More often than not I’ve had to deal with projects where I sincerely wondered whether salespeople and upper management – those that charge admission for the voyeuristic tendencies of the public in relation to technology – understood the implications of decisions. Examples abound. Planned obsolescence of a business infrastructure based on a technology tree. Coding one’s business into a corner. Complaining about the spaghetti code but forcing the conditions where all programmers can do to keep their jobs is make meatballs (features) and slathering the thing in sauce so as to keep those that sign paychecks appeased with something… resembling… something palatable. The list goes on.
Somewhere in the 1990s, Free Software and Open Source came along and put programmers in charge of much of the business process. Because of experiences I’ve had over the years, it was easy to say, “hey, this might fix everything!” Years of experience, though, made me bite my tongue because… well, because programmers are mostly interested in writing code. It’s rare to find a programmer that is interested in actually creating a product. Just as there are no unfinished poems for poets, there are no unfinished programs for programmers.
This has haunted Linux. Granted, Linux at its core has a benevolent dictator that keeps feature creep and feature tsunamis under control – but the desktop Linux never took root as much as it could have because software developers aren’t as good at keeping things simple. Frankly, in general, we suck at it. It’s not a bad thing. It’s not a good thing. It’s the way it is. There are outliers, of course, but those are rare. I’m one of them and it’s because of something quite simple I learned as a Navy Corpsman:
First, do no harm.
Harm is a subjective term. There are even people who appreciate the common understanding of the word as pleasure though this is a family friendly blog and we won’t discuss that much. Let us say that, generally speaking, there are almost no people on the planet who would wish to have harm propagated against themselves. Yet software developers have a tendency to do it every day. I’ve done it and, on much rarer occasions, I can catch myself doing such things because I’ve learned to identify them.
That’s why I really enjoyed Paula Rosenblum’s article, ‘Is Software Quality Going To Hell In A Handbasket?‘:
…Can anyone yet understand why the MS Office interface has changed completely twice in the last three releases? How many hours of productivity have you lost hunting for menu items that you knew by heart last time around? And do we even want to start talking about Windows? Not today. These posts are only supposed to be so long. Let’s just say when your Executive VP banker brother-in-law calls to ask you how to print a document in Windows 8 you know things have just gone silly…
Paula completely nails it, and that’s just a piece of the article.
Simplicity is really the key. Yet simplicity isn’t that easy when expectations are constantly evolving. The only way to actually assure a good balance of features and meeting user expectations is something that most software developers suck at: Communicating with users.
It’s almost akin to having Marines who were naughty getting stuck with KP duty – where they cook for other Marines. The Marines don’t see a flaw in this logic.
To make matters worse, businesses are also not that great with the balance – and in being bad about the balance, they often spend more money than they would have to in chasing their tails – or as they see it, catching that thing that’s oh-so-close-all-the-time.
Programmers do it to themselves. Businesses do it to themselves. Worse, both can propagate it on others – and often do.
First: Do no harm. Code responsibly. And use the right technology – just because you’ve invested heavily in it doesn’t make it right. The world has been littered with the bodies of those that meant well while reinvesting in bad debts.
After all, the income you save may be your own.