Sunday, August 23, 2015

Technical Debt and refactoring



Do not refactor for sake of paying Technical debt.  Refactor the code if it has business value. Hidden message: Do not pay Technical debt if it does not enhance value of software.

Perfection is mirage. Good enough is good.

Saturday, August 22, 2015

Every day indicators of Technical debt

  • Let’s complete testing in next sprint.
  • Lot of “To Do” and “Fix Me” in code.
  • Only Sonia should touch this code.
  • Just copy paste this code.
  • In which class we store password.
  • Unit test cases !! are you joking.
  • Do not worry about documentation for now.
  • I can this in two minutes.
  • It is OK for now. We will refactor later.
  • Let’s do this way, it is faster to do. We will change it later.
  • We cannot implement this feature in current technology of product.
  • The velocity of team is deteriorating without change in team composition or technology shift.
  • Old versions of libraries in use.
  • Frequent problems in production.
  • Known bugs
  • Never say no to features
  • Project in IDE has lot of warnings.
  • At run time we get this warning
  • Our Ops guys are so good, they can make anything work
  • We have always done this way
  • Coding guidelines!! Forget for now.
  • If we release by this Friday, approximately number of 20 bugs will be there. If you can wait till next week bugs will be 5.

Friday, August 21, 2015

Technical and Financial Debt



Most of us are familiar with Financial Debt. Let’s try to draw analogy for Technical Debt from Financial Debt.

Short-term Debt
In financial domain, short-term debt is used to finance temporary cash flow like financing of raw material for an order. As name suggest, it is expected that short term debt will be paid back on priority, generally short-term debt is expensive.

In technical domain equivalent short-term debt is debt assumed to ship code to meet deadline with known bugs, having understanding that immediately patch will released to fix the bug. Second example is hot fix for a P1 issue.  In all of cases, focus is – let’s ship/fix the code NOW, resolve the issues in immediate future.

Long-term Debt
In financial domain, long-term debt is used to finance long term goals of enterprise, generally investments like acquiring plant and machinery, acquiring competitor, etc. Generally long-term debt is cheaper to service. Long-term debts are assumed for strategic reasons.

In technical domain equivalent debt is writing a code which is UNIX specific as most of the prospects are on UNIX. It is possible that long-term debt is camouflaged as strategic architectural/design decision. When long-term debt is camouflaged as strategic architectural/design decision, never paid but does not mean it is free. There might be some opportunity cost associated with it as never approached market segment.

Interest Payment
There is no free lunch. Once you assume debt, you need to pay back it with premium. As a business and/or technical person, you need to decide, can you afford the interest and absolute amount of outgoing benefits. 

Technical debt can be pay backed regularly (with each sprint), in spurts (with each release), in one shot (bug fix release). You may also decide not to pay debt at all in case of end of life products.

Expected Cost/Value
If you purchase a car now, you may commute farther for job, so potentially earn $2,000 extra each month. The car price is $10,000. If you delay purchase of car, you may not have promised job. Are you willing to assume debt to purchase car?

If you do not release product now (before FIFA cup), no one will buy it. Are you willing to cut corners to meet the deadlines?

Opportunity Cost
What else can be done with this money/resources? Instead of following the strict coding guidelines, can I cut corners and release the product early and utilize saved (?) resources to release new features?

Present Value
Your startup needs this particular sale now even with lower margin.  Present value of debt is function of Expected value and \opportunity cost.

Debt Service Coverage Ratio
Debt service coverage ratio (DSCR) is the ratio of cash available for debt servicing to interest, principal and lease payments.

In Technical debt realm, DSCR may be defined as ration of resources available to develop software to resources spent to service technical debt.

Credit Rating
Credit rating of any individual or business depicts confidence of market in paying back the debt. 

In software development domain, credit rating of a team or product symbolizes the capacity of accruing/acquiring new technical debt.  Team/Product having less technical debt and specifically less unintentional technical debt has capacity to acquire more technical debt.

Acquired debt
A team may be very careful in assuming technical debt. But say due to product acquisition or bug in library used, team gets technical debt.

Minimum sprint payment
Team may decide to pay back technical debt in regular sprint cycle to manage total debt in reasonable limits. This is achieved by choosing debt paying stories in each sprint.

30 days, same as cash
Sometime paying debt immediately does not result in any interest. For example, in few initial sprints, there is no continuous integration.

Retiring Debt
Unlike financial debt, when a product is retired, all technical debt also retires. You do not pay it J

As product reaches end of life, cost to pay technical debt may not be justifiable.

Parting Notes
Unlike Financial debt, you may not pay back technical debt. In some cases paying back technical debt may not have any technical & financial justification. For example Technical debt in case of:

·         product is reaching at end of life
·         part of code which is not evolving/changing 

need not to be paid.  Therefore, In case of Technical debt probability should also be a factor while paying it back.

Thursday, August 20, 2015

Technical Debt – Business & Technical point of views



Business and Technical folks view Technical Debt from different perspective.  Business folks associated with a project view Technical debt as tool to:

  • shorten the go to market time
  • preserve the startup capital
  • minimizing upfront development expense


Technical folks, view Technical debt from entirely different perspective.

  • Ignorance of dev team
  • Doing under engineering to avoid over engineering
  • Surrender to business pressure



What do you think?

Wednesday, August 19, 2015

Technical debt - How to pay?



Like tax and death in life, no team can avoid technical debt in software development. Therefore we need means to manage it. To manage technical debt three broad strategies are used:

  • Buffer stories
  • Buffer tasks
  • Technical debt paying releases

Buffer stories
Team can set aside approx. 10% of velocity per release for technical debt paying stories. This will set the expectation of business stakeholders in each sprint and help to maintain relatively technical debt free software.  These stories are created by dev team. If story is focused on function debt, let PO drive it.

Buffer tasks
During task break down (in Sprint planning meeting), if required, technical debt paying buffer task is created and budgeted. This approach ensures ease in scheduling but also raises the risk of spending resources on not so important things.

Technical debt paying releases
Instead of paying a little in each sprint, team may decide to devote larger chunk of resources periodically (generally every 6 month). This approach is works well where sprints are going on for multiple years. In this approach a risk of mounting debt always lingers on. Team should avoid Technical debt paying release just after a frenzied, time-critical and feature heavy release.

I am sure there are more ways to pay back debt.  I like to hear from you more.

Thursday, July 30, 2015

Value Driven Support and Maintenance Model



Generally in most of the enterprises, we have support and maintenance model in which a fixed team is maintained to cater support and maintenance needs (e.g. enhancements, bug fixes and other small day to day tasks). In this model most of the team’s capacity is engaged in tasks which can be automated (e.g. regular reporting) or can be delegated to business personnel with training and nice interface of application ( e.g. adhoc reporting).  Remaining team capacity is used in bug fixes and enhancement. This facilitates creation of personal fiefdom of support managers. Look around in your organization, be is web site, ERP or any other enterprise application you will see the same picture.
Is there any alternative to this tried and tested model. Even, ITIL support model is based on this paradigm.

What about a model where there is no support and maintenance team. Once application is delivered to end users, no one is working on it. Bug reports, enhancement requests keep on piling up. Once pile reaches to a predefined level which warrants attention (or capable of delivering a minimum value or critical fix), support and maintenance team is created (certainly Scrum or some other Agile methodology) and pile is reduced to minimum acceptable level. Once again cycle is repeated.

I like to call this approach as Value Driven Support and Maintenance Model (VDSaM Model).  VDSaM Model will help to control cost in control and also will force team to think long term design interface and reporting requirements in the design of software from beginning. 

What do you think of VDSaM Model?