
Patterns of Failure - bdfh42
http://thedailywtf.com/Articles/Patterns-of-Failure.aspx
======
silentseraph
So.. After reading this, I began wondering if the company I work for does or
doesn't fit under the umbrella in the article.

I work for a company that creates online digital "newsrooms". Basically, CMS
on steroids. We handle everything for a company that needs to publish their PR
content in a way that doesn't make journalists cringe and run screaming. I'm
talking about Press Kits, Releases, Photos, Videos, "Baskets" or "bundles" of
the above, being able to e-mail the bundles out to other press people, very
complex embargoes on content (so releases expire or do not even show up before
a certain time), very complex permissions and very complex subscription
management systems, etc...

All of the above is... well... complex. The company found they were re-writing
the system over and over with each new client, or worse, copying code from the
old client.

So they created a system of plug-in-able modules of sorts. When a new newsroom
wanted video stuff, we plugin VideoManagement, and all the requisite features
get shoved into the new client's app. When a client application that uses
video management finds a bug, it is fixed, and pushed out to every other
client site that is actively maintained, and they get the fix too.

On top of this, though, the client applications are able to be customized with
new layouts and such. Always a bit of a pain, but it's still capable of being
customized fairly easily.

So is the company I work for wrong for doing that? We don't have any real
clients other than these types. We've found a niche, and have found plenty of
business within that niche. Does it not make sense in _this_ case?

I ask here because I'm unsure of whether or not I feel like the company I work
for is the exception simply because I work for it.

Thoughts?

~~~
chipsy
I think that's real application evolution at work: You have new projects and
new requirements all the time, but they're _similar_ projects. It is natural
to gradually build out a framework of reuse. That's different from the "the
entire business should have uniform software" misconception described in the
article. There, the owners are grabbing for an efficiency that simply isn't
present in that situation.

------
j_baker
"we often forget that the consequence of unnecessary duplication is far less
than the consequence of unnecessary consolidation."

I don't know that I agree with this. Unnecessary consolidation _is_ bad, but I
find that it's more of an effect of that consolidation being poorly thought
out.

~~~
viraptor
Then maybe just a set of common libraries is a better way out... There's just
a problem of a difference between a common "authentication library", "unified
storage library", "messaging library", ... and a global clusterfuck with more
inter-dependencies than your brain neurons have.

If you can keep them separate, they don't become a required framework for
everything - but changing anything in one of them still requires retesting a
lot of applications that could've been affected. Keeping the libraries as
simple as possible (maybe even as separate language-independent rpc services
if it's only for internal usage) could be a solution.

------
GFischer
As someone who currently works for Corporate IT, I totally share that pain,
especially about the inner-platform.

Our current UberMegaProgram is very customizable. When you want to add a new
product, you add the fields the product will have (so far so good), and then,
there is something called "operations"... which is basically Assembler re-
invented. You move data to some registers, do some basic operations... and
you're expected to do all the math and validation in that (which is, of
course, un-debug-able). I HATE it but since we paid 800000 dollars for it,
it's not going away soon.

------
tetha
I am not entirely sure. Is the difference between: (1) a number of reusable
modules/components (I am thinking of, say, maven artifacts in a private
repository, something along a private CPAN) and (2) the evil Uber-Application
that:

in (1) you take several modules out of the sea of modules you have and
integrate them into the software you create for the customers needs
(potentially adapting or refining the modules)

while in (2) you rather try to bend a single application and the customers
will in a way such that they eventually meet somewhere, forming some sort of
application which sort of meets the customers requirements?

If this is the case, then I think I agree.

------
SandB0x
Eerily familiar.

As well as making the developer's life a misery, the ÜberApplication can mean
a slow death for your company as you can't sell components separately - it's
all or nothing.

