

Is Your Software Rotting? - sahil_lmn
http://pragprog.com/the-pragmatic-programmer/extracts/software-entropy

======
yzhengyu
As I see it, software rots because though maintenance is a permanent and
recurrent cost, the ultimate cost for it (codebase abandonment) lies in the
distant future.

By the time it is needed to flush the big ball of mud down the toilet, the
people responsible would have probably gone on to better things. Or to another
big ball of mud project in another company.

I guess it is a case of misaligned incentives.

Personal experience:

In one of my previous positions, as the most senior engineer on board, I was
asked to survey our system to determine whether it was suitable to be the
basis of yet another deliverable project.

I spent a month doing this, wading through the big ball of mud which came into
existence over the course of five years and delivering three projects (barely)
using this codebase.

My assessment was pretty honest and I asked for time to attempt paying down
this technical debt to a reasonable level before we go on ahead to use the
code base on another project.

Management, at the end, did not authorize the "debt-repayment exercise".
Perhaps I should have pushed harder but I was told it was "above my pay
grade". At the end, they began insinuating that I was responsible for it all.
Simply amazing.

Soon, I bid them adios. As I understand it, the code base has been discarded
in favour of complete redevelopment. Which will take another two to three
years.

------
nowarninglabel
One corollary to this, working off the same metaphor, should be that sometimes
it's easier to just come in a redevelop the neighborhood than to try to fix
its problems. This is my plan for a piece of software where making small fixes
in it, only leads to exposing other more dire and deep-seated issues.

~~~
hammerdr
I would argue that developers will tend to have a "this is too much Bad, lets
rewrite it" perspective.

It is good to temper our desire to write it our way with the realization that
software that is hairy is often because of hairy business requirements. A
steady application of clean code boyscouting is really the only solution to a
large system with unknown but inevitably complex business rules.

Edit: But, sometimes, it is better to rewrite it. Usually this is by rewriting
subcomponents or "rewriting" software by create a new stack for a new feature
that'll phase out old software.

~~~
mullr
"Code boyscouting" is an excellent way to put it.

@yzhengyu's experience is representative of my own, though without the same
degree of politics. Even in conversations with those who should know better,
it's nearly impossible to put technical debt payback ahead of new business
requirements. Attempts to quantify it (additional time to deliver = lost
opportunity = money) are fuzzy at best.

I really think the only practical way to combat code rot is at the leaf nodes,
without telling anybody. Perhaps we ought to have a secret oath that all
developers take. "On my honor, I will do my best, to do my duty to Knuth and
my Profession and to obey Postel's Law..."

~~~
hammerdr
We can all certainly try :) And, fighting in the trenches every day (taking
some time to do some refactoring instead of calling a feature done) is a great
place to start.

However, the code rot really needs to be understood by the upper management of
IT. Having a solid grasp of technical debt, how much it hurts, how much debt
you can take on and how long it takes to pay that down is the _responsibility_
of any manager of IT departments. If management doesn't understand this, they
are setting the products up to fail every 3-5 years no matter how hard the
developers work at the leaf nodes.

------
chris_dcosta
I can't think of a project that I've worked on which hasn't suffered from
companies not understanding that you cannot build without a structural plan of
some kind, and that the person charged with making that plan needs to know
what they're talking about. Far too often ambition outweighs actual detailed
knowledge of the subject. Whilst I accept that not every technician is cut out
- or wants to accept the responsibility - there are those who take their work
seriously enough to know the difference it can make. Of course I blow my own
trumpet in this respect, but it's surprising how often the pay grade above
choses to go against all advice and evidence, and then comes back three months
later and asks for a work around to fix the mess they got themselves into. In
a week, just to save their scawny ass.

------
jfb
As soon as it's in use, it starts to rot. This is the hardest challenge in
writing software.

