Eventually Consistent HTTP with Statebox and Riak
Bob Ippolito explains how to solve concurrent update conflicts with Statebox, an open source library for automatic conflict resolution, running on top of Riak.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Vikas Hazrati on Mar 30, 2010
Most Agile teams recognize the evils associated with technical debt. Just like a financial debt, the technical debt incurs interest payments. These are paid in the form of extra effort required to maintain and enhance the software which has either decayed or is built on a shaky foundation. Most Agilists recommend repaying the technical debt as early as possible. However, most Agile teams fail to monetize the technical debt, which can give valuable insights.
Once there is a monetary amount associated with the technical debt, it helps in answering various complex and tricky questions about the software. Israel Gat suggested that unless there is a quantifiable tab on the technical debt, teams generally ignore it to a level where the software decays beyond repair.
Beyond a certain level of debt, no good option is available. The code decayed to the point in which fixing anything in a hazardous proposition – every fix is likely to break something else.
He mentioned that there is a need to monetize technical debt and represent that as a liability on the balance sheet.
According to Israel, there are multiple benefits of monetizing the technical debt.
So what is the suggested way to monetize technical debt?
One of the ways is to use the technical debt plugin for Sonar. A technical debt analysis of a vast number of projects already is available on the Sonar live site. The cost is calculated by first figuring out the debt which is
There is a default cost in hour associated with each of the above violation. For example
Now, as per the defaults cost_to_fix_one_block = 2 hours. Assuming that the average developer cost is $500 per day and there are 8 hours to a day then to fix one such block $125 would be spent. Likewise, monetary analysis can be done for each violation to finally arrive at the total technical debt.
Thus, monetizing the technical debt gives a deep understanding of the hidden costs associated with the software. It is key for all Agile teams to keep monitoring their technical debt costs and keep them within the credit limits. Doing this helps in creating a product which is not only easy to maintain and enhance but also allows VC's to invest and customers to buy with confidence.
Five Key Practices to Agile ALM
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Agile Maturity Model Applied to Building and Releasing Software
In general I agree with the approach of quantifying the current anticipated costs of resolving the different types of technical debt (Martin Fowler: Technical Debt Quadrant) but there is also interest that needs to be paid incurred as increased costs to developing features. The size of the of the debt is likely to change over time - more code built on the code with debt making the final repayment larger.
I find this method not going far enough. A big bag of points representing the technical debt is nice to know approximately the amount of debt incurred on the project but from there you can't do a lot.
I prefer to have a much more detailed picture. Usually, I keep track of all the "debt" items (for instance, slow build, using an old framework version, ...) and for each one of them I have the following informations :
> A big bag of points representing the technical debt is nice to know approximately the amount of debt incurred on the project but from there you can't do a lot.
I kind of agree but then there is a need to identify the hotspots, define the credit limit and if we have a benchmark then it is easy to compare one project to the other in relation to the technical debt.
Once we have the numbers then it is easy to drill down to the root causes on the basis of violations taking the high $$$ ones first.
Please think of technical debt in the context of various personas/use cases. For a VC, the $$ amount to be "paid back" at a certain point in time might be all he/she needs. For the CEO, governing the software development process on an on-going basis (using multiple technical debt assessments) is a typical need. A CTO might be primarily interested in the Cohesion and Coupling metrics. A project leader might want to take a deep dive on the Design metric.
The state of the art these days enables us to give each technical/managerial level the most appropriate data. One can get as little of as much data as one desires.
In collaboration with my colleagues, I have carried out Technical Debt Assessments for the Cutter Consortium (www.cutter.com/index.html). We were able in these engagements to simultaneously satisfy the needs of quite a few levels.
Best,
Israel
Well if a manager takes a decision based on a metric rather then listening to the advice of people he trust, I'm not sure is a good manager. I mean either get your hands dirty to measure the debt by yourself or trust the people that can give you the information. Managing by metrics is a sure way to disaster in my mind. I mean it's not that I am against all metrics but I see them more as a warning signal of a potential problem rather than as a decision tool.
A good manager indeed does both - "listens" to the metrics and to the team. In other words, a good manager combines quantitative data with qualitative data.
Moreover, the team itself makes use of the metrics. I have seen eyes lit when metrics provided insights to the team.
Israel
Similar to how gold and trust underpin the US dollar (if you'll bear with me on this analogy), how do you determine if the "cost_to_comment_public_API" is worth including in the debt calculation? In other words, I (as a business analyst) am inclined to lean on the technical team to determine these factors. The next step would be to work with Product Managers, executives, or whomever to build their understanding of the metric and get their decision feedback based on the numbers.
Would you agree/disagree?
What we usually do in Cutter Consortium (www.cutter.com/index.html) Technical Debt Assessment engagements is provide a pie chart of the composition of the technical debt to our clients. A typical pie chart might look something like the following:
Coverage 41%
Duplication 22%
Rule violations 17%
Complexity 15%
Comments 5%
The strategy for coping with the technical debt is determined to a great extent through heat maps we generate as part of the engagement. Moreover, we construct a unified backlog that takes into accounts all work streams, not "just" technical debt reduction/elimination.
Jim Highsmith (www.cutter.com/meet-our-experts/jhbio.html) and I will be delivering a joint workshop on Technical Debt in the forthcoming Cutter Summit (www.cutter.com/summit/inreview.html). It will address in detail most of the good questions brought up in this thread.
Best,
Israel
... by assuming that you can divide a person's salary by the number of hours she works, then multiply it by the number of hours of a task to arrive at a "cost" for fixing the task. This doesn't work, because you don't pay salary employees hourly, and you hopefully don't cut their hours when there is less work, and you certainly can't throw a project to a contractor for two hours to get one block fixed. In other words, the organization pays the salary regardless of the technical debt, so the cost is elsewhere.
The only cost is opportunity cost. You need to know how the developers participate in the company's value stream and how the technical debt impedes the throughput of value. And if development has excess capacity (it either does, or it is the current bottleneck for value throughput), then the technical debt has no cost unless fixing is significant enough to lay someone off or repurpose them to a more valuable position.
First point. Developers compare technical debt to debt because generally they are not financially sophisticated. The executives on the board ( especially the CFO who you are trying to appeal to ) will understand that this is a "Sold Call Option". Simply put, The more popular/valuable the software, the more it will cost. When talking to execs, use the right financial metaphor. Debt to execs is a good thing.
My experience dealing with business executives is that they are pretty smart. If you explain the IT situation in terms they understand, they will be able to better "monitise" the effect than simply looking at developer costs. On a previous project we did a 6 man month effort to redesign the app to make it easier to test. The business execs understood the real impact of technical debt is not the trickle off extra developer resource, but rather...
1. The delay to implementing new features.
2. The risk of application failure.
3. The risk of introducing regression.
4. Other types of risk. (Operational, Reputation, Legal,...)
The cost of a bug to an organisation that takes down a customers operations if not the cost to fix the bug.
I would recommend engaging with your business execs in terms they can understand rather than present flaky numbers that would not convince anyone. The principles are more important than the numbers.
Bob Ippolito explains how to solve concurrent update conflicts with Statebox, an open source library for automatic conflict resolution, running on top of Riak.
Erik Onnen attempts to demonstrate that Java is still the best programming language for the JVM if simplified idioms are used along with proper tooling.
Approaches to integrating data are changing with emergence of cloud computing.
Michele Ide-Smith presents the lessons learned in the process of introducing UX principles and techniques into a large organization through a series of small steps.
Dave Farley and Martin Thompson discuss solutions for doing low-latency high throughput transactions based on the Disruptor concurrency pattern.
Rajneesh Namta shares his thoughts, experiences, and some of the critical lessons learned while implementing software test automation on a recent Agile project.
Dale Schumacher presents several patterns of actor interaction that can be used in collaborative programs written in any language.
Rúnar Bjarnason discusses Scalaz, a Scala library of pure data structures, type classes, highly generalized functions, and concurrency abstractions to perform functional programming in Scala.
10 comments
Watch Thread Reply