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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>