|Perl: the Markov chain saw|
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
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
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™
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...