C’est ne pas une Engineer

I cringe every time I hear someone say “Software Engineer”. Some of this has to do with growing up in Canada where there is actually a “Professional Engineer” organization, and some of this has to do with the way that people view the profession itself. There are some odd parallels that people associate between building software systems and building bridges that I think have warped people’s expectations. Be prepared to have this metaphor taken to extremes today.

Estimating project size and scope is one of the most daunting problems that happens as a result of lumping software developers into the engineering bucket. After all, if it took you six months to build the last bridge, it should take you six months to build the next one, right?

It is not that simple. The difference probably comes in the planning. If you are building a bridge, you will generally do a lot more up front work. What are the elevations at every point along the project? What is underneath the bridge? Is there clay, silt, or bedrock? Will the bridge need to be elevated to a certain point for river traffic to flow underneath it?

The average software project does not have nearly as much up front effort put into it. Imagine if you are starting to build a bridge over a river and you did not do all of this work in the beginning. If you did not check the riverbed to determine whether there is soft mud or bedrock underneath, you might expect that there will come a moment where you will need to invest more time in making sure that the piles needed to support the bridge are deep enough and tall enough. “We did not do enough planning” might sound familiar. It happens all of the time, especially if someone in your team is fond of saying things like “something something agile!” when asked about your processes.

This is the problem that gets created when you slap that “Engineer” sticker on the forehead of your software developer. There is not enough structure and planning around the average software project for the term “Engineer” to be appropriate.

We can fix this in a couple of ways. I sneak the word “Developer” into discussions whenever I can. This is not really a solution, but it prevents me from screaming out loud and clawing at my eyes due to the horrible burning sensation created by most software projects. I have been given feedback that people on my teams do not appreciate it when I do this for the duration of the post mortem meeting and it is a super bummer during sprint planning. Feedback taken.

The real way to fix this is to help educate the non-technical leadership around you about what software development takes and why it is so gosh darned hard.

Let’s go back to our bridge example. If we are building a simple bridge for foot traffic and bicycles, that is an entirely different proposition than building a high throughput multi-track railroad bridge. The amount of support work, the types of materials needed, and general planning that goes into making the railroad bridge is going to be significantly more involved.

The choice of materials might not feel like it translates into software development, but it kind of does. You have to choose your deployment strategy and the language/environment in order to bear the proper amount of load. If you choose your database infrastructure poorly for a high intensity system, it will be the same as trying to make a railroad bridge out of simple timbers and pedestrian bridge materials—it will come falling down.

The farther we go into this the more you might be looking at me and asking “Aren’t you basically proving that the two of them are really the same thing?”

You might not be wrong here.

The bridge metaphor helps to highlight where the difference is and why most software development projects are not really engineering endeavors. Let’s go over the differences.

Planning and approvals – There is generally a document or two that exists in every project before people start building. Most software development projects do not have enough of this. It is one thing to have a few requirements sketched out and another to have deeper architecture dive done before actually getting started. This goes back to those surveyors and architects. 

Architecture – This is one of the big problems in software development. Certainly at some larger companies, or more mature companies, there is a group of people who have to think long and hard about the deployment environments, development tools, and scaling strategies. The average software project does not have enough of these. Most software architecture is ad hoc and has poor assumptions about infrastructure and deployment. Even more controversial is that some of the people who design the architecture for some software systems are also the people who end up building them. The kids might tell you this is “totes cringey”. The software development projects I have been on that have been the most successful are the ones where there has been enough independent oversight in place to help steer software developers towards a successful deployment.

Complexity – Last but not least is our good friend: complexity. This is not to say that bridge building is not complex— it is. Software complexity is its own beast and is largely the reason that many software projects struggle or outright fail.

There is a big difference between linear complexity and geometric complexity. Google yourself some math terms if you wish to be educated on the shape of those curves. The best software development projects reduce the scope of their complexity at the planning phase. It is very hard to do this until you have blown up a project or two. I now ask myself “How can I reduce the complexity of this system?” at every part of the software development cycle.

Over the course of thirty years I have seen many different kinds of software projects. I interned at Motorola Canada working on an ISO-9001 certified waterfall software development project for emergency dispatch software. That was probably one of the more thoroughly planned out projects I ever worked on. A modern day Agile developer would have turned blue and clawed their eyes out at how much up front planning and process was involved. It was also a great project that shipped in a reasonable amount of time—and it saved lives!

So where do we wind up? I will still twitch a little when I hear “software engineering” and that will probably be true for some time. This is because so many companies have poor processes for planning software projects. As we march blissfully towards the heat death of the universe I hope that we see more architectural support for projects and more thought about software complexity. This will go a long way towards making me feel better about the phrase “software engineering”.

I hope it gives you an opportunity to reflect on the subject also.

Thank you again for reading. I hope that my angry fist-shaking-at-the-sky rant about software engineering has exploded your brain and left you completely shook. At the very least, it has moderately amused you and convinced you to come back next week to read some more.
If you do not plan on coming back for more, then you should immediately go purchase this six-pack of colorful clown wigs (disclaimer: This is Amazon Affiliated Merchandise) that you can buy and wear to work. You can see yourself out.