Building Unnecessary “Stuff”

The ability to simplify means to eliminate the unnecessary so that the necessary may speak.

— Hans Hofmann

Software Engineers love to write code – this is probably not a surprise to anyone. What might be less well known by those who are less technical is that there are two main categories of Engineering work:

1. New Creations – for some projects, the Engineers are creating something that has never been created before. In the world of R&D (Research and Development), this type of work is heavy on the R and the D part is usually pretty challenging [1]. The most obvious work for this category is any project that contains the words “first in the world” where the team is literally pioneering their way through the project [2].
2. Derived works – for other projects, there is a well-worn path and the team is just creating something based on previous examples. Any project that contains the words “another ______” fits this category [3]. There is not much R in R&D for this work and the D part usually isn’t that challenging either [4].

Of course, this categorization is not truly binary, but rather a continuum [5]. For the purposes of this discussion, though, let’s assume that many projects are clearly in one category or the other.

You might gather from my notes above that Engineers, as a rule, have a massive preference for “New Creations” over “Derived Works”. The only hitch is that true Engineering (as practiced or many decades by the pre-software types of Engineers) is “standing on the shoulders of giants” type work – i.e., Derived Works. Electrical Engineers, for example, combine standard components in novel ways to make a new invention. Computer companies, for example, don’t create a new processor chip or video card each time they make a new computer – they take existing ones and build a computer around it.

The equivalent in Software Engineering is a pre-built component, such as a development framework, a web server or a database. As cool as it would be to create our own database, there are several commercial ones that work quite well. Assuming that the database is not the product we’re selling, there is probably no value in creating our own. The same is true of an application framework (a bundle of code that helps Engineers make an application faster) such as Java Enterprise Edition (JEE) or AngularJS.

Ironically, in the last three companies where I have worked, all of of them built an application framework, one built an application server and one built a database. One of the three even invented a programming language, and another resuscitated an obscure language and built a program to translate it into computer-readable 1’s and 0’s [6]. In one of the companies, I jokingly asked if they ever thought of creating a database (since they had invented many other unnecessary things). I got a very serious, “we intended to, but we haven’t been able to find the time”.

If you have been through the Introductory Series and are convinced that the only Objective is delivering valuable functionality to the Customer and that only things that are visible across the Customer Membrane are worth worrying about, then clearly something like an application framework, if that is not the product the Customer is buying, is generally not adding any value.

When I say that it’s not adding value, the Engineers who are proponents of building their own framework will say that they had to because none of the existing ones were good enough for their needs. I should be clear for the non-technical readers – there are dozens of application frameworks in the wild. There is undoubtedly something an Engineer can complain about in each and every one of them, but some of those frameworks run the largest websites in the world just fine. In my opinion, if it’s good enough for LinkedIn or Facebook, it should probably work for your project.

In every case where I have seen a company build their own tools, they ended up spending an inordinate amount of money building and maintaining those tools. As well, there was a constant stream of defects solely due to those tools and many major performance issues as well. If the time spent on homegrown solutions was spent instead on functionality that provided Customers actual value, I guarantee that Customers would be better served and there would be a massive positive economic impact to the company. As well, Customer would have benefitted in many ways from being on more widely-used frameworks and tools.

So the next time, as an Engineer, or as someone who is dependent on Engineers, you contemplate building anything (especially something that has already been invented), please stop and consider what the old school Engineers would have done. And, additionally, ask yourself, “Will this provide additional value to my Customer?”

This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker

Footnotes:

[1] Keep in mind, that for Engineers, “challenging” equals “interesting” and often even “fun”.

[2] Projects that contain the words “a better _____” also fit, but are often in a danger zone we’ll discuss shortly

[3] As in “Another e-commerce site”.

[4] For Engineers, “not challenging” equals “deathly boring”.

[5] I am reminded of the adage that there are two types of people – those that divide people into two types and those that don’t.

[6] This type of program is called a compiler (although in this specific case, the company built an interpreter, which isn’t quite the same, but that difference isn’t important for this discussion).