Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

*bilities

*bilities

  • Comments 25

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.

  • Wow, I was minutes away from finishing a blog post on a similar topic.

    My problem revolves around the need to balance the time to get the bilities right versus getting the actual feature done (btw, you're missing performance in your list).

    I fully agree that industrial software must meet all these criteria to qualify for shipping. But in order to get the features right, you need good programmers, whose skills are often highly specialized (e.g. you can't take a random person working on the networking stack and suddenly make them a compiler writer). However, all features, every single piece of code needs to have all the bilities.

    How do you achieve that? Do you make all your programmers become security, performance, reliability, deployment, manageability, ..., experts, even though they would be way more productive just doing what they do best? Do you create dedicated positions for people whose jobs consist entirely of reviewing the design and the code for security and performance issues, with dedicated setup, instrumentation, ..., teams, thus creating additional layers of bureaucracy and process?
  • I guess monopoly doesn't come free :)
  • hmmm: Monopoly?  What does monopoly have to do with this?  I actually intentionally left consent decree compliance off the list (compliability?), because it IS Microsoft specific.

    Every single one of the *bilities I listed is one that EVERY company producing software for the world market needs to face and deal with.  Everyone who ever wants to sell to the government MUST deal wth accessibility.  Everyone who wants to sell outside the english speaking world needs to deal with localizability.  Everyone who wants to sell outside the US needs to deal with internationalizability.  

    If you're doing UI, or building APIs (even if they're internal-only), you have to deal with usability concerns.  

    Deployability and managibility are more Windows centric, but if you want your product to be deployed enterprise-wide, they're critically important - companies want to be able to configure your applications remotely, it's critically important to them.

    Servicability is all about how you deploy updates and patches to customers.  It's a very rare piece of software out there that doesn't have some ability to be updated - maybe it's a manual update, maybe it's an automatic update, but it's a real issue for real applications.

    So no, it's NOT a monopoly issue.  It's an engineering issue (which is largely Ovidiu's point).

    To answer Ovidiu's question, for Vista, Microsoft had v-teams which defined the basics and described best practices for each of them.  Then each feature team had one person in each discipline (dev, test, pm) who was responsible for that basic.  It was their responsibility to ensure that each feature delivered met the basics.  There was a lot of overhead associated with this, but IMHO it was worth it.
  • I think there is a difference between proprietary software and open source software (that is sometimes also free - as in beer). Atleast if we're talking about compatibility.

    Many open source softwares are known for its lack of compatibility through versions. (Linux is probably one of the best examples.)

    When dealing with open source software, it is often the case that the people in charge doesn't want to keep compatibility. A good reason is to flush out old and bad versions of said software. Also, these people can say (especially if it's free [beer]) "I don't want this feature. I don't get paid/credit for writing this software. If you want to have the feature, add it yourself."

    There is both an upside and downside of compatibility. If you don't want compatibilty, it is easier to deal with buggy compatibility code (the Windows 2000 source code comments can testify to that*) and easier to give support if you don't have to keep in mind that all of the different versions is doing different things.
    If you do want compatibilty, the compatibilty can grow to something unmanageable. An perfect example of this is Microsoft's operatingsystems and the various APIs that "have to" be compatible with old software. I guess that is the price one have to pay to be the world's topmost development platform. But what an awful price.


    * I haven't digged through the Windows 2000 source code. I have only seen these comments on various blogs. I don't want you to be in any legal trouble.
  • Open source has the same compatibility requirements.  If Firefox expects to become a successful platform, then they can't break their APIs from build to build.  Similarly, Linux can't change the world - at a minimum, there's an expectation of source level compatibility.

  • I decided to install the first release candidate of the new operating system from Microsoft called - as I'm sure most people know - Windows Vista. Like all users, I'm not a big fan of change so it took me a while...
  • Very useful and eloquent post, Larry.  

    For those who are still wondering why shipping Windows Vista has taken so long and been so hard, consider that each one of these '*abilities' adds a non-linear, sometimes-recursive 'time tax' to every feature and line of code in the OS.

    Designing a feature that 'just works' for 1B+ PCs with diverse HW (and diverging customer expectations) is hard enough -- but when you multiply this by the >13 *abilities Larry mentions, the complexities increase dramatically.  

    Most would be surprised by the intense quantity of work involved in adding a single checkbox to the Sound CPL (done last month based upon beta feedback - and another unbelievable story in its own right.)   But this post begins to expose some of the often-invisible and non-trival hidden costs of designing and shipping features in Windows.  

    Thanks for sharing this, Larry.  I also like the name "Abilities" much better than "basics."   :)

    * * *





  • When I read Larry Osterman's blog post *bilities from Friday, I could not help but be reminded of two...
  • > Most would be surprised by the intense quantity of > work involved in adding a single checkbox to the > Sound CPL How much work? 1,024 man-hours, including 32 brainstorm sessions with middle-level managers and lawyers? Honestly, I'm tired of the excuses coming from MS these days. You're basically saying that you can't fix your own OS due to lack of resources. Are the resources dwindling, or despite the Longhorn reset Vista codebase is still convoluted contraption?
  • > I actually intentionally left consent decree compliance off > the list (compliability?), because it IS Microsoft specific. No you didn't ^_^ I saw this: >>> Geopoliticalizability (Of course there's more to it than politics, which is why this joke is submitted as a joke.) >>> Reliability Unfortunately not a joke. That's the one which monopolies don't need, and it still shows. > It's a very rare piece of software out there that doesn't have > some ability to be updated Actually it's not rare at all. Non-flashable firmware is all too common. Your cars, microwave ovens, video recorders or DVD recorders, hot water heaters (in some countries), etc., very likely outnumber your PCs. Now I do _wish_ that bugs in some of these could be fixed. > Everyone who wants to sell outside the english speaking > world needs to deal with localizability. Nope. Anyone who wants to sell in Japan only can do so without dealing with localizability. There are a LOT of sellers in this category. Some of my work gets internationalized and localized with the second language being English, but a lot of my work has no export market. Yes I know it's trivial to fix what you wrote. Just change english to Japanese. That's enough of a fix ^_^ > Similarly, Linux can't change the world True. > at a minimum, there's an expectation of source level > compatibility. Wanna bet? (Linux isn't really better than Windows, it's just that you DO get what you paid for, plus what you can add or fix.)
  • OK, what change of bugs in the Windows edit control sneaked in with a recent security patch?

    A few hours ago Notepad saved a file and didn't tell me it was deleting all line breaks while saving.  When reopening the file, Notepad showed me what it did.  The damage was confirmed with vim.

    It has become rather clear that Internet Explorer uses the same edit control for comments in MSDN blogs, with the same effect on kiwiblue's comment as on mine.

  • In the book "Software Architecture in Practice" (http://www.sei.cmu.edu/publications/books/engineering/sw-arch-practice-second-edition.html) by Len Bass, Paul Clements and Rick Kazman they use the term "quality attributes" for these *bilities. A cool example in the book is "Idahoability" which was a quality attribute for a system where Idaho was very important for it (sorry, can't remember the complete reason...).
  • Larry, what about scalability? I didn't see that on the list. Does this mean we can expect Vista to take forever to display the contents of a folder with upwards of 1000 files in it just like its predecessors? (^;
  • Michael, scalability is not on the list because I forgot it, not because it's not important. :)

  • Oh, and to answer your question: It depends on how you're displaying the contents of a folder with more than 1000 files in it.

Page 1 of 2 (25 items) 12