May 22, 2018 // By Paul Grizzaffi
In 1984, one of my favorite movies, This Is Spinal Tap, was released. It’s a “mockumentary”, if you will, about a fictional, aging, heavy metal band whose popularity is waning. When told the proposal for their new album cover is offensive and can’t be used, the band was taken aback because their current (and more popular) rival had an equally offensive album cover. When the publicist pointed out the key difference between the content of the two album covers, the band responds with “It’s such a fine line between stupid and clever”.
Back in the nonfictional world of software development, this statement is equally valid. Sometimes, it’s hard to keep ourselves from being so clever that, in the long run, we really do ourselves more harm than good.
I once worked on a team where there was a lot of unnecessary code complexity, in part because the developers were intent on one-upping each other with respect to how complex their code was. I was told multiple times, “that part is very complex; you wouldn’t understand it.” (they didn’t realize that I had a Master’s degree in computer science and had, for many years developed software for distributed systems). Also contained in this desire for complexity were thoughts of “I don’t want anyone messing up my code” and “if someone else knows my code, I can be replaced”. Clearly, this team had a lot of issues.
These kinds of conversations happened frequently between the developers and me, as well as between the developers themselves. When it came to a head one day, my comment to the team was the following:
"We’ve fooled the world into thinking what we do is magic, let’s not try to fool each other"
Needless to say, this statement was not well received.
I’ve never understood the need to dazzle with complexity; it always seemed like too much work and too much pain. Perhaps I think this because early in my college career, I had a professor who made our final project of the semester an assignment to add features to our first project of that semester, thereby making us live with the sins we’d committed in the name of getting the first project to work. I didn’t know what it was called then, but I learned about technical debt the hard way. Part of technical debt is code that is hard to extend or maintain; unnecessary complexity adds to technical debt because it takes longer to make code updates, particularly if the updaters are team members unfamiliar with that part of the code (which can include the original authors if they’ve not seen that code for an extended period of time).
Not all unnecessary complexity is introduced for self-serving purposes. Sometimes we, as developers/programmers/coders, over-engineer our code just in case, one day in the future, someone needs to add a particular capability. We create all this extra code to make it a little easier to add something that may never be added at all. In many cases, a more appropriate approach is not to implement all this extra code now; instead, we can take care to not to preclude the creation of that potential feature in the future. Generally, it’s more appropriate to incur this kind of cost closer to time that we’ll reap the benefit of that cost.
Note, I’m not saying that software shall not be complex. When implementing software to handle complex, real-world scenarios, we often need complex code to perform the appropriate tasks. I’m suggesting that complexity for complexity’s sake or as a protection of ownership mechanism is bad development and being a bad team member. We should take care to remember Spinal Tap’s fine line.