*bilities

  • Article

Most of our customers (and most professional software developers) don't really understand how much is involved in making a feature.  It's not just the specification and code work.  It's all the other things that have to be handled.

I like to lump these into a great big aggregate that I call the "*bilities".

The *bilities are all the things that are a critical part of deploying a product but aren't a part of your normal day-to-day process.

You see, when you come up with a new feature, typically you'll sit down and brainstorm about the product, then dev, PM, and Test go off and write the specifications for the feature, then dev writes the code and test writes the test cases, and PM does whatever PM does while dev is writing the code and test is writing the test cases.

And then the testers test the code, and the developers fix the bugs and you're done - the feature is ready to put into the product, right?

 

Maybe.  It depends on how well you've dealt with the *bilities.  And what are the *bilities?

Well, there's all the things that you've got to have before you can ship.  Here are some examples:

  • Reliability
  • Localizability
  • Internationalizability (it's different from Localizability)
  • Geopoliticalizability
  • Compatibility
  • Accessibility
  • Usability (this applies to both UI AND APIs)
  • Securability (ok, it's Security, but I had to figure out a *bility for Security)
  • Deployability
  • Manageability
  • Serviceability
  • Upgradability
  • Extensibility
  • etc.

If you've not covered ALL of these, your feature simply isn't ready to ship.

Some of these are pretty straightforward for many features.  For example, if your code doesn't interact with users, accessibility isn't that big a deal.  Or if your feature is totally new, compatability may not be a big deal.  On the other hand, you need to think about how upgradable your code is - what happens when you want to add something new to your API in the future?

For Vista, we covered most of the *bilities in what were called the Basics - the Basics were just a formal process we deployed to ensure that the *bilities were covered in every single feature - all the features we deployed had to have a Basics section in their spec that discussed how the feature intersected with the Basics.

The *bilities can quite literally be make-or-break for a product.  For instance, if you don't handle Accessibility, Localizability, Internationalizability, and Geopoliticalizability you may find your product banned in certain countries.  In the US, if your application (or operating system) isn't fully accessible, you can't sell to certain governments.

In many ways, the *bilities are a tax associated with delivering a product, but there are some things that you just have to do.