The Trouble With Software (and what to do about it)

We welcome your contribution.

Posted in General Overview by Ernie Schell on September 6, 2011

This site is a place for you to post comments, gripes, insights, and complaints about the difficulty of implementing, using, managing, and coping with business software applications in the real world.

While business applications are a necessary evil, they often seem to impede more than they enable.  And the blame for this applies equally to users as it does to system vendors: poor training, inadequate or absent documentation, clumsy implementation, incomplete integration, dirty data, and a myriad of traps and trappings confound even good systems that are otherwise potentially beneficial. But in many cases the culprit is indeed the systems themselves, which are often poorly written by multiple teams over many years, with little sense of overall coordination of the final product. And of course that means that they are inherently incapable of meeting the real needs of real users in the real world. To say nothing of the fact that the “generic” user doesn’t exist. YOU need something tailored to YOUR needs in YOUR environment. And the irony is that this painful result will be your reality even if the software is designed in-house (or by third-party contractors), instead of coming from a systems vendor as a packaged solution.

It almost doesn’t matter what methodology is used by the developers (third-party or in-house). The failure to truly meet real world needs efficiently and effectively seems to be endemic to the business. But I have provided categories in which you can address these methodologies specifically, if you wish.

Of course, few of us use just one system, and getting them all to work together is not only difficult, but often the cause of much of the pain suffered by systems users. And let’s not overlook one of the most significant issues, which is called “scope creep” when the system is being developed or customized, but is simply the ever-evolving business rules that any system needs to manage and enable. As these change during any given year, the “good fit” a system may have had will wobble and degrade and may ultimately collapse under its  own weight.

Some of these things are so obvious we don’t bother to gripe about them, or we use “work-arounds” which make life easier for a user or group of users but may actually just shift the pain and magnify it for other users or other departments or business units.

Will your contribution here be anything more than a way to “sound off”? I hope to incorporate these comments into a monograph on the subject sometime in 2012. Until then, blast away! And thank you in advance for your participation.

Ernie Schell
Director, Marketing Systems Analysis
A division of Systems Consulting International, LLC


One Response to 'We welcome your contribution.'

Subscribe to comments with RSS or TrackBack to 'We welcome your contribution.'.

  1. A primary difficulty in attempting to bridge the gap and “solve” the problem cited here is the fact that so many attempts at building a custom solution, or customizing an existing solution, wind up as abject failures. Perhaps because of human nature (e.g. rubbernecking at an accident scene), the stories of failure seem to travel farther and faster than any of success. As such, almost everyone in business has either lived through, or can readily cite, an example like …… “Well, we hired the VP’s neighbor’s nephew to build this custom module, and it seemed like it was going to work, but then things started going wrong, and he went off to be a pro surfer …..”

    As noted in Ernie’s initial post, and many other comments on this site – the requirement to build and adapt systems to fit the increasingly complex business needs are only expanding – yet “customization” becomes more and more of a four letter word as more attempts are made, and more systems crash and burn.

    Creating an environment in which software can be continually customized and adapted to the needs of an organization, at a reasonable cost, is a quite difficult feat, and requires proper software design, proper development methodologies, and the proper personnel to be able to do it successfully. All of these are, of course, doable.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: