I was at the bank this afternoon depositing much needed money into my very dry bank account. At about 3:50pm, all of the computers in the bank suddenly slowed to a crawl. We stood there at our respective tellers, glancing around for 5 minutes while all of the tellers asked each otehr if they were able to ‘get in’. They apologized, customers sighed and generally no one got anything done until the ‘computers’ came back up.
Being a software guy, my first instinct is to blame the programmers. The tired, overworked developers who were tasked with developing and deploying Version 2 Of The Bank Software; these developers (if they’re anything like any other programmer out there) probably had a budget that was overrun, a deadline that was missed, and a manager breathing down their neck. They probably developed the application in some easy to use language for rapid development, and if they’re anything like me (and every other programmer out there) they aren’t great programmers. In fact, if you want to get statistical, there might be 1/3 of them that are ‘above average’, 1/3 ‘average’, and 1/3 that downright suck.
They probably work in a cubicle farm as part of a consulting firm, and they’re probably the lowest bidder for the project.
Now, barely any of the decisions made are the developer’s fault. And the business people at the bank probably thought they were getting the best bang for their buck — and they did. The consulting firm probably guarantees top-notch quality and superior customer service; and the developers probably read The Pragmatic Programmer religiously.
With all of the business decisions that were made, the bank probably didn’t put an emphasis on ‘fast’. They probably didn’t say, “We need it in one year, for this cost, and we need it to be ‘fast’.” They probably assumed (much like you and I would if we weren’t programmers) that it would be lightning fast. Or maybe they’re so used to substandard application speed (I’m looking at you, Outlook) that they don’t even bat an eyelash when the system goes ‘down’ for five minutes on a busy Friday afternoon.
The question is, Why. Why does the system slow to a crawl on Friday afternoons?
Because business people made decisions based on the near-term; based on contractual obligations, based on cost; and based on maximizing profit.
No one probably even thought about the customer that has to wait in line.
But what’s the effect? So a customer has to wait for five minutes — no big deal, right?
Well, if that customer is his own business person, then that’s five minutes less they have to do any work. That’s five minutes of their life that isn’t spent doing whatever their business is.
Then there’s the multiplier effect of that. Someone who was waiting for that person now waits 5 extra minutes, and someone else waits five extra minutes because that person was waiting on person #1, and so on.
How do you quantify that?
Quantify it as lost business. That three weeks you could spend delaying deployment and load testing your application could save you money when that business decides to use you for its next version.
As a developer, you’ve got to do your learning outside of work. No longer is yours a nine-to-five job. It is a font of continual learning. Spend an hour a night just catching up on the intracies of your programming language. Premature Optimization is the root of all evil, to be sure; but skipping optimization for time saved by your banks’ customers is a recipe for never getting that bank as a customer again.
Get out of your cubicle farm, and see your software in action. Spend five minutes on a friday afternoon with your customer and see whether or not their software slows down inexplicibly. If it does, fix it. If it doesn’t, congratulations; you’re the minority.