The Magical World of Software Development (Part 2)

Last week, I discussed my perspective on the history of software development. As programming the software became decoupled from building the hardware, software engineering, also known as programming, split from engineering. Because it exists in the digital world, there is a different set of rules. Once the split occurred, software processes adapted to the rapidly changing landscape of the digital world.

Not only did the process of writing software change, but the people who were writing it also changed.

Art or Science

Software is as much an art as it is a science. I believe this is partly due to the lack of constraints in the digital world. In the physical world, you wouldn't build three slightly different bridges just to test a hypothesis. However, this and more are common in the digital world.

There are hundreds of languages, patterns within those languages, and frameworks within those patterns. With so many options and no significant constraining factors, like gravity, developers are left with only a few constraints.

Even the way a developer writes the code and names the variables has a sort of art to it. Good programming reads like a well-written article or even a poem. It has names that immediately convey an understanding of the data within and the flow of that data through the process. Bad programming, like bad art, immediately grates on the nerves.

But bad programming can still work. It could even compile to the same underlying assembly. It's just bad for the humans who need to interact with it.

So while it may seem like software development is an art, consider that teams with a lack of engineering processes tend to do poorly. There is a lot of discipline required to create good software. There are also known patterns and anti-patterns which require programmers to read and stay up-to-date on their craft.

Deploying quality software in a timely manner requires a good engineering culture. One of open criticism of the code and a clear process for how the software moves from idea to delivered solution. As the complexity of the solution grows, so does the need to take a very measured and consistent process to change it.

The answer, as you may have deduced and in my own opinion, exists somewhere in the middle. It is both an art and a science. Tilting in one direction or the other has trade-offs.

Software Developer or Engineer

TThe debate over whether we should call these people developers or engineers has existed for a long time. Like the debate over whether software development is an art or a science, it's not a clear answer with a clear winner.

I lean towards the title of software developer, but even at my own company, our official titles are engineering titles. My conclusion is that once there was the break from the physical world and software became its own thing, we had a flood of people writing software without formal training.

This is not a knock on people without formal training. I am one of them. While I have a degree, it's not in computer science. The physical world requires a credentialed person to engage in activities that would be impactful to other humans. You don't want a bunch of self-taught engineers building your bridge.

I'm sure in software there are still places that the level of engineering and education has to be extremely high for those writing software. Things like nuclear power plants, medical devices, and missile defense systems. But for 99% of the business software in the world, having someone who learned through their own curiosity and self-discipline is just fine. These people have gone on to run multi-billion dollar companies.

Once that crack opened up, people began to flood into the industry through bootcamps and late-night self-taught programming sessions. I think the gate should be wide open. However, a 3-month bootcamp isn't like a 4-year engineering degree, but it doesn't have to be to get people started in the industry.

With good mentorship, people can become quite qualified for the job in a year or two. I think colleges should acknowledge that software development doesn't have to be computer science and carve a new path for students that is heavy on the software but light on the engineering.

The Motley Crew

This was supposed to be a one-part article about how to manage software developers, but it has grown to three parts. Part of the difficulty in managing software developers is due to the nature of the job being a mixture of art and science. This attracts a wide range of people with different skillsets, thinking and training.

But all of that is due to the fact that it's a job that exists in a different world. Add remote work, and we are talking about a truly digital workforce working in a digital world. Next week, I will finally get to some conclusions about how to lead people and teams in this new world.

---

If you liked this, consider subscribing to my Substack. I publish an article about software engineering and software engineering management every Tuesday. If you want even more, consider joining my paid content where I am writing a course in real time about making the jump from developer to manager.