An iterative incremental software development process

Scrum Software Development

Subscribe to Scrum Software Development: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Scrum Software Development: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Scrum Authors: Pat Romanski, Stackify Blog, Ken Schwaber, Eric Robertson, XebiaLabs Blog

Related Topics: Scrum Software Development, Java Developer Magazine

Scrum: Article

Never Mind the Quality, Feel the Width!

This was the title of a British TV sitcom in the late 60's

Never Mind the Quality, Feel the Width" was the title of a British TV sitcom in the late 60's (yes, I really am that old), which has nothing to do with Java software development. Or does it?

The more I talk to people about the issue of Java software quality, the more I am reminded of the name of that seemingly ridiculous TV show. It seems to me that however much we talk about the need for quality in software development, it's an issue that takes a backseat to the "width" - by which I mean the number of feature requests that get crammed into our development projects.

Many years ago, I worked for a company called Data General. Anyone with more than one or two gray hairs may remember DG as a minicomputer manufacturer (guess what - before Eclipse was an open source IDE, it was the name of a minicomputer made by DG). DG finally passed away in 1999, when what was left of it was acquired by EMC Corporation, but many people remember that back in the '80s, DG had quite a reputation for innovation, as captured in the 1981 book by Tracy Kidder, Soul of a New Machine.

Anyhow, the point of all this reminiscing is to illustrate that, back when I worked in the software R&D group at DG, we took software quality seriously. If we found a bug in a released software application, we'd run around like crazy until we fixed it, and send out a patch (a real patch, back in those days) to fix the problem, pronto.

Once I left DG in 1989, and moved into the wacky world of Windows/386, I was astonished at how buggy released software could be. That was my introduction to the great quality/feature tradeoff debate, and it's fascinating to me that today, almost 20 years later, that issue still exists.

Joe Winchester wrote a nice piece about quality versus features in January's JDJ; just a single page, that you could easily have flipped past if you weren't looking for it, but good stuff. Joe was mostly talking about usability in his piece, but that's just as much a part of software quality as bugginess. "It disheartens me," he said, "that the basic task of analyzing, understanding, and tooling for the user's most simple scenarios have been overtaken by an obsession to cram as much functionality as possible into the hardware."

In my own company, we spend a lot of time talking to people in the software industry about quality issues. When I first started out in this area, the biggest mistake I made was assuming that people at senior levels of management would be deeply concerned about the quality of the software being written in their companies. How wrong was I about that! It's not that people don't care about software quality; it's that the people who care, for the most part, are developers, technical managers, and architects, who don't necessarily have the power to bring the necessary resources to bear on solving the problem.

And these people are frustrated that they can't do more to improve quality practices, because at higher levels in the organization, or in the lines of business, there are often low expectations of the IT group's performance.

In February of this year, Forrester Research published a paper titled "Closing the CEO-CIO Gap" and subtitled "CEOs and CIOs Need Loftier Aspirations For IT's Contribution." The report indicates that CEO satisfaction with the performance of IT in their firm is high: 59% of CEOs surveyed were "satisfied or very satisfied" and 27% were "neutral." On the face of it, that seems good, until you look at the CEO's expectations of the IT department: only 28% of CEOs saw their IT departments as proactive sources of business innovation, and that number dropped in smaller companies of less than 1,000 employees.

So it's not surprising that software quality isn't seen as an important boardroom issue - we as an industry have trained our customers to expect poor quality. It's a bit like asking me whether I'm satisfied with the customer service provided by my cell phone network provider - well, yes, I suppose so, but that's only because I know that all cell phone network providers provide miserable customer service - so I never call them.

So, what can we do to turn this situation around? We want to do a better job, we really do - but we are constantly under pressure from the business to add more features, and to do it all in less time. So something has to give, and that something is usually unit testing, coding standards, usability testing, refactoring to make the application easier to maintain - all those things we know we should be doing but that we don't absolutely have to do to get the application out the door.

What we can do is start to defend our projects against the feature squeeze. Unless we start to measure what we are spending time on and the value that work delivers to the project, we have no leverage for pushing back when the pressure is on to get more features done in less time.

In his paper "Controlled Chaos: Living On The Edge" written back in 1996, Ken Schwaber made the distinction between defined processes, which perform the same way every time, and empirical processes, which by their nature are "chaotic and unrepeatable, requiring constant measurement and control through intelligent monitoring." And, you guessed it - software development is an empirical process, requiring constant measurement and control - otherwise, you get unpredictable results.

So, for those of us who care about the quality issue, and think we can do a better job, my recommendation is to look into those things that can be measured for leverage: basic quality metrics such as defect rates, unit test coverage, and coding standards violations that, in conjunction with the adoption of an agile methodology such as Schwaber's Scrum, can help bring some order to the chaos, and measure the impact of trying to cram more features in without flexing project timescales.

Then, when the customer comes by to say that he or she needs the delivery date to move forward by a month, but still needs all the same features in the finished product, we can have some way of explaining why that can't happen unless something else gives.

After all, as an industry, we should care about the quality as well as the width.

More Stories By Nigel Cheshire

Nigel Cheshire is CEO of Enerjy Software, a division of Teamstudio Inc. He oversees product strategy and has been driving the company's growth since he founded it in 1996. Prior to founding Teamstudio, Inc., Nigel was co-founder and principal of Ives & Company, a CRM solutions consultancy. He holds a Bachelor of Science degree in computer science from the University of Teesside, England.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.