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.

Saturday, June 22, 2013

The Pokémon Syndrome

Originally written in December 2011
Image placeholder:? Professor Oak, a middle-aged man with greying hair, stands in an adventurous pose clad in typical Pokémon Trainer gear, including a baseball cap, a jacket, a backpack, shorts, tennis shoes, and hanging from his belt, a number of colorful hand-held devices.
Caption: Lets do this! (Again!)

Go do something you haven't done in a few years. Preferably something you've only done once. Something you really didn't do so well at. You think this time it'll be different: you're older, wiser, and have as and advantage over last time that there was a last time you can now look back to.

Except that… you don't.

After a while, you'll realize you're doing everything exactly the same! It turns out that when forced to make the same decisions under the same conditions, you'll come out with the same results. This is good: it means you are still the same person you were years ago; but it's also bad, because it means that, like a machine, given the same settings – the same input – you produce the same output; you haven't changed – haven't learned.

I call this "the Pokémon syndrome" because I discovered it playing the Pokémon games.

Thursday, June 13, 2013

I am so stupid

Image: Frank the mouse cries out in frustration, his hands atop his head as if to pull his nonexisting long hair; his arms bending his whiskers.

So, I said I had a bunch of posts lined up for you the last time I was here
I wasn't lying
but they're nowhere to be seen

The reason is, I had the posts written, but I refused to actually set the automatic post date until I had done the illustration for them. Since these illustrations are, more often than not, easier to do on the computer, I've waited until I've had a computer and free time on it.