Mar 09

On Functional Specifications

Reading through Christoph’s take on Joel’s latest “How to be a Program Manager“, I stumbled across the term “Functional spec”.
Coming from a C.S. background (admittedly, a sin of my youth), I continue to struggle with the term “specification”, as I associate it with

I don’t think you can fully understand the problem domain, the software to be written and it’s interaction with users or other systems by creating a text document in plain English (or any natural language of your choice) deliberately sprinkled with some graphics – of course you can’t do it with predicate logic either.

The main reason is that while creating your “specification” you will lack the feedback you get from actually implementing the system and from putting your code in front of users. This is way more valuable than sitting in an ivory tower waxing eloquently about a system’s intended features.

So I suggest to put another label on the document Joel is talking about – “Functional Overview”, “Functional Description” or “Functional Outline”. Don’t burden a useful document and its intended purpose with putting an inappropriate and misleading label on it.

Now that we this issue out of our way, we can start having a more useful discussion about what to put in the “Functional spec”, err, “Functional Overview”. Here’s my take on it:

Here’s what we know now. This is what we have to be aware of when starting out. This is how the interaction with the user might work out. Here are the external dependencies on other systems.

Just write enough “Functional Overview” that you are confident in your ability to move through the problem domain and take turns as you learn new things implementing the system and putting it in from of customers. You will be way better off investing your energy in defining the expected inputs & outputs of the system (and its components) as automated functional, acceptance and unit tests. And getting the system out to users & testers in order to get real feedback of a real system and learn about the shortcomings of your initial specification.

There. I said it.

Mar 09

Effective C++ – Third Editon

Re-Read Effective C++, Third Edition by Scott Meyers over the weekend – a fantastic book about the intricacies of C++.

The very existence of such a book is a testament to the many things which are wrong with C++.

[Update: As I’m writing this, Burce Eckel has posted a thoughtful article about The Positive Legacy of C++ and Java – which approaches the topic of C++ being a complex & convoluted language from a different angle]

[Update: John D. Cook mentions another interesting post (dating back from 2007) on this very topic]

[Update: The C++ FQA Lite sums up the main intricacies quite nicely]

Mar 09

Is Quality Dead?

This looks like the start of an extremely interesting series: Quality is Dead #1: The Hypothesis.

Another factor contributing to this crisis are insanely short release cycles (even for desktop software) and the expectation that each major update has to introduce substantial new features. Lot’s of them. There’s no more time to polish & deepen existing features.