Posts Tagged ‘COHAA’
It is the Passion, Stupid!
If you harbored some doubts about having good time in Salt Lake City, please take a look at the picture above: Colleague Alex Pukinskis and I “caught” in a minute of pure joy during the Agile Roots conference. I don’t recall the subject we were discussing, but the picture speaks for itself even without a subject.
The relevance of the picture to Agile goes beyond “and here is a picture from the Agile Roots conference.” I actually believe that there is something special in Agile conferences of small to medium scale. These conferences are all about the experience. The program, the presenters and the venue are, of course, important. But, more than anything else these conferences are about savoring the community experience. The value is in the experience.
Over the past year I presented in four small to medium Agile conferences:
My sense is that in each of these conferences the passion of a small group of organizers was the key to success. This passion proved infectious – it affected presenters, participants and volunteers to form an experience that can only be expressed in the words “I wish I were there.”
While I meet many passionate folks in larger Agile/Software conferences, the experience is different. My guess is that it is a matter of “density of passion.” A few passionate organizers suffice to “ignite” a small/medium conference. This core passion does not seem to scale beyond a certain number of participants.
Toxic Code
“[The 100% loan-to-value subprime loan is] the most dangerous product in existence and there can be nothing more toxic…”
This quip by Angelo Mozilo, founder of Countrywide Financial, led me to coin the term “toxic code.” The code stops being an asset when it accumulates technical debt equal to the value it is expected to generate. As matter of fact, the code could become a liability when the cost to “pay back” the technical debt exceeds the revenues the code would generate. Such situations have been known to happen more often than we might realize. They occur, for example, when numerous customers develop elaborate business processes around poor quality enterprise software.
I will be exploring the topic in my May 27, 2010 presentation at The Path to Agility conference in Columbus, OH. Here is the abstract of my talk:
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
- Highlighting error-prone modules in the code and offering guidance to fixing them in a biggest-bang for-the-buck manner
- Pinpointing technical issues all the way down to the individual line of code level
- 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.
The Agile Executive 