HMK's Spurious ThoughtsBiased / Nicht immer ausgewogen

Jeff Attwood – The Ugly American Programmer:

Advocating the adoption of English as the de-facto standard language of software development is simple pragmatism, the most virtuous of all hacker traits.

Let’s face it: If you aren’t able to read & write English in a reasonably fluent fashion, you’re in trouble – you won’t be able to participate in any discussion or project on a global scale. Plus, you’ll be late to every party – and you like the latest fad as everyone else, don’t you?

Yup, this requires some work on your behalf. Get over it and start working on it. Right now.

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

• using a formal language, e.g. predicate logic
• formal verification of programs
• defining the complete input, output and behaviour of the software using these tools.

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.

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]

In stackoverflow podcast #36, Joel & Eric are waxing eloquently about how adhering to the principle

Be liberal on what you accept and conservative in what you send.

causes massives problems for Web browser developers. While I understand that having a strict HTML / Javascript parser would ease our pain as engineers tremendously, I would argue that this very principle actually caused the explosive growth of the web in the first place. It opened up building web pages to thousands, if not millions of people whose brains aren’t wired in the strange ways tradional programmers’ brains are wired. A strict HTML parser spitting out cryptic error messages (and that’s all you get from a strict compiler, trust me, I’ve seen them all) would have stopped them dead in the tracks.

Jeff Atwood has a slightly different, but interesting angle on the topic.

Just to beat an already dead horse into the ground…

A birds-eye (but nevertheless important) view of why “Just use Unicode” isn’t the solution to all i18n problems: Pet Peeves – Unicode.

(Via Sam Ruby.)

Guide to Writing Testable Code.
Excellent stuff. Make sure to click through:

Quit Putting Your Solution In My Feature Request!

Getting feature requests instead of solution requests – priceless.

…somebody touched a nerve with Uncle Bob:

Do you want to know the real secret behind writing good software? Do you want to know the process that will keep your code clean? Do you want the magic bullet, the secret sauce, the once and for all one and only truth?

OK, here it is. Are you ready? The secret is…

The secret is…

Do a good job.

Oh, yeah, and stop blaming everything (and everybody) else for your own laziness.

And to do a good job, you gotta work hard on improving your code and your skills. Every day.

What did you learn today that makes you do a better job tomorrow?

Animated Sorting Algorithms.
For those who haven’t read neither “Algorithms and Data Structures” by Niklaus Wirth nor “Algorithms in C” by Robert Sedgewick (both available in our companies engineering library).
(Via Ned Batchelder)