There is a fact that some companies are overselling their services. The behavior is simple to describe, they take more projects than they can handle. Q: Why they can not handle those projects? A: Efficiency. As consequence, you have a heavy work load on developers, project managers and the rest of the hierarchy tree. Then you have project managers overtaking commitments, losing them, and sometimes losing a client.
According to my criteria, most of those steps back to certain milestone or time schedules have common origins:
- Incorrect NNPPs management.
- Skilled developer inefficiency.
- Incorrect estimations.
- Project tasks hieararchy.
- Difference between quality and patch-and-run.
If I have left some issue, please leave me a comments.
On "beware with the nnpp", I’ve wrote a little about NNPPs, so I think that I don’t need to explain more about them, and you can read the related paper directly on this link. So let me review the other points.
skilled developer inefficiency
You can have a skilled developer working with you, but he can forget commitments, ask for system passwords continuously, fall repeated times over the same bug, and so on. Usually a skilled developer has a strong short-term memory, but an impressive long-term memory. He can have a clear concepts for years, since he is a polyglot programmer and while is programming he can traverse the code as reading a comic book.
When a skilled developer falls many times on the same bug is mainly because he is not holding on the problems he faced on short-term memory and most of them are not related to long-term memory since are not problems related to concepts. The same applies to those scaled bugs, when modifications on software are generating more bugs.
Here we can use third party tools, such as NoteCase, Nagaina, HNB — this one it’s quiet old, I was using it from my origins in BSD, and is made for a terminals instead of GUI — or TuxCards. Those tools are made to take notes hierarchically. So you can keep your project notes in ordered and portable files. If you prefer online versions, you have Google Notes. Then you can keep a lightweight tracking on those issues which are not documented. Other skilled developers will prefer emacs planner-mode a kind related tools. Then you will not forget those non documented project details that bring you those headaches continuously by forgetting their importance.
Tracking the issue time is important, if you have good long-term memory, you will classify most algorithms you have solved and you will be conscious about the time that you need to implement them. So you will not do a commitment with the wrong time. Personally, on the most complex algorithms that I’ve solved, I’ve tracked them on KArm inside Kontact and scheduled them in the TODO list inside Kontact too, so I know more precisely how long can take me to implement certain algorithms. Using a scheduler is important too. I use Kontact to track my commitments and I a have a well structured project tree on my E-Mail folders. Kontact is nice in those aspects, I have synchronized contacts and commitments on my desktop computer, my notebook and my smartphone. Then I can bring a precise scheduled times.
incorrect estimations
You can not do a good estimation about how long can take a development if you are not conscious about what the problem means. Someone have assigned to solve and implement an NP-Complete algorithm — something related to GIS software and terrain calculations — in three days distributed along a week, without a continuous development. Since those problems require design strategies and complexity metrics to reach optimal performance, you can not solve them in three days, mainly when this kind of problems require a small research on geometric formulas, such as vector module. I don’t know if there is a track on related problems, but certainly the assignment was completely wrong estimated.
So, here enters the efficient developer, who track his time, and let their managers how long can take the implementation of certain algorithms. Also if the manager do not ask for the required time or the manager have not tracked the algorithms solved by their developers with the proper classification, he certainly is not a good manager.
Another story is about a friend. His manager has assigned another NP-Complete algorithm to be solved in one HTTP Request, and the algorithm was related to the classic bag distribution problem. Something hard to solve without parallel computing or distributed computing in one HTTP request. That manager was making incorrect estimations. Since he was assigning near to four days to solve that problem.
So, to take the right estimation for some problems, you must know in depth about the problem related algorithms to implement. Mainly when those algorithms have no simple solutions. Here time tracking and knowledge on algorithms and the used technology are key elements.
project tasks hierarchy
Most software developments require a well structured hierarchy on how milestones are committed. Certainly, if you are building any system that requires data management you can not start with data processing tasks without data handling and data loading tasks firsts. For example if are building a CMS, you can not start with public site template without building the Content Management first.
I know many managers doing the wrong prioritization of milestone hierarchy. Losing a lot money, weeks of development, and certainly throwing away patch-and-run software that is not used from the point that is not reusable and made hastily. And everything about this makes you fall in a cascade of software bugs and mistakes that makes your developers appears as code monkeys.
Possibly another mistake is to take low profile developers, people that appeals to have a good knowledge on certain technologies, but really is not knowing about them. Then you build a pretty schedule on certain task, you have your NNPP doing a bad job and then you get your tired skilled developer running away of your decisions.
difference between quality and patch-and-run
Software quality have a cost. Most clients now days do not assume that cost. As consequence you have tired developers trying to catch all those requirements and finally doing patch-and-run work with the conformance to it runs, does not crash, I’m happy since I’ve sold it. The cost reduction have a side effect, not just tired developers. As consequence you have half-made software with an specific solution, and many times with those invisible bugs that appears when you think that everything is done and clean.
Usually patch-and-run or quick and dirty means that you develop software with enough quality to run, but not enough to be maintained. This problem scales the software development until the point of carrying higher loads of work. A good client understand it, a bad client prefers the lower cost, and something that just runs. In this case, you must be a little bit humble with your earnings, and invest time on preparing utilities to face those kinds of projects, so you can reduce the development time and project cost. Also, is recommended to leave this kind of clients, if a client do not want to pay the real cost of a project, just leave it.
Quick and dirty solutions just carry heavy work load, since over the time they turns in software hard to patch and hard to follow. Usually, if you are on a company where they prefer that kind of solutions, leave it, because it sucks. In a few years you will be patching the same bugs each time, you will not grow and your career will be stagnant.
On a good company, they will bring good solutions to their clients from the basis of they are selling good software, not the cheaper one. Participating in FOSS development, such as FOSS based frameworks is a plus, it will bring you a near approach to good practices and rigorous organization. By rigorous I understand well redacted electronic mail, using the netiquette as it basis, precisely written technical descriptions and at least good experience with teamwork, with well distributed tasks, and each one with his own responsibility.
The use of neat development tools, such as mailing lists, for example, you can setup your own private mailing list at Google Groups or if you prefer a more private mailing list, setup a mailman server. It will store the archives for a long time, so it can reduce the cost of doing repeated tasks of support on the same issue, so the mailing list users will have access to the mailing list reading the proper answer when it is required. Also, the participation on mailing lists can bring a good knowledge base and growing skills. The mailing list also can bring a better look on who have the better skills on the team, since it not requires enough formality as documentation does.
On the same point, you can not setup a Knowledge Base without assigning time to each developer to make it grow. You can not expect that your developers will be publishing articles on your private KB on their free time at home when you keep them patching your quick and dirty software with heavy work loads — fool. You can setup a lot of development tools, such as issue tracking systems, like Trac which have an embedded Wiki, and so on…
conclusion
Learn about what are you doing. It is made when you know it from the bottom and you have seen which is needed.
reference: a single IRC conversation…
