Slow down in order to “speed up”: Pay continuous attention to Technical Excellence
Share on twitter
Share on facebook
Share on linkedin
Share on whatsapp
Share on email

In 1938 Marjorie Courtenay-Latimer, a curator at the East London museum in South Africa, received a phone call from the local docks. A fisherman had landed a strange-looking fish. He knew that Courtenay-Latimer was always interested in seeing unusual specimens and thought that she might like to come down and view the catch.

 

Reaching the quay, Courtenay-Latimer opened the net and picked away at the layers of detritus. What she found, she said, was the “most beautiful fish” she had ever seen.

 

Courtenay-Latimer had the fish stuffed and showed it to ichthyologist J.L.B. Smith. He immediately identified it as a coelacanth, a fish that was believed to have been extinct for 65 million years. Courtenay-Latimer had found a “living fossil,” a living part of the evolutionary record.

 

Biological evolutionary theorists used to separate into two schools: those who believed that evolution proceeded gradually over time, and those who believed that species change suddenly after long periods of calm, triggered by significant geological events. Those two schools have now largely reconciled. Evolutionary change happens both gradually and with occasional step changes.

 

The same is true in organizations. Change is both gradual, and occasionally punctuated with disruptive changes that may come from new innovation, regulation, or market events. 

 

Terms for this include exploit (existing business models) and explore (new ones). Also, kaizen (continuous improvement) and kaikaku (radical change). 

 

In evolutionary biology the term is “Punctuated Gradualism.” (See Figure 7.1.)

Product development teams rarely uncover long-forgotten fish; however, they often find themselves dealing with the detritus of legacy enterprise applications and tripping over layers of fossilized but still-living code that’s been left behind.


Even in the Age of Digital, living software fossils are still evolving in many older companies. Some companies teach COBOL to new graduates so they can continue developing mainframe software written in the 1960s and 1970s. Other companies maintain massive, monolithic databases built for client-server architectures from the 1990s and 2000s.


At many organizations, critical processing takes place on thick client desktop interfaces even as most of the industry now builds browser front ends by default.


In organizations with traditional ways of working, change (in the context of unique product development) is staccato. In evolutionary biology terms it’s “Punctuated Equilibrium” rather than “Punctuated Gradualism.” This means there are long periods of stasis, where Technical Debt builds up – slowing down new development – then a burst of disruptive (often negatively disruptive) change. 


There is a lack of ongoing continuous improvement. 


There is a status quo, punctuated with a big budget, big timeline, big overrun, big bang.


With a project-centric mentality, where the future is predicted at the point where least is known, and a financial process that encourages premature solutioning and a deterministic mindset, the “punctuation” tends to be yet another new IT product (application) being deployed. 

As previous projects have disbanded and the original knowledge has dispersed, applications are generally left in stasis. They are running in lights-on mode, and with each new application, the percentage of spend on “run” increases.

 

There is less spend available for discretionary work, a commonly observed issue. 


Akin to gardening, the weeds are left to grow. Operating systems, compilers, third-party libraries are no longer supported and patched. Eventually the garden is so overgrown, a point of no return has been passed, such that the only approach is to slash-and-burn and do yet another big-budget, big-bang, greenfield, replacement software system. And so the madness continues. 


This is not optimizing for Better Value Sooner Safer Happier—quite the opposite.


In the next few posts we’ll look at ways to avoid getting into this situation.

This post is excerpted from Sooner Safer Happier by Jonathan Smart, with Zsolt Berend, Myles Ogilvie, and Simon Rohrer.

Share on twitter
Share on facebook
Share on linkedin
Share on whatsapp
Share on email

MORE ARTICLES

Better Value Sooner Safer Happier

ANTIPATTERNS AND PATTERNS
FOR BUSINESS AGILITY

sooner safer happier book