John Heintz will be co-presenting with Israel Gat on Toxic Code.
I’m very excited, both to be presenting with Israel Gat (The Agile Executive) and to be going to Agile Roots this year!
We’ll be presenting on Toxic Code. This is a topic that I spent a lot of time on last year, working with a client to re-architect a system from the inside out while it was running in production.
Here’s the abstract of the session:
Technical debt had originally been conceived as an expediency measure – “a little debt speeds development so long as it is paid back promptly with a rewrite.” However, like financial debt, unrestrained borrowing can lead to a broad spectrum of difficulties, from collapsed roadmaps to inability to respond to customer problems in a timely manner, and anything in between.
Recent advances in source code analysis enable us to quantify technical debt and express it in $$ terms. By so doing, the software development process can be governed with unprecedented effectiveness. It is possible to constrain the “development on margin” mal-practice and avoid the toxic code phenomenon: technical-debt-to-value ratio of 100%. Moreover, even toxic code can ultimately be “marked-to-market” by reducing/eliminating technical debt.
The combination of Agile refactoring practices with technical debt analytics brings rigor to the software development process through:
- Providing quantifiable data about the overall state of the code and its value
- Driving the refactoring carried out through the Agile process from a risk mitigation perspective
- Balancing the technical debt work stream vis-a-vis other work streams
In the course of managing software development in this manner, your team will improve its design, coding, testing and project management skills. Ultimately, these improvements are the best antidote against accrual of technical debt in the future.
This is my first post describing Concrete Reflective Tools. I’m convinced they are a gateway drug to continuous improvement and cultural change.
Since I attended the Lean Kanban Conference in 2009 I’ve been focussed on understanding and finding more tools that fit the following criteria. This is my first time recording the thought on more than a note card (or cards… I keep scribbling down more variations.)
In this post I want to describe the basis for what these tools are, and reference some of the reasons they are so powerful. I’ll use Kanban as my running example, and plan to describe further tools in future posts.
Concrete Reflective Tools
I believe that “Concrete Reflective Tools” are the most useful and powerful change agents – they are easy to adopt, encourage learning from doing, and provide a path to deeper principles. I think they are a gateway drug that invite people into participating in the team learning process.
A Concrete tool is a not abstract (think naval gazing) and immediately can be at least rudimentarily applied by many people. (Read more…)
A Reflective tool is one that provides feedback to guide further use of the tool. An automatic thermostat both measures and adjusts the temperature, providing a closed-loop feedback system. (Read more…)
The Tools we are interested in are backed by principles. Getting from a practice to the guiding principles behind it offers immense leverage. (Read more…)
Why do other tools fail? A good idea (like a principle) can be too abstract and never acted on, a tool without thought is inappropriately applied, and thoughtful tools without foundation grow stale without change.