Keeping Software Soft – A Practical Guide for Developers, Testers and Managers
Why should we keep software soft? Because software should be easy to change. This is how this book from Jason Roberts starts. In the first page of the book Keeping Software Soft – A Practical Guide for Developers, Testers, and Managers, he writes “If you want to make developing software a happier, more enjoyable, and more productive experience this book is for you. Keeping Software Soft provides practical guidance on how to keep software as soft as we can. You can read from beginning to end or just jump in at any point and use as a reference guide.”
In around 150 pages, the book presents a panorama of modern software development techniques. The first part discusses coding patterns and principles such as the SOLID or Dependency Inversion. The second part discusses testing and continuous integration. The third part presents Agile approaches, including eXtreme Programming and Software Craftsmanship. For all the concepts discussed, examples are presented using C# languages and associated tools, often from the open source projects.
This book provides an interesting overview of modern software development practices. They will please every software developer and project manager that wants to improve his skills with both concepts and step-by-step process on how to implement them in the .NET ecosystem.
Reference: “Keeping Software Soft – A Practical Guide for Developers, Testers, and Managers”, Jason Roberts, Leanpub, http://leanpub.com/KeepingSoftwareSoft, 153 pages
Quotes
Software should be easy to change. Why should we care about keeping software soft? We don’t have to care, but we accept that software that is not soft may be more aptly described as “rigidware”. Some argue that over time all software ends up as a big ball of goo: hard to understand, hard to learn, and hard to change. We can respond to this argument in two ways: “why bother to even try and keep it soft then?”; or “let’s try to slow the degradation as much as we can”.
It is amazing how much time is spent in management meetings talking about how to improve delivery speed and reduce costs. It sometimes seems that agile software development is seen as a silver-bullet that can fix all the ingrained problems an organisation has. The strangest thing sometimes is how little energy is spent talking about improving the codebase itself.
Comments should always add value to the person reading the code. Comments that do not add value should be removed because they give the eye and brain more to process, only to be discarded or mistrusted by the reader.
Imagine reading a favourite novel, but with every sentence preceded by comments on why the author wrote it.
There are a number of reasons TDD helps to keep software soft:
Loosely coupled design: Because the codebase is evolved (rather than being designed up-front), lessons learned along the way feed into future tests and hence improve the overall design. Because the focus is on unit testability, code is more easily composable, reusable, and easier to call by clients. Inherent testability: Because you write the tests first, the implementation code by definition must be testable.
Regression Test Suite: A by-product of TDD is a set of well written, behaviourally-focused tests, with excellent test coverage. A good regression test suite is essential to help keep software soft: if there is a sense of fear about changing things because it is unknown what might break, refactoring is less likely to happen and the codebase will continue to degenerate into more of a mess.
Rhythm and Productivity: It is possible to get into a highly focused, highly productive state of being when practicing TDD. The “red, green, refactor” loop becomes second nature and there is zero friction. Over time a kind of “mental muscle memory” builds up and it is no longer necessary to think about which TDD phase is currently being executed.
