{"id":352,"date":"2022-01-30T16:14:23","date_gmt":"2022-01-30T16:14:23","guid":{"rendered":"https:\/\/www.davefarley.net\/?p=352"},"modified":"2022-01-30T16:21:42","modified_gmt":"2022-01-30T16:21:42","slug":"what-is-modern-software-engineering","status":"publish","type":"post","link":"https:\/\/www.davefarley.net\/?p=352","title":{"rendered":"What is Modern Software Engineering?"},"content":{"rendered":"\n

I have a new book out. It\u2019s called \u201cModern Software Engineering<\/a>\u201d and I have been working on it for the past few years. <\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

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. <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Applying Science<\/span><\/strong><\/p>\n\n\n\n

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\u2019s best approach to problem solving, so it should certainly be applicable to a difficult, technical discipline like software development.<\/p>\n\n\n\n

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<\/strong>. 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\u2019s a word for that, we call it \u201cEngineering\u201d<\/em><\/strong>.<\/p>\n\n\n\n

Engineering != Bureaucracy<\/span><\/strong><\/p>\n\n\n\n

At this point I got rather nervous. It seems to me that in our discipline of software development the term \u201cengineering\u201d has become either incorrectly loaded with meaning, or emptied of it all together.<\/p>\n\n\n\n

On one hand, many people assume that \u201cEngineering\u201d means stifling bureaucracy and heavy-weight process control.\u00a0<\/p>\n\n\n\n

On the other, \u201cEngineering\u201d simply means writing code and nothing else.<\/p>\n\n\n\n

Both of these are profoundly wrong. In other disciplines, \u201cEngineering\u201d is simply the stuff that works<\/strong>. It is practical, pragmatic and more, not less, efficient. <\/p>\n\n\n\n

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! <\/p>\n\n\n\n

Avoiding Bad Ideas<\/span><\/strong><\/p>\n\n\n\n

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. <\/p>\n\n\n\n

Data scientists not using version control, resulting in 90% of ML projects never making it into production<\/a>.\u00a0<\/p>

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!\u00a0<\/p><\/blockquote>\n\n\n\n

So something that was able to steer us away from bad ideas would be a very valuable thing to have.<\/p>\n\n\n\n

The Billion Dollar Mistake<\/span><\/strong><\/p>\n\n\n\n

The idea that \u201cEngineering == Bureaucracy\u201d is wrong<\/strong>, 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

We assume that \u201cEngineering == Production Engineering\u201d 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\u2019t work!<\/p>\n\n\n\n

Production is not Our Problem<\/span><\/strong><\/p>\n\n\n\n

In software \u201cproduction\u201d is not our problem! Our product is a sequence of bytes, and we can recreate any sequence of bytes essentially for zero cost. <\/p>\n\n\n\n

This means that we NEVER have a production problem<\/strong>! 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. <\/p>\n\n\n\n

Design Engineering NOT Production Engineering<\/span><\/strong><\/p>\n\n\n\n

So how do we optimise for exploration, learning and design?<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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\u2019t. We need to do the same.<\/p>\n\n\n\n

Designing Complex Systems<\/span><\/strong><\/p>\n\n\n\n

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. <\/p>\n\n\n\n

Software Development as an Engineering Discipline<\/span><\/strong><\/p>\n\n\n\n

I came to the view that this assumption that \u201csoftware development isn\u2019t really engineering\u201d is correct in practice, but very wrong in principle<\/strong>. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

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!<\/p>\n\n\n\n

Modern Software Engineering<\/span><\/strong><\/p>\n\n\n\n

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. <\/p>\n\n\n\n

My thesis is this, if an engineering approach to software development doesn\u2019t help us to create better software faster, then its wrong<\/strong> and doesn\u2019t qualify as \u201cEngineering\u201d. <\/p>\n\n\n\n

Like most authors, I was nervous about how these ideas would be received, but \u201cModern Software Engineering<\/a>\u201d, 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.<\/p>\n","protected":false},"excerpt":{"rendered":"

I have a new book out. It\u2019s called \u201cModern Software Engineering\u201d 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 … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5,30,27,29,34,26,23,33,16],"tags":[8,15,45,43,9],"_links":{"self":[{"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/posts\/352"}],"collection":[{"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=352"}],"version-history":[{"count":3,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/posts\/352\/revisions"}],"predecessor-version":[{"id":358,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=\/wp\/v2\/posts\/352\/revisions\/358"}],"wp:attachment":[{"href":"https:\/\/www.davefarley.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=352"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=352"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.davefarley.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=352"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}