Prisoners of Our Habits - Act One

I have been describing continuous integration for an embedded firmware project targeting a low-end microcontoller. Based on discussions I see a need for pointing out something about my view;

I do not mean that you need to apply continuous integration, unit tests running on both the host and target, etc. if you are writing a 200 LOC blinking LED application for 8-pin microcontroller for fun. This is a job for Solo-Virtuoso, and methods should be alike. The project I'm talking about, while targeting the low-end microcontrollers, will develop tens of thousands of lines of C source and will eventually be compiled into ten or so configurations for mass production. The configurations have some special areas where expertise is needed, like power management and wireless RF technology. This type of project cannot fit the Solo-Virtuoso category. Instead it requires a collaborative group of people - a job for an agile team and this team should adapt these practices.

Purely based on my biased participant observation, the trend of firmware projects is towards bigger and more complex so we are going to need these practices. The problem in firmware domain is that former electrical engineers (now programmers, or even worse, managers) are not willing to see this increase in complexity, but remain prisoners of their old habits. They are still in denial. My recent experiences manifest this very thing.

Prisoners of Our Habits. Act one. Programmer enters.

A colleague following our agile journey mentioned that based on his observations of daily Scrum meetings and collaboration we continuously run into problems caused by someone changing an interface and all of a sudden none of the configurations work. His obvious solution for this was; "there is a need for up-front designed interface contracts between modules". Problem solved, eh? We do not have full set of requirements, nor the freezed hardware architecture. For me iron-bound interface contracts seem pretty far fetched objective, but then again, it's just me. Still I would be amazed (but happily so) to find this wizard pulling out a comprehensive up-front architecture for us. Oh, and preferably delivered as a PowerPoint presentation I might add. If you happen to know this guy, ask him to drop me a line. I could use a good laugh.

I see these discussions about interfaces as a solution, not the symptom. It is good to see team members having courage to change things, to refactor when opportunity arises. These conflicts usually get solved easily after the daily Scrum at latest, so to me these are just short architecture meetings. In addition there is a huge difference compared to normal high ceremony architecture meeting: decisions get made and implemented immediately and feedback is available the next day. I have witnessed this working extremely well, and fast, even with programmers with junior skill level. This is just not the way it has been done traditionally.

Old habits die slowly.