Why is the Bar Set so Low for Enterprise Applications?

Either the author has never seen enterprise application or is simply advertising his employer, who is making money from showing Big IT how to build enterprise applications.

I like, however, how honestly http://www.thoughtworks-studios.com/ is bashing its own customers. It looks like that some Big IT (mentioned on the website), even after ThoughtWorks help, is still producing rubbish. What's worst, they are providing helpdesk for customers!! Such disgusting crime would never be commited in the agile open source World.

The point is that at some scale 'agile' development process simply does not work (think of integration with the number of third parties, think of necessity to take into account law regulations totally abstract to average developer, complicated bussines logic - medicine, insurance, banking, etc. that need bussiness analysts, I can go on for an hour like that).

A lot of enterprise applications are much, much more complicated then Linux kernel or Python interpreter. And they cannot fail - think of bank transactions.

Mind this old article How many Microsoft employees does it take to change a lightbulb? and the interesting comment by Raymond Chen:

Who develops the test plans for open source software? Who updates the screenshots in the user's guide and online help? And who translates the documentation into Polish and Turkish? Who verifies that the feature doesn't violate the Americans with Disabilities Act or German privacy laws? (Back when I worked on Linux, the answer was "Nobody. There is no test plan, there is no printed user's guide, what little documentation there is exists only in English, and nobody cares about complying with the ADA or German privacy laws." Maybe things have changed since then.)

Huge penetration of Linux on desktop suggests that maybe some kind of "enterprise application"-like process would be helpful.

And no, Linux kernel is not developed by "almost entirely volunteer organization", see http://martinezjavier.blogspot.com/2011/03/canonical-contributions-to-linux-kernel.html. All the 70+ % contributors are boring enterprises with their tickets, timesheets, managers, etc.

The issue with Enterprise Software is with priorities and requirements. The priorities place features first. "Soft" targets like usability and appearance are rated extremely low while long lists of features are rated at the top. And those lengthy feature lists come courtesy of the requirements. Business sponsors sell the application, the maintenance and the upgrades to the rest of the business by promoting features that add capabilities, save time, etc. It's virtually impossible to sell people on anything that's not concrete. And Web 2.0 principles? Fewer features in trade for simpler UI and ease of use? That would go over like a lead balloon. I'm not happy with it, but I have no idea how to substantially change it.

Hi, I'd like to respond to this one, especially the quoted text from Raymond Chen. I work for a professional open source company. (Hint: we're big in Linux and the JEE spaces.) At my place of work, we have employees around the globe. Some are tech writers, some are developers, some are support engineers. We do translate text into different languages. We have doc writers. We have professional testers who very thoroughly test every product release and patch. All are very good at what they do. We believe that the last 10 years were about making open source software a viable choice for enterprise computing. The next 10 are about making it the default choice. Time will tell if we're right. (Hint: I wouldn't bet against it.) Rick

Steven-  I think you have nominated the solution. When some 9-5 er submits a bug with their ERP package, reply with a zipped GNU C Compiler and say "Here you can solve that with this!"

 seriously though, I agree with Charles. I think what you speak of can all be attributed to the ... not sure what to call it so I'll call it the "Reluctance to Re-write" problem. As soon as the "app" becomes a "product" it moves into the hands of people who know nothing about the to-do list or the need to re-write the x and y modules because they were done in a spectacular hurry just before the deadline. The guys now steering the underlying budget on which the product rides are only interested in more features on which to sell the thing. Rewriting the shonky original modules can have no net gain.

Indeed, some development groups do not have time (or are not willing) to properly document their code let alone build a Maven site or produce decent documentation (say in a wiki for instance) . There is a cost associated with producing well documented architecturally sound code . Some systems can tolerate the quick and sloppy development approach (QSDA), some cannot. How many corporate shops hack triggers on the database to add business logic because they do not have the source to the proprietary system? Hope that poorly trained contractor documented his back door hacks to your legacy cash cow system (I'm sure corporate governance will catch that eventually :) because the supervisor didn't have time)! The problem is being able to determine when to apply QSDA and when to develop quality and easily supportable systems. Sadly some shops adopt QSDA as thier fundamental methodology thinking they are saving money only to disappoint users and typically end up costing more over the product lifetime.

This segues me into my next point. Most "enterprise" software is of lower quality then the QSDA code you do in house. If you don't believe me just run SCA tools against the code base and see what you come up with (or maybe looks at the database design). I found the best enterprise products (this is "enterprise" insurance software) were only equal to in quality to in house code I would call marginal. Most vendor code was at levels that your continuous integration system would break the build. So in essence what I'm trying to say is that no matter how flashy or functional a system is it can be chock full-o-bugs. You have to integrate with systems and use development frameworks built upon every anti-pattern in the book. At the end of the day very few enterprise products (with the exception of basic servers such as DNS, EMail, Wiki, some databases) are of good quality and I don't see that changing any time soon.

I agree that the bar should be set much higher. However, you just cannot treat all bugs equal; otherwise you will not be able to ship products.