Modern Software Engineering (review)
Bibliographic information
Farley David (2022) Modern Software Engineering - Doing what works to build Better software faster, Addison Wesley, Craydon ISBN 13: 978-0137314911
Introduction
This is David Farley's second book on the topic of software development methodology. While his first book focused on the journey of the software itself, David in this title tackles the person making the software. David draws upon his experience from work-life observation, conversations with other Engineers, as well as the test of time to discuss why software engineering really is engineering, and what it takes to be one.
Readers intent
At the time of reading this, I was working in a role with the title Engineer, mind you, not Software Engineer, but Data Engineer. At the time I was also working on how Data engineers best could perform their work. While I hold that Software and data development are not the same thing and bad things happen if you pretend they are, I believe that there is much to learn from each other. As such I set out to read this book with the intent to see if there is something of the data engineer in the Software engineer.
Discussion
Reading this book has for me been an interesting experience, as it provided me with a framework for some of the suspicions and ideas that I have had myself. whit this framework I could evaluate both my own and other data engineers’ actions and practices, to see if we meet the requirements of engineering.
David starts strong at the start by declaring his conviction at the onset that software engineering truly is engineering. While at the same time admitting that the term is overused, and riddled with odd definitions. As such he spends the first sections of the book providing us with an overview of what Engineering is, the difference between production and design engineering, and how this applies to Software developers, or rather to Software engineers. He also makes a strong case for the role of science and the scientific method in the work of any engineer, especially software engineer.
For a person interested in the human side of the Software engineering question this is the most interesting part. It provides a solid argument for the existence of Software engineering as an engineering branch. While I find there is a certain dismissiveness toward anything that does not meet the criteria of engineering, This can be forgiven given the intention of the book to create a distinction.
With such a strong focus on the virtues of Engineering as a practice. there is also left a bit of a gap, concerning the application of engineering. While this is not the purpose or intention of the book (As far as I can tell), to inform us on how to apply the superpower of engineering. I do miss a comment or a side panel on the consequences of turning good engineering practices at the wrong target.
In this book, David manages to condense the message of his book pretty much at the start, while allowing you to follow his reasoning and argument for how he achieved this conclusion throughout the remaining book. As such I found it a good example of reinforcement learning when reading the remainder of the book and seeing the initial arguments come up and be illuminated from a different angle. While I can understand if readers might find it tedious to hear the same message repeated in a different context, I agree with David in his assessment that it can be seen as evidence for the centrality of the concept. That is however not to let Farley off the hook, for we must remember that this is a book constructed by a mind steeped in a set of understanding. And as much as I agree with the message, I would point out that the emergence of these concepts is more a result of their centrality in David's theory of Software Engineering than any objective statement of truth.
The part of the book that covers the details of David's description and argument for software engineering can and are broadly split into sections, The application of the scientific method to thinking, and the consequences of this thinking in the "real" world of our software. The split between thinking and its effect serves to highlight how the two are interconnected. By adopting the arguments in the section on scientific thinking, one can easily follow along with their result on software development. This leads nicely to the tools/concepts that David describes in the second (or rather total third) part when using them to enable scientific thinking.
Final thoughts
I enjoyed reading this book. It was a well-formulated argument for the case of software engineering as an engineering discipline. And coming from a Data Engineer perspective, there was still much value within these pages. I will also state that I did not need any additional arguments for their virtue to be convinced. After reading this book the role of environment control, automated testing, and deployment pipeline, have gained a new language. One that I hope will help make Data engineering as an engineering practice become more accepted.
As such it is a book I would recommend any Data Engineer read, either at the onset of their career or at the stage they want to level up. But bear in mind that I recommend reading and adopting the ideas surrounding engineering in this book. The field of Data Engineering, in my experience right now is not ready to take on the rigorous practices that David here prescribes. You are likely to encounter resistance when trying to enforce these.