Fragile Development

I came across the phrase IgnoranceDrivenDevelopment by AlistairCockburn and thought I would add another term to the AntiPattern vocabulary. -- SelvakumarGanesan

A lovely phrase. Would you care to fill in a meaning, or should it be left to the reader's imagination?

I'm picturing something like ExtremeNormanForm.

See also the Fragile Alliance http://www.softwarereality.com/rumours/fragile_alliance.jsp

The meaning of FragileDevelopment. It is like biological evolution in a sense. The developmental team tries to reach the nearest peak - blindly.

Imagine a blind man trapped in an underground cave that is slowly filling with water (It is a sinister analogy. But, aren't developers quite like blind men let loose into Projects by ProjectManagement). There are a few raised platforms inside the cave and in a corner there are stairs that lead outside. How does he find a solution? Blindly, of course. His natural endowments aren't very helpful here except for his hands and feet. He mucks around the cave and by chance hits the nearest platform and climbs over it.

That sort of explains how FragileDevelopment happens. Blind and without foresight.

Disclaimer: Any resemblance to real people, projects and situations are wholly coincidental.

The signature set of FragileDevelopment:- 

        * ErrorDrivenDevelopment?
-- SelvakumarGanesan

Building a system so complex and hideous that it can not be reliably installed, configured or maintained. In addition the entire system will collapse into a smoldering pile if you so much as look at it funny.

For example, let's talk about a hypothetical system *cough* that I might be working on in some bizarre alternate universe... This hypothetical web-based system might rely on 4 or 5 external network-based components. There would be the database, customer entitlement checking, calls to JSPs to work around clustering problems unique to web based systems, and a few other network-based services.

Now some of those components might rely heavily on run-time based Java. For example, if some engineers were to get clever and try to work around process, they might create a system by which message processing is configured by injecting an XML message, complete with a serialized Java class, into a server. Said message would then be made persistent and accessible by the entire cluster. Clever, and highly prone to runtime errors. It's a good thing we keep those engineers on a tight leash, yep...

Furthermore if we used a development process that was unfriendly to documentation (Say, Scrum) and rotated our engineers out every few months as was the fashion during the dot-com boom, well then we'd have a system that no one knew it its entirety, was extremely prone to run-time failures and errors in external components and which could not, in general circumstances, be kept up for more than a day or two at a time.

I'm glad this is an entirely hypothetical discussion, yep...

--BruceIde

Honestly, I worked in a shop where this actually happened. Boss: "Fix this program." New hire me: "What is it supposed to do?" Boss: "Read the program." New hire me: "Is there any documentation?" Boss: "No." And, there were no reliable comments in the program.

So, you: "Where's the nearest door?"

There's no such thing as a reliable comment. However, if the system had no tests demonstrating how it does work, and no docs demonstrating how it should work...! For the record, I think my response (if not "Where's the nearest door?") would have been "OK, so what do you want it to do?" (Probably followed by: Boss: "I don't have time to explain it." Me: "OK. Get back to me when this is enough if a priority that you're willing to think about what you want.")

I've been in this situation once or twice, though I'm happy to say it hasn't occurred often. --MarnenLaibowKoser, 8 Aug 2013

CategoryAntiPattern

EditText of this page (last edited August 8, 2013) or FindPage with title or text search