Today I am continuing a series of posts in which I will be reviewing some of the books which are related to the development of quality software. They may be specific to a certain technology or a software development methodology.
The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas is aimed at developers who want to write software systems that are easy to design, build, test and extend. Andy and Dave have revealed some of the basic practices that they follow during the full software lifecycle as well as project management and career development. I am an enthusiastic fan of their work and believe this book should be read by every developer early on in their career.
This book is also one of the easiest books I have ever read. The chapters are concise nuggets of information and I found myself flying through them and then stopping to reflect on what I had just read. Even though the chapters are grouped, each chapter is mostly independent of the others and it makes it easy to stop/start without having to recall the details of the previous chapters. So, the book is one that you can pickup months or years later and go right to a chapter that you want to reread without needing to read the whole book again. In that sense, it is almost a reference book.
Good-Enough Software
Of the many gems in the book, one of them is “Good-Enough Software”, which is about creating software that users qualify as being good enough. This approach can be capture by empowering users to be a part of the process and to shift quality into requirements specs. In the Agile world this is related to producing the simple design over the complex one with the caveat that the design must work.
DRY Principle
Another great idea is the DRY (Don’t Repeat Yourself) principle. The idea is to eliminate any duplication of functionality and define a single authoritative location for it. This creates consistency, simplicity and reduces many maintenance headaches. Not only is this important in a single software system, but with the invention of Service Oriented Archictectures (SOA), you can apply it across systems.
Broken Windows Theory
One further nugget is the idea that leaving “broken windows” (bad code) unrepaired in a system will eventually compound and pretty soon you will have a whole system (building) full of broken windows and a team that doesn’t mind throwing stones occasionally. The idea is to take the time to repair your code as soon as you see an issue so that the software doesn’t deteriorate.
Consider this to be a must have for your collection and get a copy of The Pragmatic Programmer: From Journeyman to Master today.
Recent Comments