Saturday, June 29, 2013

How software projects are supposed to work

Originally written in March
Image placeholder:? A mouse has been literally drawn into a logic diagram

Here's how programming projects are supposed to work:
  1. The client tells the developers what the program should be able to do
  2. The developers scour through the client's words for hints of how the program must work internally
  3. The developers make a plan of what they want to program
  4. The developers run it past the client and explain as best they can what the program will be like
  5. The client corrects the design (which simply means he or she clarifies what they said previously) and never speaks to the developers again
  6. The developers divide the plan up logically to maximize the number of people working at all points in time
  7. The developers execute the plan and finish the program with time to spare before the deadline
  8. The developers deliver the program to the client
  9. The client delivers the product to the end users (people like you)
  10. The users get exactly the program they want and are happy
However, things rarely work in this "textbook" fashion. What happens in reality is very different. Jokes around it abound, but this is the gist of it:
  1. The client tells the developers that they "need" a program that does something or another and demand that it use a certain algorithm
  2. The developers plan out the program and realize that the algorithm the client suggested is only going to hider the way the program works.
  3. The developers send a delegation to show the client the plan, and start programming to save time
  4. The delegation explains the plan to the client, and why the algorithm should be avoided. The client does not understand the plan and demands to see a prototype
  5. The development team largely stops what they're doing to produce the prototype
  6. The delegation shows the client the prototype. The client takes back several things he said were necessary with criteria like "it just doesn't loook pretty, even if it would be easier to use", and remains unrelentless on the use of the algorithm
  7. The developers scrap much of their work and start over
  8. The client demands to know why the plan's dates aren't being met
  9. The delegation stops work on the program to meet again with the client and explain
  10. The client corrects something said before
  11. More work is scrapped
  12. The client forgets the meeting ever happened
  13. Repeat steps 8 through 12 as many times as fate deems fit
  14. The client's boss yells at the client for not having brought him the program in time
  15. The client threatens the developers in whatever ways their contract doesn't cover
  16. The developers rev up the speed, forsaking bug testing, and anything else they can, to avoid letting the threats come to fruitition
  17. The developers deliver the program to the client
  18. The client delivers the product to the end users (people like you)
  19. The end users start encountering bugs, which they ask the person who gave them the program about
  20. The client hopes his boss won't notice and charges at the developers, who are probably hospitalized by this point from the effort of the last crunch, demanding the bugs fixed by an arbitrarily near date
  21. The developers work furiously from their "hospital beds" to fix those, and just those, bugs the client told them about, without checking the rest of the program to make it in time
  22. The client proudly announces a "patch", "fix", "update", or "upgrade" (depending on which will impress his boss the most) and distributes it among the end users
  23. Repeat steps 19 through 22 as many times as fate deems fit

And the moral of the story? If the software you got sucks, it was probably comissioned by an ass.

No comments:

Post a Comment