Last year I created Codemanship as a vehicle for helping clients address one specific set of needs – the quality of their code. Agile has done a great job of addressing how software development’s managed and how teams can work together. It’s all good stuff, but sadly the great strides many companies have made in those directions have not been matched by great strides in the reliability and maintainability of their code.
This presents those newly (or not-so-newly) Agile organisations with a problem. It’s always been understood that one of the keys to being responsive to change is to create code that’s easy to change.
The things we’ve learned through decades of experience are factors in how hard our code is to change are:
- Readability – How easy it is to understand
- Complexity – Code that’s complicated is harder to understand, harder to test and more likely to be wrong
- Duplication – Duplicated logic (e.g., from copying and pasting code) has to be changed in multiple places, so multiply the overhead
- Dependencies – If a change to one part of the software will break many other dependent parts of the software (the “ripple effect”), we’ll think twice about making that change
- Test Assurance – If our tests don’t catch bugs, or if they take weeks or months to execute by hand, how will we know that the change we’re making hasn’t broken the software?
Codemanship focuses exclusively on these factors in the cost of changing our software, helping developers and teams to build up skills and habits that lead to code that’s more reliable, easier to understand, simpler, has less duplication, managed dependencies and much higher test assurance.
The disciplines that we find bring us these benefits most effectively on Agile and non-Agile projects are:
- Test-driven Development – drive the evolution of our software one automated test at a time, creating code that does exactly (and only) what’s required and building a comprehensive suite of automated regression tests that can detect new bugs as soon as they’re introduced
- Refactoring – continually work to keep the code clean (simple, readable, free of duplication and highly modular) by applying a well-defined set of safe, reversible code “transformations” and use automated regression tests to ensure nothing is broken
- Object Oriented Design – apply key principles of good object oriented design to effectively manage the dependencies in our code and localise the potentially costly “ripple effect” when making changes
- Continuous Integration & Delivery – frequently check in changes to the code to detect integration problems as early as possible and use automated build/test/deploy processes to ensure we always have a working system that can be deployed whenever the business requires, giving us more opportunities to learn from our users and evolve the software towards greater value more rapidly
I’ve been coaching software developers for the majority of my career, and over the years I’ve come to learn that the best way to teach someone practical skills like these is to give them as much practice as possible. This is why Codemanship’s approach to coaching and training is entirely hands-on and practice-based. Theory is useful, and I’ve read enough software theory to fill several Masters degrees, but Codemanship is about learning by doing. Beyond that simple philosophy, I hope what I do is more than just an exercise in self-reflection or theoretical instruction. Ultimately, if I’m teaching people to ride bicycles, I’m not going to get very far using PowerPoint slides, Panel Debate sessions or role-playing games.
Which is why everything I hope to cover with Codemanship will follow a very simple, practical mantra:
- Show people how I do it (e.g., post a screencast)
- Encourage them to have a go themselves (e.g., give them the source code)
- Give them tools to assess how well they’re doing it and where they might need to improve (e.g., good indicators of effective TDD and refactoring, useful techniques for assessing yourself while you do TDD/refactoring etc)
I wish it were more complicated than that. Because then I could probably write a book about it. But it’s actually really simple, and deliberately so.
The Codemanship training workshops are also designed to be more accessible. Publicly scheduled master classes will be run over weekends so that people don’t have to beg for time off work, and will be priced to bring them within reach of individuals taking responsibility for their own development and growth as software craftsmen, as well as small businesses and public sector and other non-profit organisations.
The Codemanship Academy has been running for a couple of years – since before I formed Codemanship Ltd, in fact – and has alumni from a number of client companies who have successfully completed long-term practice regimes in TDD and Refactoring, and who have proved their mettle through a gruelling one-day practical assessment (imagine a 5-6 hour driving test!) This was not a walk in the park for those who’ve done it, and they didn’t undertake it lightly.
The proof of the pudding is in the eating, of course. At one client site, analysis of their code on multiple projects before and after becoming Codemanship Alumni shows very significant improvements in test assurance and code quality. They also managed for the first time to deliver into production at a frequency this organisation had never achieved before. Continuous delivery is the Holy Grail of Agile Software Development, and our experiences are showing us that Codemanship can be an effective route to achieving it.
Imagine knowing that, at any time, you have software that works, that can be deployed and that can be easily changed based on the valuable lessons that deployment will teach you. This is what Codemanship is all about.
It’s an experiment, but an experiment that seems to be working. I hope that my gamble will pay off. I’m heartened by the increasing amount of interest I’ve been getting about Codemanship and the Academy, and software craftsmanship in general. My hope is that the era of clean, reliable code is finally upon us.