- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I think that cloud looks more like a llama, actually.
Admin
Possibly a poodle?
Or perhaps the Michelin Man's canine friend.
Admin
An interesting, if technical, article on the path to Code.Hades(), but where's the funny?
Admin
Admin
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?
Admin
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.
Admin
anyone else seeing phantom brown dots on the uniform application portfolio graphic..? maybe i need coffee (or less coffee, depending)
Admin
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.
Admin
Don't worry. That's a perfectly normal optical illusion.
Admin
exactly what I thought hen I saw it too.
Admin
I don't see a dog in the cloud. Unless that dog is in a sheep costume.
BuildMaster looks interesting.
Admin
Admin
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.
Admin
Damn, you beat me to it.
Yeah, that's a llama.
captcha: illum = when one is um, sick
Admin
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.
Admin
Admin
TRWTF is VB5.
Admin
Is Argentinian sheep. Onestly.
Admin
I'm not sure if the cloud looks like a dog, but I'm pretty sure the UberApplication looks like Norton SystemWorks ...
Admin
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.
Admin
Actually, it's pretty clearly a Chinese dragon. <piff> Llama, indeed...
Admin
There's an old saying a couple of my university professors would use for something like this:
KISS - Keep It Simple, Stupid.
Admin
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.
Admin
Wow, I was going to post that, and BAM, there it is in the first post.
Admin
Admin
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)...
Admin
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.
Admin
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.
Admin
That part is the WTF.
Admin
The reason the uberapp is so bad is that:
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.
Admin
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.
Admin
Admin
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.
Admin
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.
Admin
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?
Admin
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.
Admin
That dog looks exactly like a cloud I saw last week... or was it a potato?
Admin
I see a My Little Pony
Admin
SOA?
Admin
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.
Admin
Remind me not to hire you.
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.
Admin
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.
Admin
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?
Admin
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).
Admin
How many birds does it take to make this "birds-eye"?
What the hell are "authorization principals"?
Admin
On second glance, though, I think it might be a camel.
Admin
I see a Care Bear.
Admin
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.
Admin
Yup I see it too. I was going to mention it but you beat me to it.
Admin
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.