Christian Tortorich wrote: >I would suggest the possibility that what gets passed down as >programmers underestimating the complexity of the problem is in fact a >clever disguise for mismanagement of the project. Programmers pretty >much do what the requirements say, don't you think? I know we have all >felt the problem of vague, not well thought out requirements that the >programmer/sysadmin/drone must make a best guess at. > Generally you can pick up on management problems as being the source of failures when the project direction starts to change in mid-project - for instance: you're told that the project will not require any printer support and then, when shown the first beta, they ask "So, how do I get a hard copy of this?"
It's easy to assign blame in that example, but try this one: An application is designed to generate and print graphical data and store the results in a database - when finished it works as advertised but after more than 30 results are stored in the database, the data retrieval times stretch into minutes over a network... this is not discovered until a month after the product has been released. Is this a management/specification issue because network access times were not specified? Or should the programmer have tested the database with more than half a dozen datasets? The temptation is to say that the first problem is a management issue, and that the second is a programming issue but I would suggest that they are both programming issues. A smart programmer would have built printer support into the app to start off with (disabled, but there just in case), and in the second example, should have generated a large test database even though management only provided a small dataset to work with. This, in my mind is the difference between an $8/hr job and a $40/hr job - and yes, these are all real-life examples. -- I am a computer . . . I am dumber than any human and smarter than any administrator.
