The Enterprise Completo

CompletoIn the past few weeks as I wandered Chile’s ruggedly stunning Patagonian wilderness, traversed seemingly infinite salt flats, and explored vast alpine plateaus of the Atacama desert, I admittedly wasn’t thinking much about engineering or enterprise software.  Well, except for my brief and distant glimpse of the Atacama Large Millimeter Array (ALMA) observatory – which unfortunately was not admitting wandering visitors.  Aside from that one distraction, I was in another world.  This fact no doubt magnified my puzzlement as my wife challenged me to relate something in our Chile expedition to engineering and enterprise software.  And the answer would be realized in the same context for which many great answers throughout history have come forth into the world:  lunch.

But a little background first.  When visiting this vast and varied South American country, one fact remains clear: Chilenos -especially in the urban center of Santiago- sincerely adore their hot dogs.  In their quest to perfect presentation and delivery of the almighty Frankfurter, they have created what may very well be the modern world’s ultimate hot dog.  Starting from a substantial load-bearing bread bun, the sausage is topped with loads of cheese, miles of sauerkraut, heaps of palta (mashed avocado), and a mountain of chopped tomato.  The finishing touch is an utterly ridiculous drenching of mayonnaise, probably about two spoons less than a lethal dose.  A sight to behold, it is called, appropriately, a Completo.  Having amassed all the fat and cholesterol in the world into one formidable, yet portable meal delivery mechanism is the very definition of completion.  Ordinary versions are about the length of your typical hot dog and typically eaten in pairs (believe it or not), but the real deal are the titanic foot long varieties which threaten the age of men to come crashing down.  It’s not served on a plate, but what is best described as a miniature dry dock.

“This…”  I muttered  as I struggled to heft the Completo aloft, my arm buckling from the weight of a thousand mayo bottles.  “This is enterprise software.”

Let me qualify that further.  One might ask what a gargantuan hot dog bathed under a tsunami of mayonnaise tastes like.  The answer:  it tastes like mayonnaise.  I tried a couple different varieties such as the Chacarero, which throws green beans (of all things ) into the mix.  Not surprisingly, that variant also tasted like -you guessed it- mayonnaise.  That’s right, I had trouble telling my Completos apart, being the amateur Americano that I obviously was.  Some investigative action was required – and some engineering disassembly of my Completo commenced, probably horrifying locals in the process.  My discovery was that the constituent elements of my Completo were all quite tasty and remarkable in of themselves, but I’d be hard pressed to detect any of that under an ocean of mayo.  Armed with this new found knowledge, my second Completo lunch in Valparaiso was more tactical.  I ordered the plainest Completo in the country consisting of only cheese aside from the sausage.  Additional toppings I would borrow from the ample surplus in my wife’s laughably ginormous sandwich, which could be best described as an entire pork farm on an island of bread with an avocado tree thrown in for good measure.  The tactical approach was mighty tasty.

The Completo is a perfect metaphor for what we find in most enterprise software today, Product Lifecycle Management (PLM) especially.  It illustrates a paradoxical point in the dilemma of delivering enterprise software value and capitalizing on it strengths, but remaining palatable to the end user.  It helps explain why we are where we are.

And so here are a couple of thoughts that I consider to be rather universal truths:

1.  There are bits of amazing functionality in most enterprise software products.  It’s in there.  Somewhere.

2.  Most people are seriously overwhelmed by enterprise software, and consequently aren’t terribly impressed.  In fact, we hates it, precious.

Enterprise software burdened with the Price of a Thousand Functionalities, often struggles to make some of the more compelling features both relevant and transparent to the end users.  In other words, even though there’s supposedly a lot of flavor under the hood, too much of enterprise software tastes like mayonnaise.

The mayo is the mountain of menus, buttons, frames, widgets, and excess clients illustrative of most enterprise software today.  It’s undoubtedly a contributor as to why such a small percentage of total functionality in these products is actually used in deployed environments.  Sure, many products have some methodology to tailor the interfaces down to digestible levels. However this approach is too heavy handed, because it often removes the discoverability that is necessary for users to grow with a piece of software as their skills improve and expand.  Furthermore, techniques like command suppression becomes a crutch, such that developers no longer bother to understand the product presentation and efficiency as a whole.  OOTB menus that scroll off the screen is ripe evidence of usability failure.

The key is not to just add features, but make them a natural progression of the features that came before such that the end product follows a cohesive and continuous progression throughout its functional range.  But for the most part,  we have an endless supply of bolt-ons and afterthoughts that are just piled on top to the point that the really interesting stuff is mostly lost in translation.  Functionality that isn’t readily discoverable might as well not exist.

We’re all forced to eat the same Completo, and attempt to eat around the mayo.  It’s enough to give anyone some enterprise-sized indigestion.  Anyone still hungry?

  • jan takke

    Hi Ed, I always like to read your humorous blogs! Fortunately you didn’t use too much lettermayo so I could easily find the truth!

    • Thanks for reading, Jan! I aim to provide a condiment free perspective!

  • Ross Bernheim

    Software bloat is an old, old problem and infests not just enterprise software.

    Steve Jobs got it right when he said that the technology should appear as simple as a toaster. He was exaggerating just a bit, but the philosophy has made Apple a most successful company and quite profitable. People are willing to pay a premium for the polished, consistent and almost sparse interface of the Apple aesthetic.

    It is not just feature bloat, but bad user interface that is the problem. Screens that look pretty but put buttons far away from the normal actions and without hot keys so that you need to take your hand from the keyboard and move the mouse across the screen to press a button. And after having pressed the button you need to mouse back across the screen to the next button to be pressed before you can get back to the keyboard.

    Marketing people want more features so that no one will be wanting any feature, no matter how rarely it is used by how few. Marketing people want the screens to look pretty.

    Customers want it to look pretty and have the most features. It is easier to look at a sheet comparing who has the most features rather than looking at if it has the features you need and not a lot of extra bloat. Pretty screens sell to the upper management who don’t have the technical chops or time to properly evaluate the software. “That one looks good. Does it do what we need?”

    The programmers will do whatever is easiest to do to satisfy their sales people and whoever else screams the loudest. Research about what the users really do and what they need to accomplish the tasks with the least effort is rarely done and it is even rarer that it is paid attention to.

    So we end up with a Completo.

    • Well said, Ross. So why do you think most everyone – except perhaps Apple – has become so lazy with regards to feature bloat and lazy UI? Is it because sometimes “best in class” is whatever you can get away with?

      • Ross Bernheim

        Best in class has become a left handed compliment. Apple has also succumbed to bloat, witness iTunes. And I have just had the “pleasure” of trying to wrangle the latest version of iMovie to do some rather simple things. It also displays some lack of polish and attention to detail in a number of areas.

        The feature bloat is due to the fact that it is easier to market it as having the most features. “See, we have more check marks on this list of features than our competition!” A much easier sell than explaining why your program is better and why all those non-used features are bad.

        The bad user interface problems are a lack of user input, or biased user testing. Programmers should read the “Apple User Interface Guidelines” book and the “Programmer’s Book of Rules” by Ledin and Ledin. Digest these then program.

        Also, programs should be held to a reasonable level of merchantability. Is an inventory control program that has a purchasing module that doesn’t allow for taxable versus non-taxable purchases even merchantable? How about an accounting program that is marketed for manufacturing and doesn’t allow for multiple vendors and multiple vendor part numbers for a part?

        Am I picky? Yes. When you spend a lot of money on a program and invest a lot of additional time and manpower to install it and work with it, you should expect it to at least do the basics and not get in your way!

        • The Apple User Interface Guidelines book is hugely important to Apple’s success, IMHO. If only enterprise software vendors would adopt similar guidelines! Instead I see different applications within one suite that look, feel, and behave wildly differently. I see dialogs that are functionally identical or at least extremely similar that look completely different from each other. In this application you pick from a list of possible values on the left and your choices are copied to the right but in that application you select from a column on the right and copy the values to the left.

          The other maddening interface problem is having far too many controls scattered willy-nilly around the screen. What? You didn’t realize that the red-circled X in the error dialog window is actually a button that shows you more information about the error? For Shame! You didn’t realize that that little 8×8 cluster of pixels in the lower left corner of the third pane in the left window was actually a control that opened a new menu? Where have you been?

          • Ross Bernheim

            My feeling is that the programmers should sweat once so the users don’t have to every time they use the program.

            The not invented here and engineer/programmer egos get in the way. The classic example was in the very early days of the Macintosh computer. All programs except graphics programs used command + P to print. Graphics programs all used command + ;. User complaints were so loud and consistent that all graphics programs changed to command + p with their first upgrade. It was not Apple driven, but customer driven. The users demanded a consistent interface.

            Functionality and consistency are important in trying to get productivity. Pretty doesn’t count. Pretty is nice but please make it subservient to usefulness.

          • I agree Ross… the best cooks eat their own dishes. But how often are the enterprise programmers totally disconnected from even a vague description of a wordy use case, or an actual (living) user, or first hand experience with the needed task?

          • Ross Bernheim

            Supposedly there is a feedback loop from user to programmer for enterprise software. It is not a good one.

            The people who are doing the installation and customization at the user’s site are supposed to feed back the user problems to the programmers. It doesn’t work well at all.

            The feedback is far to late in the process to begin with. Well after a lot of the problems are coded into the program. Secondly the feedback is second hand or worse at best.

            While there is a lot of programmer ego. It is not the only cause. Even the best programmer is constrained by those in charge who have other priorities than the end user of the program.

          • Great examples Scott, I’ve seen all too many examples of massive inconsistency, button treasure hunts, and more panes than a window factory.

            Part of the problem is enterprise applications are a composite of functionalities from various acquired technologies and sub-products… sometimes over decades. Those features are built by different team at different times, probably on different planets. They are integrated at minimum cost (bolt on is more like tape on these days), and the end result is frankensuite.