Beyond Legacy Code (Book review)
The Software Development industry has had a string of high profile failures. Also what mainly goes unreported is the large number of corporate applications that become so called legacy applications as soon as they are pushed to the live environment.
Legacy applications are costly to support and usually close to impossible to enhance quickly so that a company can react to changing market conditions and customer requirements.
It’s also important to be able to change software to cater for new rules and regulations, particularly in the financial industry. In smaller companies it’s quite regular for the owner to have an idea overnight and wanting it implemented quickly.
There is a real need to improve the maintainability and changeability of software. It’s far too easy to create software that ‘does the job’. But those poorly designed applications have little scope for being enhanced. The mere suggestion of adding a feature is often greeted with, “We can’t touch that, no one knows how it works”.
I firmly believe that we should move to creating better software, and this is not just a Programmers responsibility. Managers, Business Users and Stakeholders all need to be involved.
If, like me you are interested in improving the quality of software, interested in creating software that is bug free, easy to maintain and enhance, then Beyond Legacy Code by David Scott Bernstein is a book that I highly recommend.
David has a passion for creating software that is bug free, easily maintained and extendable. In this book he shows us that we don’t have to create legacy software. He shows us that we can create software in such a way that we can easily enhance it and be confident that bugs have not been introduced.
One of the main threads of the book is test first development and TDD. If you find yourself saying “Oh no, not another book on TDD”, let me tell you that this is different, it will give you a whole new fresh perspective on TDD, Agile and Object Orientated Programming.
I personally started using TDD back in in 2005, I’ve seen how it can help me create better code and David fully explains how to implement it.
I want to stress that this book it not just about TDD, David covers a whole range of topics that will help you improve the quality of your software.
Here’s a quote from the book.
Most software is written in a way that often makes it harder to read than it was to write. It’s full of dependencies – one piece of code depends on another, which depends on another, until the entire system is one big knotted mess.
I think that the main audience for this book is coders. However, it explains concepts in a way that should be understandable if you have a slight technical inclination. Perhaps you are a team leader that has not done hands on coding for several years, then this book can bring you up to date on how to create high quality code.
It will also be of use to you if you are a Scrum Master or Project Manager interested in trying to understand the many things that a coder has to do to create a software product. And whoever you are, you’ll pick up some hints and techniques for explaining things to Managers and non-technical Business people.
Here’s a another quote from the book:
It often costs 100 times more to find and fix a bug after delivery than it would cost during requirements and design.
In most other professional trades there are well known rules, regulations and procedures for carrying out work, from plumbers to lawyers and building architects.
I certainly don’t want to see the Software Industry regulated in that fashion and thankfully I don’t think it would be possible. What David does is propose methodologies and techniques for taking us and the industry far closer to being a more professional body.
So when managers or developers say to me that they don’t have time to write their tests before writing implementation, I’m not surprised. They don’t have time to do test-driven development because they’re not doing test-driven development.
What the David means is that if you are constantly firefighting, fixing bugs, dealing with support calls, that you simply do not have time to implement test first development. If you did test first development you would avoid all the firefighting and bug fixing and have better software. It’s a no brainer to me, but so many places that I work in still go at full speed creating expensive to maintain software.
I often hear coders say “I don’t want to write tests; I want to write real code, to be creative”. Well the thing is by having clean flexible, bug free code you get to be more creative, you have more time to write great business features. With clean code your application will serve the company for a longer time and you’ll probably keep your job.
David, the author, recommends and describes in detail nine practices that you can follow. Here’s a very brief summary of the principles to give you a flavour of the book.
1) Say What, Why, and for Whom before How
Requirements sound like a good idea, but because of the way people tend to communicate in terms of how, they end up causing more problems than they solve.
And by the way, this is a problem in spoken language. It’s systematic of the way self-consciousness works and not exclusive to software requirements.
2) Build in Small Batches
Filmmakers don’t make a whole movie in one two-hour take; they shoot it not even, necessarily, a scene at a time but a shot at a time. When they have that shot, only then do they move on to the next. Though a director will always be keeping an eye on the movie as a whole, all efforts that day— or that part of a day— are on getting that one shot.
3) Integrate Continuously
Integrating software into the build can be painful, exposing bugs and other issues that weren’t visible before. Many software development teams try to avoid that pain by putting integration off until as late as possible only to find that integrating their code just before release is a lot more painful. Continuous integration is also incredibly valuable to developers as a feedback mechanism.
Software development is a social activity, one that involves a lot of communication and interaction— constantly learning, constantly interacting , and dealing with and talking about the abstract— so coordination among individuals is of vital importance.
5) Create CLEAN Code
An object should have well-defined characteristics, focused responsibilities, and hidden implementation. It should be in charge of its state; and be defined only once.
6) Write the Test First
Tests are specifications; they define behaviour.
7) Specify Behaviours with Tests
Developers get instant feedback about what works and what doesn’t, and this changes the whole dynamic of software development.
8) Implement the Design Last
Let’s write the test first. Let’s do the design last.
9) Refactor Legacy Code
Refactoring is restructuring or repackaging the internal structure of code without changing its external behaviour.
Just knowing that you don’t have to be perfect on the first and only pass makes anything so much easier.
For me the book is very readable. It was like having a one to one conversation with David, very down to earth and practical. I highly recommend this book if you want to get on the journey to creating far better software than is possible without the techniques outlined in the book.
The book is available from the following places.
Publisher: The Pragmatic Bookshelf
Book Published: 31 July 2015
Register at https://www.uksoftwarejobs.co.uk/SoftwareJobs if you are interested in receiving vacancy notifications that are accurately matched to your profile.
You can view some current vacancies at this link: https://www.uksoftwarejobs.co.uk/CurrentVacancies