Here are 5 things understanding which will make life easier for programmers. Unfortunately, it is not the programmers who has to understand this but their super headed bosses (so called managers).
- All resources are not same. First of all, I don’t like when people call programmers “resources”. It indicates as if programmers are some kind of robots. Of different make and model but robots none the less. If you are working in software field for more than 6 months you will strongly agree with me. If you still have some doubts, you got to read The Mythical Man-Month.
- A design document can never be complete unless the coding for that product is complete. Same is true for product specification document. I don’t know why it is that hard to understand. My head starts burning when a person with a fat belly asks me “Is design complete? Have you started implementation phase? Why you are still modifying product specification?” It is roughly equivalent to asking “Is the foreplay complete? Have you started sex now?” Next time somebody says “Design for EagleWing is complete and it is in implementation phase”, you know he is one of those moron managers.
- Nobody else than a programmer can prepare a schedule for a project. Yes. Nobody else can. Doesn’t matter your super smart project manager has just returned from a fancy software estimation training which costed your company more than his one month salary. Doesn’t matter a coder is having just 6 months experience. She will still do it better. I bet last time you were given 1 week to complete import table feature in some ToDa application, you wanted to yell “You do this in a week and I will pay your salary for this month.”
- More bugs does not necessarily mean that programmer who implemented that darn thing was poor in programming. There are zillion reasons for more than average bugs being reported. Perhaps, the initial design of software was so bad that it is almost impossible to touch something without breaking the other. Perhaps the tester was far too intelligent and perfect and he found all the bugs at once which were left unnoticed in last couple of years. Perhaps the project is dealing with one of those customer who decide that their banking software should show a warning “Be careful of the snowy weather” after having a sneeze. Perhaps the programmer was not given enough time to implement blah feature properly (side effect of point#1).
- A design remains unaffected by the language, framework, platform. This is too good to be true. Can one create an application on Unix with the exact same functionality and user interface as she would do on Windows. Deliberately or accidentally, designs are created to leverage the full power of framework/platform being used and I don’t see any harm in that. Any design or specification without so much details of implementation is useless anyway and if they are detailed, they ought to have few things related to implementation scheme peek out.