Ever since Jeff Atwood wrote a post suggesting software engineering may be dead I’ve gone between disagreeing and thinking it’s somehow more complicated.

Years ago at a job I had working on primarily web based software, the director of software got a look at the code our department was producing and wasn’t amused. While building and maintaining numerous applications much of the department had written spaghetti code. Nothing was in a library. A bug found in one application meant all the applications had to be scrubbed to fix the same situation. Development time for new applications took far longer than using something like Django or Symfony. There was no architecture, few patterns, and lots of problems.

The director held a meeting with the department and had one message. He’d hired engineers and not simply programmers. He expected tools, reusable patterns and code, software architecture, and even error handling.

I’ve also had the opportunity to help repair outsourced software. Hours and hours of development went into writing an application. Yet, the software failed. It was poorly architected, had hardly any documentation, and was filled complicated solutions where far simpler options could have been used.

Through all of this I learned some valuable lessons.

Roles Not People

When I talk about engineering, development, and programming it’s the roles a person does rather than a person themselves. Someone isn’t simply a software engineer or a software developer. These are all hats they can wear.

Someone who is good at building software will likely wear both of these hats at times.

What Is Engineering?

Google provides a pretty clear definition for engineering:

the branch of science and technology concerned with the design, building, and use of engines, machines, and structures.

There are many places that building software is engineering. For example, take a look at something like IBMs Watson, the design of an operating system, or even modern integrated software systems in cars.

But, engineering has gotten a bad reputation. One that’s been earned in recent years. As software engineers build new tools and figure out new ways to do things it feeds back into the system. Some companies and engineers have avoided this. Some have over engineered processes. This has led to software engineering feeling stale.

This bad reputation is more about how they do things than what they’re doing. Thankfully, engineering has been around for millenniums. Hopefully this current blip on the radar is just a blip.

The Craft

Some people architect software and systems. Some of them and many others write a lot of code to live in these systems. This is what I refer to as development or programming.

I think of it like building a sky scraper. Someone architects the building. Some others come in and architect elements like the landscaping. They come up with patterns to keep the building consistent. Then the developers come in and build it.

A recent term used to describe how this should happen is software craftsmanship. Rather than use it in opposition to software engineering I like to use it in addition to it.

If you go back to the building example, many of the people involved are practicing a craft. They work to get better, learn new tricks from others, deal with new technologies as they come out, and growth often happens by real world mentoring.

Both And

To build useful systems that meet needs, scale, are secure, and so much more, we need these two roles to work together and build both of them up. Not in some traditional sense but a modern sense that continually changes and hopefully grows.