Judge by API

I think the best way to judge about the quality of a developer is to look at the API he has designed. If he really thinks about his code he designs the API with extreme care (here the C++ variant):

• clean formatting


• concise naming of methods


• no redundant methods, if necessary provide default parameters instead of multiple similar methods


• implementation specifics like headers of third-party libs don't shine through


• only few public methods


• and even fewer virtual methods


• short parameter lists; instead of long parameter lists use parameter objects with senseful default values


• comments on dependencies


• thorough documentation, embedded code samples

I could go on and on. Such classes can be used like a breeze.

Unsettling calm

After a while of heavy fighting the beast seems to be tamed. I speak about the horrible component I've had the honour to work on the last months. I made ugly patches to the code base to reduce the worst memory and performance problems.

In parallel I managed to convince upper management that we need a new design which includes a real database as the backbone (the actual concept tries to mimic a SQL database and fails miserably). And I got green light !!! I really thought this would be harder but the pain caused by this component seems to be so pervasive that any new intelligent proposal is welcomed. But the new design will only work for the projects to come, the running project is nearly finished and I cross all my fingers that the fixes will hold the thing together.

Lessons learned:

• Don't let lone freelancers implement core functionality without controlling reviews. They sometimes vanish faster than you can see.


• Don't be fooled by the perfect process. The process can't check memory and performance requirements


• Take a look at your design and ask yourself: is the design simple or are there too many abstractions

Sometimes you have to face the beast !

Two months ago I inherited a major component of our system which is really badly designed. The previous coders just mourned about the fact that the original programmer (freelancer) had left behind such a complex beast and no one wanted to touch it.

The problem could have been fixed last year by doing a dedicated refactoring (or rewrite) but nothing happened. The beast just slept during the year, the unit tests passed fine. But now its ugly smells come through: bad performance, horrible memory-usage, code which covers its awfulness in a stampede of design patterns.

What strategy can be applied now ?

• Throw everything away and start from scratch. This would have been possible last year at the same time but now it's too late. The project is nearly at its end, with lots of years coming for maintenance.


• Ignore the problems. Well, it seems to work sometimes: just refuse to fix it (or make it better) by just doing nothing or claiming that nothing can be done. Perhaps some other poor soul comes around and takes the crap.


• Try to fix it in specific areas and especially carefully. This is hard and you really must be sure if you can do it. At the time you say that something can be done, it's yours. The other ones will nod and show pity but finally leave you alone.

I've chosen the last option although I'm not happy with it. There may be times when I will regret my decision but I think that I will have a better chance to completely get rid of it when I'm the only one who knows its internals :-)

Read this II

Ok, ok, I'm still learning how to use w.bloggar, now here are the links

The Pragmatic Programmer
Joel on Software
The Career Programmer

Read this !

Yesterday I listened to two of my colleagues who are actively "designing" our internal development processes. The one said "have you read DeMarco's 'The Deadline' ? Great book". The other one responded. "Oh yes, certainly, I recently finished 'Waltzing with Bears'. Great stuff". The conversation went on and on with exchanging project management book titles.

I've also read both but wasn't really that impressed because most of the advices sound great theoretically but reality often strikes badly. One of these colleagues worked the whole last year on a component in our system which is obviously over-engineered (more about that in later posts). He was so busy to stay to the process ("this is the design which you all voted for, now live with it" or "you can't have that feature, it isn't on the list of the original requirements") and the project really went from green to red as the component really munches memory like Godzilla (which is quite crucial in the embedded world).

Now I'm the one who is trying to cope with the beast. And I think: DeMarco's advices don't help here ! You must go way back to the bytes and carefully fix the design flaws with a very tight schedule.

So I really wanted to shout at them "Read this instead !" and you will get good project managers:

Read this !

Yesterday I listened to two of my colleagues who are actively "designing" our internal development processes. The one said "have you read DeMarco's 'The Deadline' ? Great book". The other one responded. "Oh yes, certainly, I recently finished 'Waltzing with Bears'. Great stuff". The conversation went on and on with exchanging project management book titles.

I've also read both but wasn't really that impressed because most of the advices sound great theoretically but reality often strikes badly. One of these colleagues worked the whole last year on a component in our system which is obviously over-engineered (more about that in later posts). He was so busy to stay to the process ("this is the design which you all voted for, now live with it" or "you can't have that feature, it isn't on the list of the original requirements") and the project really went from green to red as the component really munches memory like Godzilla (which is quite crucial in the embedded world).

Now I'm the one who is trying to cope with the beast. And I think: DeMarco's advices don't help here ! You must go way back to the bytes and carefully fix the design flaws with a very tight schedule.

So I really wanted to shout at them "Read this instead !" and you will get good project managers:

Test of w.bloggar

This is just a small test for w.bloggar. Seems like a great program which makes blogging much easier. Now on to publishing :-)

Log-Launch

Reading is easy, writing is heavy ... nevertheless I have decided to launch my own web-log to write down random thoughts, strange stories and so on.

The posts will probably be heavily IT oriented as this is my profession. But I hope I can get my brain working in other areas than bits and bytes :-)