http://qs321.pair.com?node_id=888403


in reply to Nobody Expects the Agile Imposition (Part VI): Architecture

Over the course of a great many years, I’ve noticed that the software industry seems to be locked in an ersatz science-fiction movie.   The scene opens in a graveyard, beside an open grave, with shovels and picks all around ... and the grave is surrounded by cribs, and in each crib there is a happy young baby.   Everyone in the scene wants desperately to grab a shovel and fill-in the grave, but no one can do so, because the life-force that is still sustaining everything is within the erstwhile “corpse” that has been consigned to the grave.   (In fact, a baleful-looking old man is standing upright in that grave, and he ... the oh-by-the-way source of all that business sustaining life-force ... is far busier than all the rest of them combined, with nary a shovelful of dirt upon his head.)

As the science-fiction movie progresses, an amazing thing happens.   The bouncing, happy babies almost instantly turn into old men, and graves are promptly dug for them in which they calmly stand, busily doing the jobs for which they were intended, even as a brand new set of bouncing babies appear.   (The engineers promptly turn their attention to the new set of babies, as a new crop of clever young publishers write and sell a new crop of books.)

Perhaps... we should give more serious consideration to the fact that none of the “crappy, old” legacy code in any of our shops ever started out that way, and also to the fact that every bit of the “new and improved,” “Agile&trade, Scrum™ insert silver-bullet buzzword here™” code that we are now writing will soon turn out that way.

Let me say it again.   The new-and-improved systems that we are writing today will become the legacy-code of next week, regardless of what we do.

(Sux to be the bearer of bad news, but this old phart doth stand his ground, and who among ye will stand with me?   Who shall stand to show me wrong?)

If our methods (“It will be so much better this time!   I promise!!”) were actually new and improved better, then “the legacy code problem” would cease to exist altogether, would it not? ...

Perhaps... we should stop trying so hard to bury Caesar, and spend a lot more time figuring out to give the old boy a facelift and a shave.   The “convoluted, incomprehensible” logic of a legacy system consists of two three four (unfortunately, inseparable) parts:

  1. The code that is specific to the exact representations of code-and-data that were chosen at some particular time (the “Y2K Problem™” being the most-obvious example of this) ... and ...
  2. The (representation independent) business logic that is buried in all of that rigid concrete ... but which actually represents the business, as it actually is.
  3. It is effing huge, consisting of not one but perhaps hundreds or thousands of individual parts.   All of them are moving ominously.
  4. I t     W o r k s .

The “so what?” take-away that I would offer is that ... every piece of computer software that we have ever designed, and that we ever will design, is a similarly “concrete” structure.   Oh, we can cast it in many different languages and dress it all up in many ways (calling every single one of those ways “a silver bullet™” if it suits our marketing purposes), but our essential modus operandi, from the point-of-view of the physical hardware, really has not evolved at all.   The “new and improved™” working methods that we now use, are (I would suggest...) really not materially different from the “new and improved™” working methods that our parents used.   Or (gasp!   I am dating myself here!) ... we, ourselves used ... to create the “crufty, old, legacy” systems that we now decry.

As an example of what I am saying ... consider the “New and Improved™ System” that your “New and Improved™ Agile™ Scrum™ New-Buzzword™ team just developed.   The realities of Business are upon ye, even as one-third of your development team just went to greener pastures while another two-thirds of your team just had their visas revoked due to some unforseen technicality.   Your company just swallowed or got swallowed-up by another company in what was a truly excellent business deal, and their 1,650,000 paying customers must be none the wiser when the deal is consummated eight weeks hence.   Can your “methodology” cope with that?   I doubt.   But is it pragmatic business reality?   Yes.

Perhaps we should all be focusing our collective attention on things like ... change control, or the merging of development teams, or the assimilation of totally-unrelated code bases that (while well-designed by their own teams at their own time) are now in “a Brady Bunch moment.”   Perhaps we are staring too earnestly at the Eastern sky, waiting for a savior to come that will never come.   (I cordially request “religious indulgence,” and promise that I mean no “religious slight” or disrespect for the sake of metaphor.)   Maybe we are earnestly pursuing the wrong solution to the wrong problem, just as our predecessors did.   Maybe we should take full ownership of “legacy code.”   Both our predecessors’, and, soon enough, our own.

/me straps on his hopefully flame-proof bunny suit and waits for the circus to begin...