Category Archives: Lean

The Anti-Programmer

When I think back to my more hands on development days earlier in my career, if someone asked me what my job was, amongst other things I would have said….


  • Add features that provide business value
  • Write code to provide solutions to customers problems


Both of these statements include adding something or providing my input in order that someone else (the customer) gets value out.
This is not what I have been doing more recently. In the last couple of weeks and ongoing I have been removing something or retracting someone else’s input in order that someone else (the customer) gets value out.
Surprisingly and maybe counter-intuitively this has given me great pleasure.


  • I have been deleting code.
  • I have been removing excess complexity.
  • I have been reducing the number of features in a product.


This is why I have been an “anti programmer”.
This is certainly what all programmers or engineers of any system should be doing, and this gives me as much pleasure as adding to it does.
This process still involves the same amount of rigour and control. Whether you are adding or removing code you are still making changes to the system so you need to have the controls in place to ensure that you haven’t changed the system in a detrimental way.

This process has benefits both internal and external to the business.



All code that exists contributes in some way to its complexity. When a developer comes up to speed on an area of the product or code base they will have to understand why that code is doing what it is. Hopefully this will be fairly easy to understand but there will be a degree of ramp up. Less code can mean less to understand and therefore less complexity.
The testing of this code manual or automated will also incur a cost. Manual testing will involve the team understanding the feature from a users point of view and even automated tests however quick will add some delay in the feedback loop in the time it takes to exercise those tests.



The customer sees this feature and wonders how it would be useful to them. “How can i use this software to add more value to my business?”If there is more than one way to solve a problem using your software they may spend time deciding which one is best.
Pruning your product should be a constant process. A feature may have had been adding value at some point but as the software grows over time this may not always be the case. Constantly looking and measuring your customers usage of your product overtime will hopefully highlight areas that are no longer needed or marginally used. These unused features become a from of waste like the dead heads on your rose bush. These should be pruned/removed/retired/culled however you want to phrase it.

There’s a great sense of relief in removing unused features and it should be encouraged.

Keep it Lean.

Give me some slack

I caught a great interview this week with J. B. Rainsberger. In this interview he gave to Marko Keba of, J.B. talked about managing slack. Naturally this got me thinking about what I do within my team to create this slack. If you want to listen to the interview that inspired this post then it may still be available here and its well worth a listen.


Why slack off?

In the interview J.B Rainsberger spoke about how creating slack and performing tasks that are not directly attributable to features with business value can help reduce volatility in the cost of adding features of time. By working at full capacity continually your teams will not have time to improve or maintain their productivity. The code design if not maintained and nurtured over time will exponentially decrease causing features that seem relatively simple in complexity to become bloated and far more difficult to implement than expected. This will clearly effect both developer productivity and your teams ability to react to the market, delivering business value into production quickly.


What slack should consist of?

J.B  doesn’t go into details around what practices or tasks should be performed within the slack as these will be specific to your environment and business but he does mention techniques such as Value Stream Mapping to identify where the problems are, where the bottle necks occur and where the extra work is hiding.


How we negotiate managing slack

The tasks that you perform and how much time you spend doing this as developers should always be negotiated. You will need to justify your investment in these tasks and learn how to sell these ideas to your Product Owners. Hopefully your Product Owners will already have an awareness of the pay-off that this can give but just in case, you will need to be prepared. This may be a challenge as the immediate paybacks may be difficult to see.

My approach to this was to negotiate a percentage of time each sprint, creating slack to perform these tasks. By doing a small amount every sprint you reduce the impact on your teams velocity as the velocity will naturally balance to the incremental effect. This also brings about a metronomic habit to continually take care of your code base, call it gardening if you will. The iteration based pruning is far better than a big bang approach wiping your team out for an entire Sprint as the big bang approach is not sustainable and the important part of providing slack is that it is a continuous process. Additional benefits come naturally with all processes that we do in small batches.


What activities are we doing when we are slacking off

As the team go through their daily work they should be automatically recognising work items that would be considered technical debt. These items often build up as a result of not having any slack, going too quickly or a concious decision to take short-cuts in order to deliver on schedule. (Reduction in quality over time or scope) These items are prime examples to improve given some slack. Your team may already have a backlog of these items.

In the same way we refine the backlog our team refines the event log messages. The event logs are one of our views on the health of the system so it is important that we can judge this at a glance. Removing false positives and re-prioritising warnings to errors and vice versa are all things that can be done to improve the system both for developers and for our operations team. (DevOps). Refining these items highlights work that needs to be done. This work is not always seen as being directly attributable to business value and is therefore a great item for slack.

Tests should always be considered production code and in the same way you will build up technical debt in your test code f you don’t continually take care of it. During time set aside for slack testing is a great spot to tackle. Improving the readability, reliability, coverage or general design are all must dos when slacking off.

The more often you give yourselves time improve the easier it will be and the less likely you are to fall into the trap of bloated estimates and never ending stories.