The Stigma of Simple Software
Saturday, September 21, 2019

I'll admit it: I write simple software. I'm hesitant to actually use the word "admit", however, as it suggests that writing simple software is some type of engineering sin. That said, I'll also admit that on a broader scale, I aim to design simple systems.

There is no shortage of advocacy for writing simple software – some dating back several decades. The Zen of Python, a list of 19 (or 20) software design tenets (largely applicable to any language) decrees "simple is better than complex" as its third commandment. Software design acronyms like KISS (keep it simple, stupid) and YAGNI (you ain't gonna need it) are familiar to many developers, and despite their wide, general acceptance amongst most, there nonetheless seems to be no shortage of over-architected and over-complicated software being written. Why are we making things so complicated, even when we know we shouldn't be?

Years ago, I was provided a coding exercise as part of an interview whose requirements were as follows:

Please demonstrate how you would code the following scenario: The cost of benefits is $1000/year for each employee. Each dependent incurs a cost of $500/year. Anyone whose name starts with 'A' gets a 10% discount, employee or dependent. We'd like to see this calculation used in a web application where employers input employees and their dependents, and get a preview of the costs. Please implement a web application based on these assumptions: (1) All employees are paid $2000 per paycheck before deductions and (2) there are 26 paychecks in a year.

To which I produced the following in response (actual company logo changed to protect the innocent):

fake logo courtesy of Pigment

I am of course biased (as the author of the code), but I thought what I'd produced was clean and well-written. It looked nice, it was easy to use, it met the requirements – and it was simple.

The interviewers, however, disagreed. I was asked a gamut of questions – some general and some related specifically to the project. Amongst those was, "what could you have done differently?" Given the simple requirements – and given that they were well-addressed with a simple solution – I didn't have much of an answer for them. As such, I was pressed with follow-up questions like, "why didn't you cache the jQuery selector?" and, "why didn't you use an IoC container?"

I tried to remain as polite and professional as possible while under the scrutiny of these architecture astronauts, and though I don't recall all of my answers, I do believe I answered the second question with, "because this is a calculator".

Needless to say, I didn't get that job. What I found interesting, however, was that after the interview process was over, I actually found GitHub repos from a number of other developers who went through the same exercise for the same company – and most went the exact opposite direction. Web API, Entity Framework, Angular... You name it, chances are it was used somewhere in one of these other projects.

While all of those technologies are fine and dandy, the crux of the issue remains: the requirements were effectively for a calculator, yet many developers chose to go hog wild with technologies which added nothing of value to the project – only overhead and complexity – presumably to showcase their skills.

For what it's worth, these other developers who had their code on GitHub also had their resumes publicly available – and none of them looked to have been employed by the company in question, so what that company was looking for in a developer is anyone's guess.

Justin Etheredge in his article Software Complexity Is Killing Us echoes my experience:

I can’t tell you the number of times I’ve had a developer tell me that building something as a single page application (SPA) adds no overhead versus just rendering HTML. I’ve heard developers say that every application should be written on top of a NoSQL datastore, and that relational databases are dead. I’ve heard developers question why every application isn’t written using CQRS and Event Sourcing.

I actually don't know why so many developers choose to over-complicate things. Perhaps there's a fear of being seen as "responsible" for "inflexible" software which can't magically adapt to every future business need. Or, perhaps in their mind, these developers aren't over-complicating things.

Of course, these same developers would likely respond by insisting that my software is too simple, too rigid – dare I say even too amateurish?

"What if we need to replace this service or that service?" they'll exclaim. "What if we need to switch from SQL Server to Oracle?" "What if we need a different logging library?" "What if we need a different JSON serializer?" This endless speculation – and the quest to solve what are often obvious non-issues – is killing us.

Of all the sciences, it often seems like computer science (in the broadest sense) is one where there is no shortage of folks who disagree simply to disagree – as opposed to doing so constructively for the advancement of the field. Anyone who's ever been on Stack Overflow (read: everyone) has undoubtedly seen replies from users who seem to be hell-bent on doing nothing but touting every solution other than their own as the "wrong way" to do things.

I think this speaks to the mindset of some developers – a mindset in which they feel like they have to write fancy, complicated code to gain the respect of their peers. In my opinion, this couldn't be further from the truth.

The hardest part of YAGNI is believing it. My suggestion is this: keep your software simple – and err on the side of "ain't gonna need it" if you're ever on the fence. If you get one wrong and you "need it" later, write it later.

There shouldn't be an unspoken stigma associated with "simple" software. Rarely is it simple to write clean, concise code which solves difficult business problems and is comparatively quicker to write and easier to maintain. To that end, simple software is often anything but.

Blog engine and all content © 2024 Jason Plackey