Performant Code for Business

Screen Shot 2013-09-20 at 11.51.59

How do you produce code that performs well for a business and IT? Yet again I see another business in the process of re-writing their platform…. and I wonder why. It’s a common pattern with the common set of reasons.

I remember an old question at a previous company: “What is the most important aspect to coding” … (Multiple choice answers). To which almost all answered: “Working correctly”.    I think this is incorrect and a widely held belief for a number of reasons.  My preferred answer was “Well Documented” … meaning “Well structured, internally annotated and easy for others to understand”.   In essence, I think its more important for a codebase to be ‘broken but easy to fix’ rather than ‘working and hard to understand’.

This is a key lesson I learnt during my formative development years.  Producing 1000’s of lines of code, with no debugger (only a core dump explaining what line I had failed on).  I also learnt that I quickly forgot what sections of code did what if I came back to them a week later (or a few hours later with 6502) – so I structured my code in a way that was easy for me and others to understand.   I was made to do pair programming before it had a name (thank you ICL) – and although I resisted at first, it shaped my thought and practices from that point on.   I also learnt that code naturally gets complicated no matter how simple your building blocks start – and conversely if you started off with something complicated it would fail/be hard to maintain/produce a load of bugs/(insert other costly symptoms here) ..  to different degrees of quickly.   Which brings me in a round about way to be biggest intangible cost I still see in the industry today – Code that works (Kind of) but isn’t easily understood.   This results in …

1)   Developers wanting to re-write it (they want to re-write everything anyway)

2)   Developers scared to touch it because it does something they don’t understand but it is used by everything else (If a developer says this, be truly scared)

3)   A complete re-engineering effort required to replace that entire section of codebase

4)   Errors on live – resulting in substantial engineering effort to diagnose the cause

5)   An inability to enhance the codebase easily to the developing needs of the business … (It’ll take X months to make that small change)

6)   The list goes on …

All in all the cost associated with code that isn’t easy to understand by others is exponential.  I’m not just talking about coding standards – its structure and flow.  I was recently asked “C++ or Java..?”.  I come from a C++ background, but now prefer Java as a language for teams – One of the main reasons is its harder to write poorly understood code in Java than C++.  Its also one of the reasons I dislike JavaScript – its too easy for others to write gobbledegook.   You can be a magician and make code do what you want it to – but it’s absolutely useless to the business when you move on.

Developers are part of the problem – I think most of this can also be attributed to PM’s and Scrum Masters that don’t understand the value of well understood code.  They focus on delivery, milestones and RAID logs (Risks, Assumptions, Issues and Dependencies).  Developers then focus on delivery and don’t have the time to peer review, inspect and re-engineer or refactor as they see fit.   They aren’t given the opportunity to improve the quality of what they produce.  Quality in code is iterative.

Maintenance can broadly be broken into the following subsets:

  1. Root Cause: How easy it is  to locate the elements we want to improve or fix by others
  2. Change:  How much work is required to implement a modification by others
  3. Stability:  How many things break after our changes by others
  4. Testing:  An ability to validate our modifications by others
Pair programming solves this by default, but I’m yet to see an organisation embrace this – its viewed as too expensive and abstract.

There is a fundamentally human aspect to this.  We all recognise quality in certain brands – VW vs Skoda.  We also know the futilely of false economy’s when building stuff we can visualise (e.g. House).  But why not with software….?  I think its because development is still opaque and hard to measure (in terms of maintenance quality) to those outside that domain.  What’s the answer ..? I’m not sure … I guess the first step is awareness, then devising a method to measure maintenance quality – only when something is easily visible and produces a metric does it become important to those that it is opaque to.  Up until then poorly written software (Agile or Waterfall) will continue to produce the same set of issues and perpetuating circumstances that result in high demand for those that write it.

Key Takeaways: 

  1. Producing Quality software is iterative – give dev’s the time to do this
  2. Focusing on just delivery and getting ‘something out’ is a false economy
  3. Black Boxing all development is bad, we need to white box some aspects and communicate better to those that oversee
  4.  ‘Broken but easy to fix’ is better than ‘working and hard to understand’
  5. A major medium & long term intangible cost incurred to business is software which is written and not easily understood by others

Jason

One thought on “Performant Code for Business

Leave a Reply

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