"If it ain't broke, don't fix it" ???

-

It’s a pretty nifty saying, isn’t it? Unfortunately it only works for when


  1. You don’t understand how it works, and/or
  2. You’ve got too many other things to worry about.



The problem, of course, is that if you don’t understand how it works, how do you know it’s not broken? Murphy’s law being what it is, you know that the break will reveal itself at the single most inopportune time, right?

Ok, that’s not actually fair to Murphy. Broken parts tend to fail under stress, and fail disastrously at that. And stressful situations are typically the situations in which you need the largest amount of cognitive bandwidth to deal with the ongoing chaos, and the last thing you need is something (critical!) rupturing on you. So yeah, of course, the break will reveal itself at the worst possible time.


And that is kinda the point here - if you don’t understand the mechanism, saying “if it ain’t broke, don’t fix it” ‘cos it seems to work is, quite possibly, the worst possible thing that you can do.


Mind you, there is a bit of a meta point here too in that there is one consistency to technology - if it isn’t already broken, it’s just a matter of time before it breaks. The fact that it isn’t broken now doesn’t really have much bearing on whether it will continue to not be broken into the future. And we’re right back to the previous point - when it breaks, it will quite probably break under stress, and (back to Murphy!) the break will happen when you least can afford to have it happen.


The bottom line to all of this - every time you hear yourself say “if it ain’t broke, don’t fix it”, take a long hard look at why you said that. And if there is even the slightest hint of escapism, denial, or ignorance around the statement, be afraid, be very very afraid.


Oh, by the way, I wasn’t ignoring the “you’ve got too many other things to worry about” category. It’s just that 99 times out of 100, this happens because you’re choosing the “least worst” of your options, i.e., you’ve got 5 gallons of problems, and only a 3 gallon bucket to deal with them. In that case, you need to get very good at prioritization, and as soon as you have the opportunity, address the remaining 2 gallons

Comments

Post a Comment

Popular posts from this blog

Erlang, Binaries, and Garbage Collection (Sigh)

-
Image
The nice thing about garbage-collection is that it is makes memory management absolutely transparent to you Of course, the above is true right up to the point when it stops being transparent, at which point it does a phase change from nice to clusterf**k of biblical proportions .  There are entire posts, books, and suicide notes that have been written about this, and I have no great desire to add to them, save with the minor comment that paranoia about garbage-collection is still justified , albeit only in the edge-cases for most people. That said, I'll give you that Erlang GC is in many ways much, much better positioned in this regard than, oh, Java, but it still rears up and bites you in the butt when you least expect it. ( More information about Erlang's GC vis-a-vis Java here , and Jesper's truly excellent description of Erlang's GC here ).  A story from the past should serve to illustrate this. Once upon a time, in a magical land far far away - well, Her
Read more

Visualizing Prime Numbers

-
Image
From Jason Davies , we have El Patron de Los Primos , probably one of the coolest prime number visualizer that I've seen.  For every Natural number, he draws a periodic curve that intersects at that number and each of its multiples.  Needless to say, prime numbers are touched by only two curves (itself and 1 ). You can scroll to the right, and move up the prime food change. (The image above is a screen grab.  Go here to see the actual thing)
Read more

Its time to call Bullshit on "Technical Debt"

-
Image
Seriously. You know what " Technical Debt " is, right? Ok, heres the (official?) Wikipedia definition   Technical debt   (also known as   design debt   or   code debt ) is a   neologistic   metaphor referring to the eventual consequences of poor or evolving   software architecture   and   software development   within a   codebase . The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future. And in this - somewhat purist - sense, " Technical Debt " is absolutely valid. The problem arises in the way it is almost invariably used, viz., as an excuse to not do something. Herewith a simple exercise - the next time you hear someone cite &quo
Read more