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-12 08:46 • by hobart (unregistered)
302046 in reply to 300726
Although I don't agree with Joel Spolsky on everything he writes, he nailed this issue pretty well:
Not sure he does nail the issue here. TBH, I'm struggling with what his point is.

Is it that abstraction sometimes goes too far? True, but the example of p2p is a pretty poor one. If you take the original Napster, remove the "music only" thing and get to peer-to-peer as he suggests, you don't get something that "misses the point". You get torrents, or you get iPlayer (oh, and p2p lending still has a fair chance of being a big thing).

Is it that some people over-hype technology? Well, duh. But that's been the same with every product that's been sold since the dawn of time - that's marketing. Can't really see what it's got to do with "architecture astronauts".

Or is it that most people don't care about the underlying architecture? Again, true. But just because most people don't really care about the fact that something is underpinned by XML, it doesn't make the people who came up with XML, or someone building an architecture based around XML, an "architecture astronaut" who's run out of oxygen.

Re: Patterns of Failure

2010-03-13 14:48 • by JJ (unregistered)
If I were to put a label on this article, I'd say it's about the state of trends in evolution of so called "Enterprise Systems" and the fine line that exists between the good usage and bad usage of patterns; and the reasons that could lead to such a situation. The article takes the example of a wrong turn were the end result seems to make sense in regards to certain principles, but was driven by bad decisions.

Having seen some HR/Finance systems in medium to big corporations, I can attest that quite often, the excessive use of patterns mix the concerns at higher level just enough so that implementing specific business rules related for example to salary can become a nigthmare; the flow of data can also become badly broken; or the dependencies could become unmanageable. Lack of foresight is not necessarily to blame because changes in that kind of softwares can take a heck of a long time and span multiple people.

Interestingly enough, this thought process seems to apply equally to organization changes in companies of the same sizes, were we could compare the choices of companies having multiple HR, Finances or IT departments versus companies centralizing everything and at the end of the day thinking about outsourcing those groups. It is definitely arguable that some companies can and do benefit of such changes, but what makes it so?

Re: Patterns of Failure

2010-03-19 01:36 • by Calvin (unregistered)
302890 in reply to 300680
Good lord, I'm glad I'm not the only one. I learned my lesson, though; and repented of my sins.

Re: Patterns of Failure

2010-12-16 02:46 • by cindy (unregistered)
find for all kinds of amazing watches and women handbags

Re: Patterns of Failure

2012-07-03 00:42 • by tanus (unregistered)
This reminds me of MSN messenger 2011. It has its own library and runtime.
The library: one massive package that after you install it, which you have to, you may as well install all other programs; which are small in comparison; though you may just messenger.
And everytime there is a new version you get prompted to update to the new one.
Imagine something like this: a 100MB library and 7 5-12MB applications.
And one only really want 1 application.
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment