What is Modern Software Engineering?

I have a new book out. It’s called “Modern Software Engineering” and I have been working on it for the past few years. 

The ideas in it grew out of a growing realisation that the way that I approach software development, and the way that all of the teams that I was familiar with, that I considered excellent at software development, shared some fundamental characteristics. 

This got me interested in trying to nail down those characteristics and formulate them into a model that I could use to explain what it seemed to me worked best for software development.

Applying Science

I recognised that my own thinking has long been influenced by one of my hobbies, I like to read and learn about science. I am interested not just in the findings of science, but also in the organised approach to knowledge acquisition that it represents. Science is humanity’s best approach to problem solving, so it should certainly be applicable to a difficult, technical discipline like software development.

I had long described my preferred approach to software development, Continuous Delivery, as a simple, pragmatic, application of scientific style reasoning to solving problems in software. This led me to become really interested in exploring this idea in more depth. What does applying an informal approach to scientific learning and discovery mean when we apply it to solving practical problems? There’s a word for that, we call it “Engineering”.

Engineering != Bureaucracy

At this point I got rather nervous. It seems to me that in our discipline of software development the term “engineering” has become either incorrectly loaded with meaning, or emptied of it all together.

On one hand, many people assume that “Engineering” means stifling bureaucracy and heavy-weight process control. 

On the other, “Engineering” simply means writing code and nothing else.

Both of these are profoundly wrong. In other disciplines, “Engineering” is simply the stuff that works. It is practical, pragmatic and more, not less, efficient. 

Sure, it may offer some guide-rails, constraining our thinking, but it does that in a way that helps us to rule-out, or at least steer us away from, dumb ideas. This is a really good thing! 

Avoiding Bad Ideas

In software development we have a poor history of being able to eliminate bad ideas. We tend to make the same mistakes over and over again. 

Data scientists not using version control, resulting in 90% of ML projects never making it into production

Low-code environments that work on the assumption that you know exactly what you want at the start of a project and that that requirement will never change – good luck with that idea! 

So something that was able to steer us away from bad ideas would be a very valuable thing to have.

The Billion Dollar Mistake

The idea that “Engineering == Bureaucracy” is wrong, it comes from a completely incorrect, but understandable, mis-categorisation of what engineering in other disciplines is about, and then applying that mis-categorisation to software.

Humans are used to building physical things, so the production of physical things is front and centre in our minds when we think about making things. The inspiration and design of a physical thing is certainly a challenging problem, but it is so much more difficult to scale that up to produce those things en-mass, that we assume that that is where the only real challenge lies and so we assume that is all that engineering does.

We assume that “Engineering == Production Engineering” and so we, as an industry, made the billion dollar mistake of attempting to improve the efficiency of software development by applying production-line techniques. Didn’t work!

Production is not Our Problem

In software “production” is not our problem! Our product is a sequence of bytes, and we can recreate any sequence of bytes essentially for zero cost. 

This means that we NEVER have a production problem! Our problem is always one of learning, discovery and design. Engineering for software then, needs to focus very firmly on that part of the challenge and ignore, or at least automate our production process. 

Design Engineering NOT Production Engineering

So how do we optimise for exploration, learning and design?

If we want to look for examples outside of software, this is much more closely related to the innovative creation of new things, than it is to production engineering. Design engineering is a very different discipline. Think NASA designing Mars rovers, or Apple designing the first iPhone or SpaceX designing their Starship.

For this kind of engineering you optimise to be great at learning. Modern engineering consciously designs systems in ways that allow the engineers to iterate quickly and efficiently so that they can learn what works, and what doesn’t. We need to do the same.

Designing Complex Systems

The systems that modern engineers create are increasingly complex and sophisticated, so as well as focusing on learning, modern engineering in general, but certainly modern software engineering, needs to focus us on managing that complexity. We need to focus our tools, techniques and mindset on dealing with the complexity that is always at the root of our discipline. 

Software Development as an Engineering Discipline

I came to the view that this assumption that “software development isn’t really engineering” is correct in practice, but very wrong in principle

How I worked for most of my career certainly did not qualify as engineering, it certainly was closer to craft. However, in the latter part of my career I started to think more consciously about how I could do better. 

I started to take a consciously more rational approach to decision making in all aspects of software development. I started to apply some heuristics that would guide me, and the teams that I worked with, more reliably towards better outcomes. It works!

Modern Software Engineering

I have tried to outline this organised, but pragmatic and low-ceremony approach to software development in my new book. To capture some principles that I think are generic to all software development in a way that we can adopt them and use them to steer us in the direction of more successful outcomes. 

My thesis is this, if an engineering approach to software development doesn’t help us to create better software faster, then its wrong and doesn’t qualify as “Engineering”. 

Like most authors, I was nervous about how these ideas would be received, but “Modern Software Engineering”, my new book, is starting to gather some great reviews and people are finding the ideas in it as helpful as I have. If you read it, I hope that you enjoy it.

This entry was posted in Continuous Delivery, Continuous Integration, Culture, Effective Practices, Engineering Discipline, Personal News, Software Design, Software Engineering, TDD and tagged , , , , . Bookmark the permalink.

4 Responses to What is Modern Software Engineering?

  1. AC says:


    You say:

    Low-code environments that work on the assumption that you know exactly what you want at the start of a project and that that requirement will never change – good luck with that idea!

    Could you elaborate on this? Why do you think low-code is a bad idea?

    As far as I know, low-code doesn’t mean that the implementation / requirements cannot be changed.

    Thanks in advance.

    Best regards,

    • davef says:

      It is less that I think “Low code is a bad idea” and more that I think that the problem with coding isn’t what most people, at least most low-code creators, think it is. The problem with creating computer systems isn’t a problem of typing, it is that we have to consider all sorts of things that we are likely to get wrong first time. That means that we have to organise our work so that when we do get things wrong, we can find the problem, and fix it quickly. For that we need ideas like version control, and testing. Every low-code system that I have seen break down in nasty ways when you pass some threshold, that is hard to determine up front, of complexity. Big, broken, spreadsheets are a terrible, and regular source of errors in big firms. That is not because spreadsheets are evil, it is that they are an overly simplistic representation of the problems of programming a computer, and at that hard to see threshold of complexity, they aren’t maintainable. All low code systems suffer from this, as far as I can tell. They are great at simple, constrained, problems, and then they are a disaster when you pass that threshold.
      My view is that software development is considerably more complex than it looks on the surface, and is about lots more than the syntax of your programming language.

  2. Robert says:


    Just wanted to note that your book has brought back the joy of programming for me. I’m actually doing some programming for fun for the first time in a long time, because the approaches outlined in your book are so liberating and make even big projects seem approachable.



Leave a Reply

Your email address will not be published. Required fields are marked *