Progress, Not Perfection

Recently, I was reminded of something called The Principle of Good Enough. Several reminders, to be exact.

This was when I got a popup notification from Microsoft asking me to upgrade to Windows 10.

Yes yes, we know.

Before that, it was in the form of an announcement that Microsoft support for Windows 8 would cease in 2018.

Shortly before that, it was in the form of a similar announcement for Windows 7.

And before that, around April 2014, yet another announcement for Windows XP.

What's all this got to do with The Principle of Good Enough, you may ask? Basically, that technology is all about progress. Progress, not perfection.

Hold on, I'm a perfectionist...

Whoa, buddy. Let me stop you right there. See, the problem I have with developers claiming to be "perfectionists" is that it's at best an extreme stance couched as a positive trait, and at worst, blatant self-praise.

Most of it misguided because, I say again, technology is all about progress, not perfection. Perfectionism is irrelevant, perhaps even poisonous, to the process.

Were any of the Windows Operating Systems "perfect"? From the ugly but serviceable Windows 3.11, to the monstrosity known as Windows Vista, to the latest iteration in the form of Windows 10? If they were "perfect", why the need for different versions? Why the need for patches?

And why, oh why, did Microsoft not wait till each version was at least bug-free before releasing to the public?

Because in technology, perfection is unprofitable.

Firstly, let's establish that there is no such thing as "perfect" unless all you're peddling is a "Hello World" kiddy script - perfect and utterly useless.

Perfectly useless.

There will always be bugs. There will always be security loopholes. But if Microsoft waited for all these to be ironed out before shipping each version, they wouldn't have sold a damn thing since 1985. Also, if you make something you consider "perfect" today, emerging technology will render it obsolete in a year.

This brings me to my second point...

Your company does not want perfection.

The duty of the developer is not to produce "perfect" software, but to produce software that will not exceed the pain threshold of their target market. Hence the Principle of Good Enough. If the user will pay for the product and not kick up too much of a stink when the inevitable bugs surface, it's "good enough". No one, not least the people paying your wages, have the time to wait for everything to be absolutely perfect before shipping.

But before this principle leads you to think you can get away with murder, think again. Just making a product shippable is a sizeable task on its own. If the product is so bug-ridden even at basic usability levels that no one will touch it with a ten-foot pole, then it is, quite simply, not good enough.

That is why, despite the Principle of Good Enough, testing is still relevant, and more important than ever.

So, perfectionists...

Remember that your first duty is to ship a viable product - whether it's an operating system, a web portal or a mobile game. Quality takes time - time that your superiors may not want to invest in. If an imperfect but serviceable system will pay the wages of your entire team for six months upon release whereas a perfect system will take another six months (while earning the company squat), which do you think upper management is likely to prefer?

Learn to look at the bigger picture. The business is far, far larger than you, your code or your principles.

Which brings to mind something I read in another blogpost, titled Don't Call Yourself A Programmer, And Other Career Advice. Now I don't always agree with McKenzie, but this hit home for me. This wasn't some airy-fairy idealism - this was real, hardcore pragmatism.

Producing beautiful software is not a goal.  Solving complex technical problems is not a goal.  Writing bug-free code is not a goal.  Using sexy programming languages is not a goal.  Add revenue.  Reduce costs.  Those are your only goals.
- Patrick McKenzie

Errata

In a previous blogpost, I provided a very shallow look at the difference between programmers and web developers.

Programmers often criticize web developers for not being thorough enough and being too willing to take shortcuts in order to get the job done, and lack of long-term vision. That's not wrong, but look at the context. Software is made to last, therefore programmers are allowed - encouraged, even - to do a proper, complete job.

Obviously, now that I consider this new evidence, I was mistaken.

Ah well, nobody's perfect.
T___T