Agile software development methodologies highlight the importance of continuous learning.
Teams can take advantage of having small iterations followed by retrospectives in order to progressively get better, smarter, and learn from their errors.
And theoretically eventually, the team will get to a point where its members can efficiently work together, where every team member can produce high quality and maintainable code, where the sky is perfectly blue, and the sun is shining.
Yeah.. eventually, we will live in a perfect world…
However, there is something that bugs me with this approach: by letting the team “auto-organize itself to discover its own solutions to its highly specific issues”, we actually end up having the team re-invent the wheel to solve the always-same problems that every development team faces. Yes, guess what ? At some point, sometime in the future, the team will discover that it needs to write decent OO code, that it needs to have a decent coverage of carefully written tests or executable specifications (TDD, BDD), that the domain needs to be properly externalized from the technical code (DDD), that it needs decent modelling skills, that IoC enhances the testability of their code,that it needs to decouple the code with small modules and services, that junior developers need to be coached by senior ones, and so on…. Or.. the team won’t discover it, because the project will lack money at some point, and everything will need to start from scratch again.. Wao! so productive !
So, the question is.. What can we do to reduce the duration of the learning curve ? How can we make sure new projects can benefit from the experience of previous ones ? That’s exactly the debate we have had with a few guys from Pyxis Technologies (http://www.pyxis-tech.ca).
When dealing with organizational coaching (Scrum, Agile), the idea of imposing engineering practices (XP, DDD, ..) was totally rejected by a few people that had concrete examples of failures. Most developers have a great ego and still haven’t learned enough of programming to just admit they can learn more from others.
So, what are the other ideas that were thrown ? Everyone seemed to agree that most of the problem lies in the beginning of the contract: every Scrum/development contract should start with an initial diagnostic, that states the technical debt accumulated by the team. This can then serve as the basis of an execution plan. Most of the challenge lies in linking the technical recommendations with business objectives, and clearly explaining the value of these engineering practices to the product owner and stake holders.
Once the product owner (PO) agrees with the values and the vision, most of the job is done. The team is supposed to work on the PO’s priorities, and the technical coaching will be seen as a wonderful help to meet the business objectives.
Of course, in order to achieve this, a few things will need to be sorted out such as compiling the list of the best practices that we embrace. But nothing impossible here, I guess.
Is that enough to learn faster ? probabably. Is that enough to learn wayy faster ? probably not ! We will still see crappy code being produced for months (years ?), and projects failing because of that. So, what can we do to DRASTICALLY improve the quality of code that is produced by those teams ?
nice post.
The 1M$ question I have is how do we measure that technical debt in such a way is to make it clear that its not just some off the cuff number that the (probably defensive) development team will try to discredit, and will at the same time speak to a product owner?
Different measures have been proposed. (1) James Shore suggests the spag (http://jamesshore.com/Blog/An-Approximate-Measure-of-Technical-Debt.html), (2) I (and you) have disscussed the the gap between today’s code base and and its envisioned production-worthy future, (3) even measurements of the impact on a teams velocity. All seem like good ideas, the first and last at least use measurable metrics. The second is tricky, I have seen teams very quickly deploy crap into production environments – sometimes said crap does not smell for quite some time.
I still can help but feel that in a concrete sense, the idea of technical debt is as hard to measure as its nemesis “clean code”.
One thing that I think needs to be done is for our industry to stop glorifying “the hacker”, the lone wolves of old who where praised for being able to decipher the cryptic messes they themselves wrote. We should start praising those who write code their grandmothers can understand (or at the very least a SME). This shift in culture at least will open the door to an era in which young developers stop being proud of what they can read, but rather what they can write.