What are the most common lies told by programmers?


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.

What are the most common lies told by programmers?


About AvatarNemo

V: Voilà! In view, a humble vaudevillian veteran cast vicariously as both victim and villain by the vicissitudes of Fate. This visage, no mere veneer of vanity, is a vestige of the vox populi, now vacant, vanished. However, this valourous visitation of a bygone vexation stands vivified and has vowed to vanquish these venal and virulent vermin vanguarding vice and vouchsafing the violently vicious and voracious violation of volition! The only verdict is vengeance; a vendetta held as a votive, not in vain, for the value and veracity of such shall one day vindicate the vigilant and the virtuous. Verily, this vichyssoise of verbiage veers most verbose, so let me simply add that it's my very good honour to meet you and you may call me V.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s