Archive

Posts Tagged ‘Software Maintenance’

Firefighter Fran

October 21, 2012 5 comments

Being anointed as a firefighter in an org that’s constantly battling blazes is one of the highest callings there is for any group member not occupying a coveted slot in the chief’s inner circle. Hell, since you didn’t start the fire and you’re gonna try your best to save the lot from a financial disaster, it’s a can’t-lose situation. If you fail, you’ll be patted on the back with a “nice try soldier; now we’re gonna go find the firestarter and kick his arse to kingdom come”. If you extinguish the blaze, at least you’ll lock in that 2% raise for this fiscal year. You might even get an accompanying $25 Dunkin Donuts gift card to keep your spare tire inflated with dozens of delectable, confectionary delights.

Given the above context, let’s start this heart-warming story off with you in the glorious role of firefighter Fran. You, my dear Fanny, oops, I mean Franny, have been assigned to put out a major blaze in one of your flagship legacy software products before it spreads to one of the nearby money silos and blows it sky high. Time, as always, is of the utmost importance. D’oh!

Since the burning pile of poop’s “agile” architecture and design documentation is a bunch of fluffy camouflage created solely to satisfy some process compliance checklist, you check out the code base and directly fire up vi (IDEs are for new age pussies!) for some serious sleuthing.

After glancing at the source tree‘s folder structure and concluding that it’s an incomprehensible, acronym-laden quagmire, you take the random plunge. With fingers a tremblin’ and fire hose a danglin’, you open up one of the 5000 source code files that’s postfixed with the word “Main“. You then start sequentially reading some hieroglyphics that’s supposed to be source code and you come to an abrupt halt when you see this:

And… that’s it! The story pauses here because BD00’s lizard brain is about to explode and it’s your turn to provide some “collaborative“, creative input.

So, what does our guaranteed-to-be-hero, fireman Fran, do next? Does the fire get doused? Does the pecuniary silo explode? Is the firestarter ever found? Does Fanny get the DD gift card? If so, how many crullers and donut holes does he scarf down?

Who knows, maybe you can become a self-proclaimed l’artiste like BD00 too, no?

The Hidden Preservation State

January 16, 2012 2 comments

In the software industry, “maintenance” (like “system“) is an overloaded and overused catchall word. Nevertheless, in “Object-Oriented Analysis and Design with Applications“, Grady Booch valiantly tries to resolve the open-endedness of  the term:

It is maintenance when we correct errors; it is evolution when we respond to changing requirements; it is preservation when we continue to use extraordinary means to keep an ancient and decaying piece of software in operation (lol! – BD00) – Grady Booch et al

Based on Mr. Booch’s distinctions, the UML state machine diagram below attempts to model the dynamic status of a software-intensive system during its lifetime.

The trouble with a boatload of orgs is that their mental model and operating behavior can be represented as thus:

What’s missing from this crippled state machine? Why, it’s the “Preservation” state silly. In reality, it’s lurking ominously behind the scenes as the elephant in the room, but since it’s hidden from view to the unaware org, it only comes to the fore when a crisis occurs and it can’t be denied any longer. D’oh! Call in the firefighters.

Maybe that’s why Mr. “Happy Dance” Booch also sez:

… reality suggests that an inordinate percentage of software development resources are spent on software preservation.

For orgs that operate in accordance to the crippled state machine, “Preservation” is an expensive, time consuming, resource sucking sink. I hate when that happens.

Software Debt

October 21, 2010 Leave a comment

If it hasn’t taken place already, be prepared for the latest buzz-concept in the software development world to go viral –  “Software Debt“. I think that Ward Cunningham (who I love because he invented the Wiki) is the originator of the term “technical debt“, from which “Software Debt” is, no doubt, derived.

Voila, here’s the first book that I’ve seen so far with “Software Debt” in it’s title. Expect all kinds of seminars and videos and professional “Software Bankers” (who will certainly help you keep your debt low and prevent foreclosure by your customers) to sprout up all over like fungi in a dark, stanky, and moist environment. After all, the well worn and tired “agile” buzzword needs to be replaced by something just as exciting, no?

In my twisted mind, “Software Debt” is no different, but sounds a lot kooler than the bland “Software Maintainability“. Designing, coding, and artifacting to manage “Software Debt” is no different than doing the same for “Software Maintenance“. What do you think?

Hi, I’m a software banker and I can help you consolidate and pay off all your software debt. Trust me, I will solve all your maintenance, oops, I mean debt, problems in no time flat. Plus, my fee is reasonable.” – Bulldozer00

%d bloggers like this: