What are the most common lies told by programmers? by Martin Katz
Answer by Martin Katz:
Many of the answers you see here are management lies, not programmer lies. Prototypes are proof of concept and/or skeletons of a part of a program. Managers have been known to ship proof of concept as product – they usually are not looking at the long-term picture. The same thing with sloppy/hacky/elite/untested code.
On average, programmers under estimate the work by a factor of 2, because they forget about testing/QA. If there is no detailed design, that can be a factor of 3. Good managers know about this and correct for it (they keep track of expected versus actual delivery for each programmer and can get better estimates after two or three tasks).
Good development requires spending a lot of time studying what the user wants and needs. This includes the format and environment for the program (for example, under Microsoft Windows, disconnecting from the network without logging out and then logging back in will complicate any program immensely). The needs should be negotiated with the client. This should be fleshed-out to include screen appearance and response to user actions under various conditions (Analysis) and a specification provided that the user can understand (and negotiate). A design should be developed that converts the specification to procedures or functions with secific parameters and well documented activity. Tests should be developed for each item in the design (based on the design) before implementation of the procedure or function. Tests should always be written by a person different from the person who writes the implementation (often each will have a different understanding of what the procedure is supposed to do).
When a manager asks a programmer to implement something without a clear connection back through the design and analysis, there is usually insufficient information for the programmer to get the solution right the first time. The manager expects the programmer to write tests and test the code without enough information, and nobody to check the tests. Without suffiicient initial information, the repairs can take several times longer than writing the code in the first place.
Because of poor communication and/or management style, the program seems to be 80% or 90% complete when 80% of the work still remains. Only poor managers allow release of software without tests and documentation (and most programmers do not push back when the manager attempts to rush things). The other side of this is that most programmers do not like writing tests or documentation.