Yes Adopt DevOps But Don’t Forget The Pain of Re-Writes: My Biggest Software Lesson Ever

As we deliver more and more software projects in my part of Cisco Services, I have a keen interest in software development best practices.  And concerns on poor practices.  A few weeks ago, a software vendor made a passing comment on their next software release to me “It’s OK, in our new release we’ve re-written our product and we’ll have that new capability that was asked for”.  “What”, I asked, “You’ve re-written your code base?”

At that moment, the nightmares came back.  It almost sounded like the world was crashing around my ears.  Back to  2000/2001 when I was involved in a “re-write”.  And it was a disaster that become my #1 software development project lesson EVER!  So let me start this blog with a plea: sure adopt DevOps, adopt Agile Methodologies such as Scrum – but please please please – don’t forget some of the fundamental lessons from the past.

I’m a huge advocate for the potential improvements in software delivery – and alignment to customer/stakeholder needs – that  Agile and DevOps can deliver.  I wish we had these methodologies in place 10+ years ago when I worked in software product management.  However application of today’s best practices on your data center application development projects can still lead to failure if you make the wrong strategic decisions.

Around 2000, I was part of a team where the decision was taken to re-write the code base, in order to address future extensibility needs and work around some architectural issues.  While we did benefit from some powerful new capabilities, we also suffered from late deliveries, features were delayed, behaviours that customers depended upon changed and a whole new set of bugs and issues manifested themselves in customer deployments.  In fact we so ran out of time that we delayed porting an entire application to our new framework for 2 years.  As a product manager I really suffered from that decision!

Nowhere is this better described than in “Things You Should Never Do, Part I“, by Joel Spolsky (@spolsky on Twitter), published around this same time as we were re-writing.  When I eventually came across this seminal article a few years later, I could not believe how accurate his descriptions of the consequences of software code re-writes were.  In fact, he classes significant software re-write projects as “the single worst strategic mistake that any software company can make“.  When you throw away old code, you are throwing away so much knowledge of how old bugs were solved, of features that customers came to depend upon that you don’t even know they still use. “All-new code will be easier to maintain” you may here software developers say.  Yea, quoting Spolsky again – “As if source code rusted“. When in fact what they really mean is “It’s harder to read code than to write it”.

It’s just over 16 years (that long?!) since Spolsky wrote about what has (so far!) been my biggest software lesson ever.   Software development has moved on significantly since them.  However in the clamour to adopt agile/scrum and DevOps, don’t forget about these significant lessons from the past!

And back to the software vendor I mentioned at the start –  turns out I’d mis-interpreted his comment.  They weren’t doing a complete re-write – just a small part was being re-written, very much in line with Spolsky’s recommendations later on in his article.  Phew!

If you’d like to discuss this topic in more depth, please reply in the comments below or ping me on Twitter follow @StephenSatCisco.