Have You Forgotten A Critical Attribute Of Your Development Project?


Forget about what customers want—or at least, what they say they want—for a minute.

People with software development experience will want to talk about non-functional attributes, such as performance, scalability, capacity, usability, flexibility, maintainability, etc.  They may not be familiar with Tom Gilb’s "Principles of Software Engineering Management,” a favorite book of mine (see Amazon.com), but they would probably agree with his statement on the importance of managing critical, non-functional attributes:


The Achilles’ Heel Principle:

Projects which fail to specify their goals clearly, and fail to exercise control over even one single critical attribute, can expect project failure to be caused by that attribute.


Software architects often struggle to convince other stakeholders that strict attention to non-functional attributes is vital to project success.  But even architects and senior developers often miss one of the critical attributes.  In fact their regard for it sometimes resembles the sales team’s regard for something as meaningless (to them) as maintainability.

The neglected nonfunctional requirement? 


Operability:  i.e., the ability to actually support the software after it has been launched.


To consider whether operability is being overlooked on your project, think about your answer some questions—there are more, but here’s a starter:

  • Are operations specialists (network and database administrators, customer support teams, any others who will be running the show when it’s in the hands of its users) involved throughout the entire development process?
  • Do they gain frequent experience with the software by deploying it into production-like environments?
  • Are you delivering functionality to customers in small increments? (Just as “big bang” doesn’t work well for customers, it’s usually a disaster for operations.)
  • Do developers need permission in the production environment to see data, logs, etc., on a regular basis (or, heaven forbid, to “fix” data or configurations)?
  • Is deployment to the production a nail-biting experience?
  • Does customer support know how to use the software?
  • If customers need training, has it been done, and using what materials?  Has the customer support team (and the development team) gotten feedback feedback from these sessions?


Like most of the other nonfunctional requirements, operability provides no "business value" to the marketing team.


Until you have actual customers, that is.

Then we find that everyone wants operability.

New Book May Change My Thinking!

A while ago a friend of mine recommended a new book from Martin Fowler’s signature series: 

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation  (At Amazon.com)

I finally got a chance to spend a bit of time with it and have now ordered it.  I’ve been blogging about principles of successful deployments and it looks like this covers a lot of those topics and a lot more—and it’s sure to be better written.

I’ll keep blogging on the subject here since it helps clarify my own thinking.  But as I get a chance to read through the book I expect to further develop the things I’ve learned over the years and may even change my mind on some things.  I’ll be sure to mention the book when it has taught me something new.

Thanks, friend, for the recommendation, and thanks, Jez Humble and David Farley for writing the book—it looks fantastic!