Code for Concinnity

I was thinking about composition vs. inheritance today and I wanted to make everything crystal clear. Here’s some quick brain-dump of my research and thoughts:

• Use composition when possible. It delegates the dependency process to the callsite. This is a prefer composition over inheritance. Since modern programming idioms prefer composition to inheritance, most of the time using delegates and Dependency Injection to achieve composition would be a Good Thing.

• Why prefer composition to inheritance? Simply because inheritance is almost the strongest coupling you can introduce between two classes (second to friend classes in C++). We all know that coupling is bad and that separation of concern is good.

• Use Inheritance whenever necessary. An example of a necessary case is when the new functionality (injection point) needs to access the protected members of the base class.

• When using Inheritance, prefer nonpublic inheritance to public inheritance. Use private inheritance when you need to access the protected members of the base class; use protected inheritance when you need to access the protected members of the base class, while at the same time exposing them to your derivatives.

• Only use public inheritance when your derived class is a true IS-A relationship that satisfies the Liskov Substitution Principle.

• There is a good quote from somewhere:

Inherit (publicly) not to reuse, but to be reused.

Is there anything that inheritance can do but composition can’t do?

• Yes, when you want to access protected members of the base class.

• Theoretically, this could still be done using composition by having the base class pass along the required attributes, but that often quickly degenerates into passing a chain of message.

• Even if you pass an instance of the Base class to the Derived class in hope of that the Derived class can access the Base class, it’s still limited to the public interface only.

As a freelance developer, I’ve always thought that formal requirements specifications are just too much overhead. Sure, big projects in big corporations will have to ensure the budget and time-frame very accurately using rigorous methods like IBM’s RUP or the ISO approved Function Point Analysis, etc. But for a one-man show, I mean, I could have got the whole project done in the time I had to prepare the specifications, right?

Wrong

Programmers have always notoriously over-estimated how fast they can write code. Of course, we enjoy writing code and time passes by just so quickly, but it doesn’t mean writing code is as really as efficient as writing English. Many small teams shy away from formal specifications because they think they could have written the damn code by the time they’ve got the specification down.

I’ve always believed that, as much as I believed I’m a programmer with adequate skill, until a recent revelation hit me:

Writing the program is, in itself, a DAMN SPECIFICATION PROCESS

That’s right. Instead of confirming with the customer what the requirements are about in clear concise English, we somehow feel better describing the problem to a computer using programming languages. We have advanced through several decades and have lived past the dark eras of Assembly programming to higher level programming languages like Ruby, Python and idioms like functional programming. Why did we choose to move away from low level languages like Assembly and C? Because higher level languages are inherently more expressive — we can say much more with fewer words in a higher level language. In other words, high level languages allow us to program faster.

And what’s the highest level language of all?

English!!

That’s right. Surprise.

But computers can’t read English, doesn’t that mean duplication? We now need to define it in two sets of languages.

Yeah, and that upsets my DRY spirit a lot.

In an ideal world, we could understand the requirements 100% accurately, code it once in the programming language of our choice (Ruby anyone?), deliver the product and bring home the bacon. Everybody is happy

But how often does that ideal scenario happen?

The ideal never happens. Let’s face it, we need to rewrite the damn code anyway.

That’s right. Unless you are an uber skillz haxx0r incarnate, I believe you don’t expect your program to work totally correctly the first time you run it, right? For any programs that more than 10 lines long, I’m it takes at least a couple of retries at least to get it compile without errors. Even if you get it to work correctly, how many times have you written a program and say to yourself “Yeah, this is the perfect solution to the problem”?

That is, even after you get it to work technically correctly, you’ll realize there are some ways to improve it, some quirks that really shouldn’t be there. It’s called “I know it when I see it.”

See? So much for DRY, we need to rewrite it over and over. It’s our damn fate.

If you have to throw away “code,” would you rather throw away a couple of English descriptions plus some wireframes, or a full set of engineered objects?

Many Agile proponents advocate writing code as soon as possible. Ironically, it’s pretty stupid once you think about the pseudo-math behind it:

Let the total number of iterations needed be R
Let the amount of time needed for each English iteration be E
Let the amount of time needed for each Coding iteration be C

Obviously,
    R ≥ 1
    C ≥ 1

For total amount of time needed T:
    T = (R - 1)C + RN
        where N is either E or C

For example, in an ideal case, we do no specification,
just code it once and everything goes fine:
    T = C

Scenario 2: the first version gets rejected by client since we
misunderstood the requirements (or they think we
misunderstood, whatever). It took 3 times of coding:
    T = 3C

Scenario 3: we made a detailed specification, client realized
they mispresented the requirements (notice how the client seem
to understand their own faults when you just tell them in English
instead of code). It still took 3 iterations:
    T = 2E + C

Obviously, E < C. Which means we've saved time!

You see, the only case where writing the detailed specification would “waste” time is when you get everything right the first time. Honestly, how often does that happen?

So what should I do?

Should I go out and read on all rigorous processes out there? Probably, I went down that route and it was quite fun to learn each of them. But ultimately, I must also acknowledge the huge overheads those processes incur. And enforcing the client to go through rigid processes don’t always work without a full team of experienced lawyers and contract writers.

After a lot of trial and errors, the approach I’m adopting now is to have as detailed specification as possible before writing any code. It doesn’t necessarily have to be 100% accurate UML diagrams with spell-checked use cases. I find that just a set of PowerPoint slides, annotated wireframes along with some rough use case scenarios seem to work fine. I try to avoid having charts because people tend to misinterpret quite often. It’s the right mix of flexibility and details that maximizes my productivity.