*bilities

re: *bilities

Ovidiu — Fri, 29 Sep 2006 21:17:13 GMT

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?

re: *bilities

hmmm — Fri, 29 Sep 2006 23:58:31 GMT

I guess monopoly doesn't come free :)

re: *bilities

LarryOsterman — Sat, 30 Sep 2006 01:02:14 GMT

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.

re: *bilities

Fredrik Ullner — Sat, 30 Sep 2006 01:27:21 GMT

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.

re: *bilities

LarryOsterman — Sat, 30 Sep 2006 10:35:43 GMT

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.

Some Thoughts on Windows Vista

John's Adventures — Sat, 30 Sep 2006 17:36:55 GMT

I decided to install the first release candidate of the new operating system from Microsoft called -&nbsp;as I&#39;m sure most people know -&nbsp;Windows Vista. Like all users, I&#39;m not a big fan of change so it took me a while...

re: *bilities

Steve Ball — Sat, 30 Sep 2006 22:04:40 GMT

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." :)

* * *

I know about some o' dem *bilities!

Sorting It All Out — Mon, 02 Oct 2006 09:32:05 GMT

When I read Larry Osterman's blog post *bilities from Friday, I could not help but be reminded of two...

re: *bilities

kiwiblue — Mon, 02 Oct 2006 13:07:31 GMT

> 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?

re: *bilities

Norman Diamond — Mon, 02 Oct 2006 14:20:31 GMT

> 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.)

re: *bilities

ndiamond — Tue, 03 Oct 2006 07:01:25 GMT

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.

re: *bilities

andy — Tue, 03 Oct 2006 13:46:47 GMT

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...).

re: *bilities

michael maniscalco — Tue, 03 Oct 2006 17:37:40 GMT

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? (^;

re: *bilities

LarryOsterman — Wed, 04 Oct 2006 22:58:30 GMT

Michael, scalability is not on the list because I forgot it, not because it's not important. :)

re: *bilities

LarryOsterman — Wed, 04 Oct 2006 22:58:55 GMT

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.

re: *bilities

Jon — Wed, 11 Oct 2006 13:25:08 GMT

You can also add documentation to your list of *bilities. Everytime we change the GUI in our software, some poor documentation specialist gets the responsibilty of updating the product documentation.

re: *bilities

vince — Fri, 13 Oct 2006 16:28:26 GMT

don't forget portability too, it's one windows programmers often neglect.

Larry Osterman s WebLog bilities | Outdoor Ceiling Fans

Larry Osterman s WebLog bilities | Outdoor Ceiling Fans — Sun, 31 May 2009 15:15:51 GMT

PingBack from http://outdoorceilingfansite.info/story.php?id=2651

Larry Osterman s WebLog bilities | Outdoor Ceiling Fans

Larry Osterman s WebLog bilities | Outdoor Ceiling Fans — Sun, 31 May 2009 18:44:57 GMT

PingBack from http://outdoorceilingfansite.info/story.php?id=20287

Larry Osterman s WebLog bilities | Menopause Relief

Larry Osterman s WebLog bilities | Menopause Relief — Tue, 09 Jun 2009 03:06:15 GMT

PingBack from http://menopausereliefsite.info/story.php?id=41

Larry Osterman s WebLog bilities | garden decor

Larry Osterman s WebLog bilities | garden decor — Sun, 14 Jun 2009 10:00:08 GMT

PingBack from http://gardendecordesign.info/story.php?id=6176

Larry Osterman s WebLog bilities | unemployment office

Larry Osterman s WebLog bilities | unemployment office — Tue, 16 Jun 2009 10:35:03 GMT

PingBack from http://unemploymentofficeresource.info/story.php?id=5194

Larry Osterman s WebLog bilities | fix my credit

Larry Osterman s WebLog bilities | fix my credit — Wed, 17 Jun 2009 05:04:13 GMT

PingBack from http://fixmycrediteasily.info/story.php?id=11006

Larry Osterman s WebLog bilities | low cost car insurance

Larry Osterman s WebLog bilities | low cost car insurance — Wed, 17 Jun 2009 07:46:18 GMT

PingBack from http://lowcostcarinsurances.info/story.php?id=3341

Larry Osterman s WebLog bilities | fire pit

Larry Osterman s WebLog bilities | fire pit — Fri, 19 Jun 2009 09:09:26 GMT

PingBack from http://firepitidea.info/story.php?id=871