Comment On Patterns of Failure

Not too long ago, I was at a client site, working to understand and improve their development process. From a birds-eye view, their development organization was a lot like many other Corporate IT set-ups: they had a sizable portfolio of proprietary applications that were built for and used by different business groups. Some of these applications were “mission critical” and had highly formalized promotion and deployment processes, while others were ancillary and were hardly ever used. <shameless_plug>This, along with the medley of technologies and platforms, was why they sought our help in managing and automating their development processes with BuildMaster.</shameless_plug> [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: Patterns of Failure

2010-03-02 11:07 • by laoris (unregistered)
I think that cloud looks more like a llama, actually.

Re: Patterns of Failure

2010-03-02 11:11 • by Ed (unregistered)
300676 in reply to 300675
laoris:
I think that cloud looks more like a llama, actually.


Possibly a poodle?

Or perhaps the Michelin Man's canine friend.

Re: Patterns of Failure

2010-03-02 11:12 • by SuperAnalyst
An interesting, if technical, article on the path to Code.Hades(), but where's the funny?

Re: Patterns of Failure

2010-03-02 11:13 • by dkf
300678 in reply to 300675
laoris:
I think that cloud looks more like a llama, actually.

And I only manage to see a tap (that's a faucet to you North Americans).

Re: Patterns of Failure

2010-03-02 11:19 • by Wheaties (unregistered)
Yeah, been there, done that, have the scars to prove it. Where's the stories about watching the new hires' faces contort as you try to explain how the monstrosity works?

Re: Patterns of Failure

2010-03-02 11:20 • by Engival (unregistered)
I've seen a few well designed intranet sites sharing a common user and permission system, without having to shoehorn every module into some unrealistic requirements. Does this automatically make it a WTF?

It doesn't matter if you design an uber-app, separate apps, or some form of modular intranet; if you start from a bad framework or bad design goals, you end up with a WTF. If you have good design goals, and some sensible non-overreaching framework, you can end up with a nice system.

Re: Patterns of Failure

2010-03-02 11:24 • by A Nonny Mouse
anyone else seeing phantom brown dots on the uniform application portfolio graphic..? maybe i need coffee (or less coffee, depending)

Re: Patterns of Failure

2010-03-02 11:27 • by ClutchDude (unregistered)
This article underscores the importance for at least half-decent project planning.

For instance, if at the framework level, they partitioned the code for each functional group off, they'd find themselves in a more manageable position. Sure, I want a simple calendar popup to be consistent through out the organization. UI can be a big and sometimes beast of a problem, so it makes sense to simplify it as much as possible so users can expect the same thing.

The problem, as Alex points out, is that it's so easy to move beyond just centralizing UI.

It was hard enough getting framework Foobar working in one application. Why would you redo that when you can just tack the need functionality onto that framework? It'd make your life a lot easier..until the logic between the two somehow-separate applications gets so intermeshed you can't pull them apart without breaking both.

Side note, you might want to tell Softlayer that they misspelled "Washinton DC" in their banner ad.



Re: Patterns of Failure

2010-03-02 11:27 • by James (unregistered)
300686 in reply to 300684
Don't worry. That's a perfectly normal optical illusion.

Re: Patterns of Failure

2010-03-02 11:29 • by Dan (unregistered)
300687 in reply to 300675
laoris:
I think that cloud looks more like a llama, actually.


exactly what I thought hen I saw it too.

Re: Patterns of Failure

2010-03-02 11:29 • by rudraigh
I don't see a dog in the cloud. Unless that dog is in a sheep costume.

BuildMaster looks interesting.

Re: Patterns of Failure

2010-03-02 11:29 • by lesle (unregistered)
300689 in reply to 300684
A Nonny Mouse:
anyone else seeing phantom brown dots on the uniform application portfolio graphic..? maybe i need coffee (or less coffee, depending)
Yes. They're interstitial brown.

Re: Patterns of Failure

2010-03-02 11:34 • by Hmmm... (unregistered)
This article attempts to take on a pretty huge topic. It seems to me to miss out on many key advantages of an architecture where disparate functionality can benefit from unified conventions and foundations. Aside from benefits to developers, a group of applications which share common elements can be easier for users to learn, faster to use, and easier to administer. You can certainly enforce these by convention, but the strength of convention in large groups is not usually very high without burdensome review processes.

Further, if it becomes necessary to move information from one system to another, it is much simpler if the systems share a platform.

My gut says to me: six different internal applications which don't share a code base are bound to reinvent the wheel and be a real pain to manage.

Re: Patterns of Failure

2010-03-02 11:43 • by Gump (unregistered)
300691 in reply to 300675
laoris:
I think that cloud looks more like a llama, actually.


Damn, you beat me to it.

Yeah, that's a llama.

captcha: illum = when one is um, sick

Re: Patterns of Failure

2010-03-02 11:52 • by Ben Burns (unregistered)
I don't think the problem here is the internal framework, it's the adoption of processes which don't allow for "the law of leaky abstractions." Unwillingness to accept a lack of perfection in a particular set of abstractions limits flexibility in design and leads to the problem you describe - overtly modifying the requirements to fit the system rather than the system to fit the requirements.

Re: Patterns of Failure

2010-03-02 12:06 • by amischiefr
300697 in reply to 300690
Hmmm...:

My gut says to me: six different internal applications which don't share a code base are bound to reinvent the wheel and be a real pain to manage.

Yeah, I don't see what the problem is. Having a code base that extracts like functionality for reuse seems to be highly functional, not dysfunctional. Especially (which is mentioned several times in the article) user authentication. Why would you not want one centralized solution for this so that every application authenticates in the same way? We have such a system that returns a list of user roles which can be used in the application to determine access.

Re: Patterns of Failure

2010-03-02 12:08 • by blah (unregistered)
TRWTF is VB5.

Re: Patterns of Failure

2010-03-02 12:15 • by Marvin the Martian (unregistered)
300700 in reply to 300691
Gump:
laoris:
I think that cloud looks more like a llama, actually.

Yeah, that's a llama.

No is no llama!

Is Argentinian sheep. Onestly.

Re: Patterns of Failure

2010-03-02 12:17 • by Doug (unregistered)
I'm not sure if the cloud looks like a dog, but I'm pretty sure the UberApplication looks like Norton SystemWorks ...

Re: Patterns of Failure

2010-03-02 12:19 • by md5sum
Wow... I guess I'm missing the WTF here today, or maybe I'm missing what this article is saying, but I've worked on many systems (and am currently building a new one) where a single application layer lays the foundation for multiple application front-ends. Obviously bad design is bad design, and bad architecture is bad architecture, but built correctly with keeping the UNIQUE application logical units separate while re-using the NON-UNIQUE modules has many HUGE advantages. Among other things, it makes management of future development and changes in the shared components much simpler.

Now obviously I'm not promoting a one-size-fits-all application model, but sharing DAO and security objects across multiple applications just makes sense.

There are only 3 possible ways you would ever consider doing security for an application (AD w/ groups, single password for everyone, unique logins and permissions internally managed) maybe a 4th method if your application requires field level permissions for each user, but I always advise against that method due to the poor manageability.

And obviously, you might have multiple different data sources, potentially different data types, but I have both built and worked on several different structures that support multiple data sources and types with GREAT ease of use for the developers, and reliability for the consumers.

Considering the example cited here, if the "Disparate Application Portfolio" is the RIGHT way to go, and all of them use a copy of the same Data object. You find a bug in your Data object... you now have to re-deploy all of your applications. If they all share the same Data object, and none of them contains a unique copy of it, but rather they all point to a SINGLE, SOLITARY deployment of the Data object, then you only have to re-deploy the Data object.

Maybe it's just me, and maybe I'm wrong, but (sadly) I've worked with all the models listed in this article, and the easiest and best in my experience has been pretty close to what's described here, minus the “how might we adapt the needs to meet our pre-determined requirements” part, which should never be a part of a development process.

Re: Patterns of Failure

2010-03-02 12:23 • by Richard (unregistered)
300703 in reply to 300700
Actually, it's pretty clearly a Chinese dragon. <piff> Llama, indeed...

Re: Patterns of Failure

2010-03-02 12:31 • by Ray (unregistered)
There's an old saying a couple of my university professors would use for something like this:

KISS - Keep It Simple, Stupid.

Re: Patterns of Failure

2010-03-02 12:32 • by Franz Kafka (unregistered)
300705 in reply to 300690
Hmmm...:
This article attempts to take on a pretty huge topic. It seems to me to miss out on many key advantages of an architecture where disparate functionality can benefit from unified conventions and foundations. Aside from benefits to developers, a group of applications which share common elements can be easier for users to learn, faster to use, and easier to administer. You can certainly enforce these by convention, but the strength of convention in large groups is not usually very high without burdensome review processes.

Further, if it becomes necessary to move information from one system to another, it is much simpler if the systems share a platform.

My gut says to me: six different internal applications which don't share a code base are bound to reinvent the wheel and be a real pain to manage.


Mine says that the internal apps should share some code (via a core package, perhaps), but beyond UI and common mechanisms like auth, they should be separate.

Re: Patterns of Failure

2010-03-02 12:35 • by Robert (unregistered)
300707 in reply to 300675
laoris:
I think that cloud looks more like a llama, actually.


Wow, I was going to post that, and BAM, there it is in the first post.

Re: Patterns of Failure

2010-03-02 12:36 • by Anonymous Coward (unregistered)
300708 in reply to 300703
Richard:
Actually, it's pretty clearly a Chinese dragon. <piff> Llama, indeed...

Much closer to a Chinese lion. since spamfilter won't let me link, see: http://en.wikipedia.org/wiki/Lion_dance

Re: Patterns of Failure

2010-03-02 12:36 • by md5sum
300709 in reply to 300705
Franz Kafka:
Hmmm...:
This article attempts to take on a pretty huge topic. It seems to me to miss out on many key advantages of an architecture where disparate functionality can benefit from unified conventions and foundations. Aside from benefits to developers, a group of applications which share common elements can be easier for users to learn, faster to use, and easier to administer. You can certainly enforce these by convention, but the strength of convention in large groups is not usually very high without burdensome review processes.

Further, if it becomes necessary to move information from one system to another, it is much simpler if the systems share a platform.

My gut says to me: six different internal applications which don't share a code base are bound to reinvent the wheel and be a real pain to manage.


Mine says that the internal apps should share some code (via a core package, perhaps), but beyond UI and common mechanisms like auth, they should be separate.


Which is exactly what I was referring to in my (somewhat lengthy) comment, and is also almost exactly what is pictured in the "UberApplication" diagram (that's supposedly so bad)...

Re: Patterns of Failure

2010-03-02 12:45 • by Paul W. Homer (unregistered)
There is certainly a balance that developers have to make between trying to abstract everything, and just pounding out masses of overly duplicate code. However, just because this example of building an uber-system failed so miserably, it doesn't mean that the goal or their intentions were wrong.

It sounds like they just didn't understand what problem they were really trying to solve. They collected together a big ugly mass of technology hoping that it would somehow magically solve their problems, however the real problem was how to make it intrinsically easy to quickly build and maintain new components.

Technology by itself is never the issue, complexity management is.

Still, these types of failures shouldn't lead developers to conclude that pounding out more redundant code in a large number of independent systems is a solution. One problematic uber-system is still way better than twenty badly written little ones. At least with the big system, when pointed in the right direction, there is some hope in getting it sorted out. With the little ones, only the better ones will eventually get updated. The rest will just rust away.

Re: Patterns of Failure

2010-03-02 13:05 • by Michael (unregistered)
Good article. I figure the reason we think this way is because, as the article says, at a code-level finding and reducing redundancy is *usually* a good idea. However, at a macro-level, there are all these standards (like XML, SOAP, XML-RPC, etc) for providing loosely coupled interactivity between applications. Some of the standards even predate the Web!

IMO, awareness of and adherence to existing standards is the key to avoiding this trap.

Re: Patterns of Failure

2010-03-02 13:07 • by highphilosopher (unregistered)
300716 in reply to 300702
md5sum:
Wow... I guess I'm missing the WTF here today, or maybe I'm missing what this article is saying...
the “how might we adapt the needs to meet our pre-determined requirements” part, which should never be a part of a development process.


That part is the WTF.

Re: Patterns of Failure

2010-03-02 13:07 • by Franz Kafka (unregistered)
300717 in reply to 300709
md5sum:
Franz Kafka:


Mine says that the internal apps should share some code (via a core package, perhaps), but beyond UI and common mechanisms like auth, they should be separate.


Which is exactly what I was referring to in my (somewhat lengthy) comment, and is also almost exactly what is pictured in the "UberApplication" diagram (that's supposedly so bad)...


The reason the uberapp is so bad is that:
1. developing an app requires an app template that doesn't quite fit the requirements
2. even with that, it takes longer to develop than a custom one-off
3. this leads to lots of unrelated apps stuck together in the same 'app'

What should be done with code sharing is to share the lower layers of the stack and also horizontal concerns - common utils, DB access, logging, some UI widgets if practical. Forcing every app into a preselected mold doesn't really help much.

Re: Patterns of Failure

2010-03-02 13:19 • by Bill Sorensen (unregistered)
I strongly disagree that this is a WTF. The implementation may have been, but the concept is valid. Microsoft's Composite UI Application Block (CAB) is based on this premise; it was seen as overly complex, so Prism (Composite WPF) was introduced as a replacement.

We wrote a stripped-down version of CAB, which works well for in-house development. Users appreciate the consistent look-and-feel, and developers don't have to reimplement security for every application.

Composition is good in software design. Removing duplication is good when coding. Why are these concepts bad for application design?

The framework must be flexible enough to handle diverse requirements, but that's not that hard. Outside of vendor demos, most applications look very similar (and that's a good thing). Apple got it right, and Microsoft does try.

Re: Patterns of Failure

2010-03-02 13:21 • by mfah
300719 in reply to 300701
Doug:
I'm pretty sure the UberApplication looks like Norton SystemWorks ...

It's clearly Lotus Notes. This is exactly the sort of thing that happens with Lotus Notes (which is enough of a WTF in itself).

Re: Patterns of Failure

2010-03-02 13:44 • by ObiWayneKenobi
Isn't the accepted best practice for software development to have your common modules and then reuse only those in other modules? It's a WTF if the "Customer Management Module" shares logic with the "Report Generation Module" but not if both make use of the Authentication Module and/or the Base Entity Module.

Re: Patterns of Failure

2010-03-02 13:58 • by EatenByAGrue (unregistered)
A serious article on TDWTF. Ok, I'll go with it, since usually this site is dedicated to demonstrating what not to do.

Although I don't agree with Joel Spolsky on everything he writes, he nailed this issue pretty well:
http://joelonsoftware.com/articles/fog0000000018.html

What happens with these types is that they see patterns and abstractions really well, which may or may not be useful for putting together a good software solution. I've worked with guys who were great coders and really bright folks, but because they were so focused on solving a generalized abstraction of the problem they never actually got around to solving the specific problem.

Re: Patterns of Failure

2010-03-02 14:09 • by Ed Larmore (unregistered)
I think Alex makes interesting points. I've definitely seen requirements for a new system based on how an existing system works.

But sometimes that actually makes a lot of sense. Often a customer doesn't know exactly what he wants until he sees it. So if he sees an existing system that does some similar things to the often vague notion in his head of what he wants, he might say "I want X but don't want Y, and I like Z but please change it to something a bit different". Wouldn't it then make sense to re-use requirements and code on the pieces he wants and modify requirements and refactor code for the things that he wants to change slightly?

Now of course this strategy requires competent engineers and can be done poorly as any task can; but that doesn't make the approach somehow bad.

Also, many security features are rather arbitrary; e.g., password requirements (must have 1 upper case character, 2 numbers and one special character). If a new customer can choose between an arbitrary password requirement that he has to pay money for vs. an arbitrarty password requirement that is already implemented, why not reuse the latter? Or if he really must have a particular password requirement that isn't implemented, why not refactor the existing password checker to use regular expressions, so that both the original app and the new app can use the same code?

Re: Patterns of Failure

2010-03-02 14:17 • by James S (unregistered)
This seems like a great big DUH moment. *Every* business application is a database application. Every single one. And this is probably why Lotus Notes seemed like such a good idea. Only that once the thing was bought, insufficient resoruces are devoted to 1) telling everyone the plan to put everything into Notes, 2) making that plan actually happen. It all gets watered down and set aside and not communicated. At HQ, sure, there Notes-ing their brains out, but in the field offices, their not even sure what Notes is (other than horrible email client) and are busily building there own business-specific tools with Lotus Approach. (or now-a-days, a horrible combination of MS Excel and Access, with hooks into Outlook, that all runs on some Admin Asst's desktop). The problem is that big businesses are too big.

Re: Patterns of Failure

2010-03-02 14:19 • by Vjg (unregistered)
That dog looks exactly like a cloud I saw last week... or was it a potato?

Re: Patterns of Failure

2010-03-02 14:27 • by Jackson Curtis (unregistered)
I see a My Little Pony

Re: Patterns of Failure

2010-03-02 14:33 • by Rob (unregistered)
SOA?

Re: Patterns of Failure

2010-03-02 14:38 • by woah! (unregistered)
300733 in reply to 300681
Engival:
I've seen a few well designed intranet sites sharing a common user and permission system, without having to shoehorn every module into some unrealistic requirements. Does this automatically make it a WTF?

It doesn't matter if you design an uber-app, separate apps, or some form of modular intranet; if you start from a bad framework or bad design goals, you end up with a WTF. If you have good design goals, and some sensible non-overreaching framework, you can end up with a nice system.


Yeah this was a pretty poor TheDailyWTF article. Sounds to me like they were just using a skeleton in house framework, and as they needed to plug new applications in, some code went in to the wrong layer.

This should just be a standard "someone invented their own shitty framework" wtf. Instead it ridicules what all software engineers try to achieve: never having to write the same line of code twice.

Re: Patterns of Failure

2010-03-02 14:46 • by DES
300734 in reply to 300702
md5sum:
There are only 3 possible ways you would ever consider doing security for an application (AD w/ groups, single password for everyone, unique logins and permissions internally managed)


Remind me not to hire you.

md5sum:
Considering the example cited here, if the "Disparate Application Portfolio" is the RIGHT way to go, and all of them use a copy of the same Data object. You find a bug in your Data object... you now have to re-deploy all of your applications. If they all share the same Data object, and none of them contains a unique copy of it, but rather they all point to a SINGLE, SOLITARY deployment of the Data object, then you only have to re-deploy the Data object.


In the real world, the guys who maintain Application X stumbled across the bug in the Data object and fixed it, while the guys who maintain Application Y tweaked something (possibly unwittingly) so the buggy Data object works fine for them, and deploying the fix broke Application Y at the precise moment when the CTO was demonstrating it to the Gnomes from Zürich. As a consequence, the Gnomes return to Zürich without signing the multi-million-dollar contract, and the CTO fires the idiot who came up with the deployment procedure, viz. you.

Re: Patterns of Failure

2010-03-02 14:48 • by Cliff Buttons (unregistered)
There was a classic Dilbert (so it must be true) where the consultants came in - decentralise everything that's centralised, centralise everything that's decentralised, and leave the dust to settle long enough for the next guys to reverse what you just did.

That's because the real world is endlessly variable, IT is extremely rigid, and there's no single right answer to any problem.

Take a company (hint, one I worked at) who insisted on 'online payslips' and had the scariest, shonkiest application and massive security holes in the corporate network to enable it. Nobody knew how the skunk app worked, they just knew it was a nightmare, and had to be migrated to different hardware, so they may as well look at it. Migration/redev would cost a minimum of £20k to fit the corporate security policy. It turned out for under £1000/year, they could revert to paper payslips (printed and sent throguh internal mail as opposed to everybody printing their own, which was what happened anyway) - but that couldn't be allowed - progress was progress after all. And in a market-leading IT company (one you know very well) these dual pressures of corporate compliance, legal compliance, security compliance and sheer bloody common sense, there was no single perfect answer. There never could be. This is a similar case - there is no 'right' answer, they're all wrong.

Re: Patterns of Failure

2010-03-02 14:57 • by Quirkafleeg (unregistered)
Never mind all of this reuse-this-don't-reuse-that-put-this-in-that-layer stuff. What I want to know is this: is who's in charge of maintaining the GAF the GAFfer?

Re: Patterns of Failure

2010-03-02 15:30 • by Franz Kafka (unregistered)
300740 in reply to 300734
DES:


In the real world, the guys who maintain Application X stumbled across the bug in the Data object and fixed it, while the guys who maintain Application Y tweaked something (possibly unwittingly) so the buggy Data object works fine for them, and deploying the fix broke Application Y at the precise moment when the CTO was demonstrating it to the Gnomes from Zürich. As a consequence, the Gnomes return to Zürich without signing the multi-million-dollar contract, and the CTO fires the idiot who came up with the deployment procedure, viz. you.


Well sure, if your idea of deployment is "throw against wall and see if it explodes". If you validate a configuration before foisting it on the world, this won't happen (much).

WTF Alex?

2010-03-02 15:31 • by Slicerwizard (unregistered)
How many birds does it take to make this "birds-eye"?

What the hell are "authorization principals"?

Re: Patterns of Failure

2010-03-02 15:48 • by The Wanderer (unregistered)
300743 in reply to 300675
laoris:
I think that cloud looks more like a llama, actually.
Exactly my first thought.

On second glance, though, I think it might be a camel.

Re: Patterns of Failure

2010-03-02 15:56 • by frits
300744 in reply to 300731
Jackson Curtis:
I see a My Little Pony


I see a Care Bear.

Re: Patterns of Failure

2010-03-02 15:57 • by jmucchiello
The only thing even close to a WTF here is that these disparate programs share the same address space. I don't care if these six user functions share 99% of the same code (and that 1% is just the stuff to differentiate them). The only problem here is that they are all contained with one Überlauncher. The savings gains from signing on only once is not worth the pain when one app crashes and takes out the other ones.

Re: Patterns of Failure

2010-03-02 16:06 • by MyNameHere (unregistered)
300746 in reply to 300684
Yup I see it too. I was going to mention it but you beat me to it.

Re: Patterns of Failure

2010-03-02 16:20 • by Bim Job (unregistered)
300748 in reply to 300744
frits:
Jackson Curtis:
I see a My Little Pony


I see a Care Bear.
I see a pantomime horse.

TRWTF is the silly multi-coloured "architecture" slide. This basically tells me that managers are in control, not engineers. And we all know where that leads.

All this stuff about authentication, authorization, and templates? It sounds like the lunatics have taken over the asylum. For the first two, separation of concerns should take care of the issue: all that other modules require is a yes/no/file_not_found answer, coupled with a list of capabilities. (And it has nothing whatsoever to do with subtle differences between password requirements and the like.) For the third, You Do Not Re-Use Web Templates. Yes, you can modularize them. No, you do not include logic in them (refer to Terrence Parr for details).

This sounds like a genuinely diseased organisation (three successive Architects?). It appears to be badly-managed, badly-directed, badly-staffed, and without any sane concept of testing or business analysis. I even suspect that, at ground level, the C# guys have little or no concept of inheritance and/or packages. Of course, I can't tell, because it's so generalised.

What it doesn't sound like is much of an argument for Alex' proposition.
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment