Friday, February 24, 2017

Engineering Logs for the Product Backlog

I'm experimenting with how to better control and pay down technical debt. The objective of this experiment is to determine if we can align the payment of technical debt with asks from business stakeholders. 

Martin Fowler says this about technical debt:
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
The tricky thing about technical debt, of course, is that unlike money it's impossible to measure effectively. The interest payments hurt a team's productivity, but since we CannotMeasureProductivity, we can't really see the true effect of our technical debt.
The balance between the quick and dirty solution and the deadline is critical here. 

I include in quick an dirty, those outcomes which aren't as successful as we had hoped--those situations were once you complete the implementation you realize how to create a simpler implementation but you are simply out of time.

To improve balance,  I use an engineering log to identify potential improvements and align those improvement with requests by the business. 

An engineering log is a list of things we need to do to improve the product but which are not going to add to the value the business can extract from the market--refactoring code falls into this category. Importantly, my engineering log is not in my Product Backlog.

The basic idea is that a refactor usually needs to proceed the introduction of new functionality. This is  likely true if you are working on a legacy code base. In my view, this refactor is limited to the work needed to make the introduction of the new feature easy.

I use the engineering log to identify technical debt and include the payment of that technical debt in stories motivated by the business. 

This has the advantage of aligning the repayment of technical debt with a business objective, so code that's "good enough" isn't refactored until there is a new business requirement for that code. It has the disadvantage of adding cost to the business activity.

The disadvantage does have a business impact. I don't have a solution for that other than to write the code right the first time.

Saturday, February 18, 2017

The Accidental Creative (Stimulating Creativity)

Several years ago I read The Accidental Creative. I shared my thoughts on the book in The Accidental Creative (Book Review). I've also read Die Empty. Both are recommended reads.

The Accidental Creative includes a framework to ensure you remain creative over the long term. One part of this framework is to ensure that you "Curate stimuli that help you pursue creative possibilities." I've found that an effective way for me to remain creative is to review writing that I've enjoyed either because it's entertaining or because it's thought provoking.

Recently, I've begun to ensure that I select one piece of writing to read each week. This is always something that I've read in the past and I take the opportunity to revisit part of it over the course of a weekend. The result of randomly selecting a piece of writing that has influenced me in some way is profound. I find that I reconnect with some of the ideas that have inspired me and that I can make new connections on how to solve current problems.

Food for thought.