Writing a short article about that topic turned out to be much harder than expected since there are so many things to mention. Nowadays, a young software developer does not automatically know “Extreme Programming” anymore. She may have heard of Scrum, but typically she doesn’t know XP. Our industry is so short-lived that people don’t read books that are 10 years old. So we are destined to see the same mistakes being made again and again.
In 2008, I participated in the Agile conference in Toronto where Robert C. Martin (“Uncle Bob”) gave a brilliant keynote which was a plea for test-driven development. He told the story of Ignaz Semmelweis, the “savior of mothers”. In his early years as a doctor, Semmelweis worked in an obstetrical clinic in Vienna. Being a good observer, he discovered that the mortality rate in a maternity clinic could be drastically reduced by making doctors wash their hands when moving between the autopsy ward and the maternity ward.
What is obvious nowadays was heresy in the 19th century. Physicians take the Hippocratic Oath. They are meant to save lives. Still Dr. Semmelweis told other physicians that they kill mothers by not washing their hands. Obviously, he was not a diplomat. For decades, doctors didn’t follow through. Nowadays, they all wash their hands.
Uncle Bob’s conclusion was not especially diplomatic either: if you want to be a professional, then “wash your hands”. Use TDD and write clean code!
Let’s not waste decades in our industry by (still) not adopting TDD.
Ten years earlier, in 1998, I was at the ECOOP conference in Brussels where Jim Coplien questioned the crowd of PhD students about the Liskov Substitution Principle (LSP). No-one knew about it – under that name. He was baffled and started to explain – then many of us jumped in, since of course we had understood OOP, subclassing, covariance, contravariance, etc. We just didn’t refer to it as the LSP. Back then, the guiding principles for good design and modularity were: low coupling & high cohesion.
When I read Uncle Bob’s book “Agile Software Development. Principles, Patterns, and Practices” a few years later, I gladly accepted a few more acronyms. Since then I kept handing out laminated index cards in my Software Architecture courses with his principles of Object-Oriented Design and Package Design:
Those principles offer much more concrete advice on what to avoid and what to strive for.
Nowadays, I can simply tell young software developers to become clean coders. Still not everybody uses TDD all the time. That’s why I want to reinforce it: TDD does benefit you and your clients. Wash your hands. There’s no excuse. Otherwise, you’re just not professional. Otherwise, you’ll deliver crappy software. You’ll potentially kill people.
Don’t underestimate the power of TDD.
We are living in a world of interruptions. TDD gives us very short feedback cycles. It allows us to focus on a small part – thereby reducing the time it takes us to get into the flow again, after an interruption. By practicing TDD, you can drastically reduce your costs of interruptions.
Instead of writing about “100 more things”, I’ll point out just one more thing:
Use inclusive, low tech tools to collect feedback as early as possible.
In an early stage, it’s more important to collect information, and to uncover hidden assumptions and misunderstandings. Low tech tools like pen and paper or flipcharts are easy to use by anybody, anytime and anywhere. High tech tools might give you more precision which is not important upfront with that much uncertainty everywhere.
Use techniques that are intuitive and “inclusive”, i.e. where everybody can easily participate. No need for a special piece of hardware or software to contribute in the process. No need to learn the “method”.
A few examples for low tech tools and techniques:
- System context diagrams on flipcharts: to discuss “what’s in ⇔ what’s out” with your stakeholders early on
- Architecture overview diagrams on flipcharts: to assure that you and the IT personnel on the client side have the same ideas about the architecture from the beginning, to quickly explore different variants
- Usability tests via paper prototypes: to exercise your system long before you write the first line of code
Such low tech tools and techniques will result in more immediate and diverse feedback.
Once you know the goal, the persona and the user stories well enough, of course, use the best possible tools (no need for low tech tools any more) and develop clean code with good internal structure that is fit for the purpose.
That’s the end of this episode.
I know, a hard read, a hard write.
It is difficult to “do it right” – on the other hand, it’s then also so obvious (and hard to explain) why you do what you do.
Fortunately, we have so many clean coders in our team and we do a lot to get that knowledge and experience to all new team members.
… which is the topic of the fourth leaf.