- 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
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.
Admin
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?
Admin
Good lord, I'm glad I'm not the only one. I learned my lesson, though; and repented of my sins.
Admin
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.