CMMI training impressions

Today I've had the second day of a three day CMMI training. After a more general training about software process improvement last year this is a basic course helping to establish CMMI in a company. Currently we are not planning to do so, but we're discussing it and maybe we'll trying to achieve the levels 2 and then 3 in future. My first impressions are really good. CMMI contains lots of helpful and well organized process areas with useful goals and practices. And it is no bloated model that forces to use every part. In fact it emphasizes that there has to be a good business motivation for each activity. So an introduction can easily be tailored to the own needs.

Additionally the CMMI training has influences to the Tideland projects. Not that we'll introduce CMMI for our small team, but the TOT project will be extended, the existing RMS project will be integrated, and features supporting software development teams will be added. The feature set is inspired through my main job leading a software development team, experiences made during lots of projects, and last but not least this training. I'll create an outline in our wiki and inform you here.

OOP 2007 - Bad smells in agile processes

Jutta Eckstein refered about bad smells in agile processes as an indicator for a misinterpretation. The agile manifesto defines the base ideas for a flexible value-oriented software development. So XP, scrum, or the crystal methodologies don't have to be followed strict. It is more important to interpret the idea behind it right. So she mentioned different known bad smells and made recommendations how to avoid them. She has a real good style in presenting and you recognize here experience immediately. I'm practicing agile processes - as far as it has been possible in my jobs - since 2000 and her track has been really interesting fo me.

Parallels between basketball and software development

Yesterday we've been at the German major basketball league game of our EWE Baskets Oldenburg against the TBB Trier. It has been a very good match, Oldenburg has been on rank 10, Trier on rank 9, both fighting for a place in the playoffs. We won with 99 to 61 and are now on rank 9.

What makes this so interesting is the fact that Oldenburg started this season with an almost completely new team of the youngest players. So they've lost a lot of games in the beginning. But the coach - Don Beck - and his staff managed it to build a great new team, very committed and with a clear goal.

Thinking about it today I found that there are many paralles in leading a sports team and leading a team of software developers to success. You need to build a team, give them a clear vision and heading, improve their abilities with training, show them to choose the right way on their own, learn to live with setbacks, find new ways when the situation is changing, and don't lose the faith into the own possibilites over a long period. And there is is much more. So if one compares all those aspects he will find some similarities which he can adapt and use in his own projects. They are patterns.

So I'm now planning to browse my experience - and other information sources - and collect a set of process patterns here.

TDD helps developing the ODBMS

As our ODBMS approaches the beta status I've found the memory footprint on disk is still relative high. The reasons have been very simple:

• the object identifiers have been GUIDs, which are very long,
• the full qualified type have been stored with each instance and
• technical timestamps have been stored in a human readable format.

So the solutions seems realy simple: change that. *smile* And it has been done in just five net hours.

To do this I've decided to change the root name management into a common database control that additionally generates individual object identifiers and provides a registry for the persisted classes. It has to realize a storrage mechanism which should work like the stores. Everything has to be integrated into the transaction class, the analyzer, the file I/O utility, the base file I/O strategy, the entities and the value holder.

What has helped me to do these changes are the powerful Smalltalk development environment and the fact that I'm doing TDD.

The Smalltalk environment with the integrated refactoring browser helped to easily perform renamings, find senders and implementors, add almost similar new methods through editing an existing one and submit it with a new name (as an intermediate step without breaking implemented behaviour), starting the unit tests, switch direct into the debugger for failed tests and to change the code immediately in the debugger. Together with the very simple language and the missing overhead of static typing everything has been done very fluently.

As allready said above I'm doing TDD. Not the kind of writing tests first for each and everything. But with the time I devised a good feeling for a very practical approach of what to test. Those tests accompanied me and growed the whole development time of the Tideland SOS. Without them many design changes - like above - or refactorings would have been much harder.

Both together, Smalltalk and TDD, are a very strong pair.