“simplicity of solution” is an essential element of quality

June 24, 2007 at 6:29 am Leave a comment

Last month, I posted a response to Brad Feld’s question, “Why Do Computers Suck So Much?”, which I think deserves its own posting here because I feel so strongly about it:

Computers do not suck so much, it’s the software engineers. Software engineers suck even more. Being a software engineer myself, I think over the years the quality of engineering in software has been slowly going downhill and it has been no secret. While I know some of the reasons why software is sometimes deliberately designed so that is difficult to use with certain third party products (forced migration strategy anyone??), I would like to take your question as an opportunity rant on my dissatisfaction with the quality of software design and engineering in general. It’s just something that has been irking me for some time.

Software engineers tend to forget that software engineering is a craft. It’s a craft whose beauty is in the detailed attention paid to the relevance of the functionality and the quality of the finished product. Engineers tend to forget this fact and their managers tend to be ignorant of it. Engineering managers have been lacking in identifying great engineers. More often than not, engineering managers do not understand the composition dynamics of a great software engineering team. Most managers mistake the person who can whip up the code the fastest (and rant differences between technologies and languages) to be a great engineer and they stack their teams with a whole lot of those types of engineers. A great engineer is a person, who can not only find smart solutions to complex problems but one who can also simplify the solutions to complex problems. The smartest guy in the room is not necessarily a great engineer but just a smart guy. In my working with some of the engineers and their “program/product managers” from some of the “tier one” software companies, I noticed that a lot of them were simply just smart guys and not necessarily great engineers because they failed to make abstractions of software that were any less than “smart abstractions”. (The average user is better served not by smart abstraction of software but rather by simplified abstractions.) The end result is software that just does not “simply work” as the average user would expect. Instead, users must know that this and that needs to be done before they can complete their tasks because to a geek engineer, his/her tester and their program/product manager, that is “so obvious”. What they fail to understand is that users have an affinity towards simple abstractions as evidenced by the fact that when all else fails, the user falls back on the simplest abstraction of all “turning it off and turning it back on”.

I have not been around long enough to say software is not longer being developed the way it used be, but I have been around long enough to know that software is neither being designed not engineered the way it should be. Software engineers, who view their work as a craft, should view “simplicity of solution” as an essential element of quality of their work.


Entry filed under: Software Engineering.

Getting Real – the forgotten chapter “You are getting the BETA version of our seed funding”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


June 2007
    Nov »

Most Recent Posts

%d bloggers like this: