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


Amazon’s Kindle glitch and the “always-be-shipping-code” mentality

Posted in Development - General,General Overview by Ernie Schell on March 1, 2013

Richard Nieva has hit a nerve in PandoDaily on this very important subject. Take a look.

Advertisements

Why IT Projects Go Wrong

Posted in General Overview,Programming by Ernie Schell on December 9, 2012

Thorin McGee writes in Target Marketing magazine: “When it’s time to implement new technologies, the focus needs to be on execution [and] internal communication….” Using the Romney campaign as his focus, McGee notes that “Ars Technica reported that the multiple vendors hired to develop ORCA [the campaign’s get-out-the-vote system] weren’t in communication [with each other] and didn’t see each other’s code until Election Day. Romney Digital Director Zac Moffat told CNET there wasn’t time for adequate beta and load testing. At one point, ORCA had so much data coming and going that the ISP mistook it for a DNS attack and shut it down.”

In short, they made every mistake in the book! Most of all, as the sheriff said in Cool Hand Luke, “What we’ve got here is failure to communicate!”

5 Common Mistakes Writing User Stories in Agile Development

Posted in Agile Development,General Overview by Ernie Schell on December 9, 2012

Krystian Kaczor writes on the Scrum Alliance Website: “Most of the issues with gathering requirements in agile software development and agile testing derive from issues with User Stories. Somehow expressing requirements in such a simple form causes a lot of trouble to agile teams.”

He further asserts that mistakes in User Story scenarios lead to wrong Test Cases, a poor understanding of requirements, and inappropriate implementation, which can be a “direct cause of rejecting the deliverables of the iteration.”

His five most common mistakes people make writing User Stories:

1. Not clearly identifying who “The User” is

2. Not understanding the Business Role of The User

3. Defining the Business Role incorrectly

4. Providing no Business Value or Benefit for The User

5. Defining no Acceptance Criteria or Conditions of Satisfaction for The User

As a perfect analog to these Role & Development ambiguities, there is also what I will call “Function Ambiguity.” For instance, how do you define “Customer Relationship Management?” Everyone probably has their own way of conceiving what it is, so how in the world are developers supposed to meet a generic set of needs and requirements, since, in Venn Diagram style, there is probably a small area of overlap among these different definitions. For a good example of this, see “Defining CRM: Thoughts from three experts” on the Marketing Sherpa blog.

Software Development Failures Plague 36% of N. Amer. Enterprises

Posted in Development - General,General Overview,Programming by Ernie Schell on December 9, 2012

eWeek reports that “despite the availability of a wealth of development tools and agile methodologies, an alarming 36 percent of the 200 North American organizations surveyed in a recent study found defects in new releases that had gone into production, according to CA Technologies.”

To add insult to injury, “only 4 percent of those surveyed claimed that errors are never found in production releases. This means that many organizations are launching buggy applications to market and having to solve for them later with software updates and patches.”  To compound the problem, “applications are often released with reduced functionality, according to 70 percent of those surveyed,” according to the CA Tech study.

“North American businesses are under pressure to deliver increasingly complex applications, and at a much faster rate than ever before to keep pace with customer demands,” said Shridhar Mittal, general manager of service virtualization at CA. “Unfortunately, IT budgets are not increasing at the rate of change inherent in today’s highly distributed composite applications. This causes serious constraints to software development, resulting in delays and failures in delivering new software features to market.” Not surprisingly, Mittal suggests that service virtualization is an excellent “virtual environment for software application testing that cuts out constraints or barriers to delivery.”

Harvard’s Cybersymposium

Posted in General Overview,Programming by Ernie Schell on November 5, 2012

At Harvard Business School’s 18th annual Cyberposium on November 4, 2012, Mariah Levitt, senior usability specialist at Continuum, said candidly: “One of the most embarrassing things in the human factors and ergonomics field is that software products we use are so hard to use.”

See Comment No. 4.

The Customer Value Proposition

Posted in General Overview by Ernie Schell on July 8, 2012

TBK Consult has an excellent post on its blog that speaks to many of the issues covered here. One key quote: “Most people in the software industry will agree that there is more to developing software than programming. Programming in itself is maybe 5-10% of the effort. The software development value chain is long and requires many more competencies than mastering the technical frameworks. Domain experience, design, product management, project management, prototyping, UI expertise, integration, testing, support, documentation and communication (between people) are some of the other elements in the process.”

The Truth About IT Projects

Posted in Development - General,General Overview,Programming by Ernie Schell on March 20, 2012

For over twenty-five years, Allan Kelly has held just about every job in the software world, including: system admin, tester, developer, architect, product manager, and development manager. Today, he is based in London and works for Software Strategy Ltd. helping companies adopt and deepen agile and lean practices through training, consulting, and coaching. He specializes in working with software product companies, aligning company strategy with products and processes. His article, “The Truth About IT Projects,”  tells it like it is!

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
ernie@schell.com

“Plus ca change, plus c’est la meme chose!”

Posted in General Overview by Ernie Schell on August 30, 2011

Five years ago in Technology Review there appeared an article with the same title as this blog, The Trouble With Software, which highlighted the “singular problems” of the software business. It is, if anything, even more timely today. See what you think, and please feel free to contribute your experience, thoughts, observations…..

Braille on Parking Garage Elevators

Posted in General Overview,Programming by Ernie Schell on August 30, 2011

I recently thought that having braille floor numbers on parking garage elevators made no sense. Why would anyone who can’t read the elevator buttons want to drive a car unaided? And if they are accompanied, then why have the braille markings? Of course, why not? And why discriminate? But my first thought was that it made no sense. If I were to transfer this thought to programming, I would not allow for a set of functions because to me, the programmer, they made no sense. On further reflection, though, I realized that a blind person in a parking garage could easily wish to go back for a forgotten item or to visit the restroom, etc. — any number of reasons having nothing to do with driving — that would require them to determine which button is which on their own. It struck me as an excellent lesson in the perils and pitfalls of systems development.

Next Page »