DevOps Zone is brought to you in partnership with:

Mr. Lott has been involved in over 70 software development projects in a career that spans 30 years. He has worked in the capacity of internet strategist, software architect, project leader, DBA, programmer. Since 1993 he has been focused on data warehousing and the associated e-business architectures that make the right data available to the right people to support their business decision-making. Steven is a DZone MVB and is not an employee of DZone and has posted 139 posts at DZone. You can read more from them at their website. View Full User Profile

Why is the Bar Set so Low for Enterprise Applications?

10.19.2011
| 6484 views |
  • submit to reddit
It occurs to me that much of "Big IT" creates a well-oiled organization that makes broken software seem acceptable. The breakage is wrapped in layers of finely-tuned process.

Consider a typical Enterprise Application.  There's a help desk, ticket tracking, a user support organization that does "ad-hoc" processing, and a development organization to handle bug fixes and enhancement requests.  All those people doing all that work.

Why?

If people need all that support, then the application is -- from a simplistic view -- broken.

The organization, however, has coped with the broken application by wrapping it in layers of people, process, tools, technology, management and funding.  The end users have a problem, they call the help desk, and the machine kicks in to resolve their problem.

It is a given -- a going-in assumption -- a normal, standard expectation that any enterprise software is so broken that a huge organization will be essential for pressing forward.  It is expected that good software cannot be built.

We're asked to help a client create a sophisticated plan for the New Enterprise App support organization.  Planning this organization feels like planning for various kinds of known, predicted, expected failures. Failure is the expectation.  Broken is the standard operating mode.

Consider a typical non-Enterprise Application.  Let's say, the GNU C compiler.  Or Python.  Or Linux.  An almost entirely volunteer organization, no help desk, no trouble tickets, no elaborate support organization plan.  Yet.  These products actually work flawlessly.  They're not wrapped in a giant organization.

Why is the bar for acceptability so low for "Enterprise" applications?  Why is this tolerated?
References
Published at DZone with permission of Steven Lott, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Daniel Kec replied on Wed, 2011/10/19 - 7:28am

Well I think it's because those "enhancement requests" that is what makes it EE, and quite frankly every one enhancement makes minimally two bugs. If you make one flawless app which is final to some date of release your customer doesn't need support but also don't have possibility to make enhancement requests -> but the app isn't EE any more isn't it?

Piotr Kochanski replied on Wed, 2011/10/19 - 9:35am

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.

Michael Remijan replied on Wed, 2011/10/19 - 9:32am

The C compiler, Python, or Linux are, in essence, stand alone projects where enterprise project can integrate dozens of different systems which, from the end user's perspective, is all wrapped up nicely into a Web App.  Any problems with any of these dozens of systems and the "Web App" is down.  You need an organization of people to manage this and pull it all together. 

Charles (Ted) Wise replied on Wed, 2011/10/19 - 3:13pm

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.

Nicolas Bousquet replied on Wed, 2011/10/19 - 6:12pm

Enterprises tend to choose the cheapest possible solution. The decision maker is typically a finance guy that will never use the software anyway and has no idea of the user needs. Politics and human relation have a key role. The boss may think that you absolutely need to use java or soa, even if the best solution in the market is made in C or worse lisp... One might want to choose the product of a friend and try to have a free trip to the vendor headquaters or a job for his brother. Part of the software that will be specific for this company will be used nowhere else. In a sence, it is beta, and of course has the behavior of beta software. And well users themselves don't really know what they need. Counting all of that, how the software in question could be any good?

Rick J. Wagner replied on Wed, 2011/10/19 - 8:16pm in response to: Piotr Kochanski

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

Jan Kotek replied on Thu, 2011/10/20 - 3:15am

> ...the GNU C compiler... These products actually work flawlessly.

Is this a joke? Opensource stuff is just crawling with bugs nobody is bothered to fix. 99% of opensource projects is useless junk (just have look at SF). I think average quality/success rate is actually better in corporate world.

And yes, I am writing OS software.

J Casey replied on Thu, 2011/10/20 - 4:25am

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.

J Casey replied on Thu, 2011/10/20 - 4:26am

On further thought I think I just 'got' the essence of your article - what if we were to take all the money attributed to help desk and user support and sink it into making the product 100% bug free (i.e. so it works as per the user manual). Would we save money? That might get those guys steering the budget interested in the to-do list.

The help desk could be replaced with a recorded voice message "The product is fine. Is your network cable connected?, Is your keyboard working?, Do you have the latest OS service pack? ...."

Steven Goldsmith replied on Thu, 2011/10/20 - 10:07am in response to: J Casey

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.

Steven Goldsmith replied on Thu, 2011/10/20 - 10:06am in response to: Jan Kotek

Read my other post about enterprise software quality. Run SCA tools against Velocity, Tomcat, etc. and you might be surprised. Also realise the a lot of in-house and enterprise software is built upon OS frameworks and use OS servers, etc. The bugs and quality become part of that project.

Jianping Roth replied on Fri, 2011/10/21 - 1:53pm

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.

Lund Wolfe replied on Sat, 2011/10/22 - 7:44pm

I assume by "enterprise" you mean corporate wide internally built applications. You can either build a quality, trouble-free, intuitive application, or provide good user documentation, or provide phone support.

It is commonly held that better developers are hired by dedicated software companies to build commercial shrink wrapped software or volunteer to build quality open-source software (that becomes popular) than are hired for corporate IT. I've worked almost entirely in corporate IT, so I can't speak to that. There is a strong sense of "good enough", too. The users are a captive audience required to use the application and they acclimate to the fact that some stuff is broke or of poor quality/performance. As long as a problem isn't a show stopper and they can get their work done, they don't care, and features that enable them are far more important.

It may be cheaper to hire mediocre developers and surround them with a support infrastructure or it may not even be practical to expect to be able to find enough of the best developers willing to work in the corporate environment. It may be more practical to sustain a consistent level of quality, even if mediocre, by using a process and hiring (and cycling through) mediocre developers and support people with fairly specific roles than to depend on really good developers who may or may not be on the payroll and available at any given time.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.