6.30.2003
False Economy of time
There is not enough time to do it right the first time, but there is time to redo it three or four times. Sitting down and planning what you are going to do, will take longer than just doing it once. However it will take less time than fixing all the problems that you didn't plan for.
Time (and schedules) should be optimized for the big picture, not for localized gains.
6.26.2003
When a schedule is shown to have misjudge the length of times the right way tocorrect the schedule is not to just add on the extra time taken so far. Rather the extra should be calculated as a percentage and then applied to the whole project (effectively multplying) by that percentage.
(0) comments
Why do we usually do the big push at the end? What is there about the development process, so that we don't usually do a big push in the middle but rather at the end?
(0) comments
6.25.2003
A failure to undstand the complete problem that you are trying to solve means that any solution that you come upwith will be incomplete. There is a good chance that the design will be unable to cope with all the needed features.
(0) comments
6.19.2003
Priorities are not defined by what you include but rather by what you leave out. It is easy to say "Do everything". It is much harder to actually prioritise and choose to leave something out. By choosing to leave something out, you are really saying the things still in are really important to me.
(0) comments
6.11.2003
A QA departments job is not to make or develop a product. QA's job is to check the status of a product. QA is working fine when it finds faults in a product, and when it doesn't. I have heard it said that QA is like the doctor who said "the operation was a success, bu the patient died.". I prefer to think of it as the anesthetist who says "the patient didn't feel a thing". The anesthetist did their job regards of the final outcome.
(0) comments
6.05.2003
Hey I just noticed that I have been linked to by http://myblog.perculaclown.net/
(0) comments
6.01.2003
Using (wasting) time to produce a demo that marketing "needs" should not happen if develment are struggling to make their schedule. All development should pbe prioritized, and it must be understood that a demo product will use SOME time and so will either reduce the final feature set, or extend the total time needed for development.
(0) comments
Its amazing that after 30 years a classic of the field "The Mythical Man-Month" is still not read by every manager. The basic message is that adding programmers does not necessarily reduce the time it will take to produce a product. Some managers still believe that increasing the team size just a few weeks before the final delivery will help.
