Software development at less than 1 millihertz
Martin Cracauer recently described why he appreciates the fast turnaround time of short observe-orient-direct-act (OODA) loops in software development. I agree that faster feedback makes for better (or at the very least, more enjoyable) development, but what happens when you don’t have it?
I’ve run into this kind of thing a few times in my career. In the past I’ve worked on embedded systems where the development environment is separated from the execution environment and emulators are not available. On my current project, I have to deal with very slow turnaround time for various reasons that aren’t worth getting into. Suffice it to say that changing the environment to facilitate faster feedback would take significantly longer than just living with the existing delays.
As Martin’s post illustrates, distraction is the enemy in such situations. It takes discipline to stay focused and keep going with the task at hand. And the longer the period of inaction, the harder it is to stay focused. How can you fill this idle time with meaningful work?
The way I’ve been doing this recently is to subvert (read: hack) the usual build process and hypthesize a lot. It sounds weird, but it seems to be working for my team.
In my recent project I’m a little lucky in that it’s a porting effort. Another way to say this is that the system itself doesn’t actually work – we’re trying to make it work. So the common feedback loop of only adding working code doesn’t quite apply. For the most part we make a change and see if it got things further along.
We don’t do this blindly, of course. A faster feedback loop would be appreciated, but we don’t have it. So we kind of make it up. The build process is such that we can inject some changes at various points to avoid some of the slower parts of the build at the expense of having those changes actually be usable by the build process. In other words, we end up altering intermediate and binary files directly.
While this is going on, we throw out hypotheses as to what will work and discuss them in a group. (One might cheekily refer to this as actual “computer science”.) It helps us understand the system we’re porting better since it’s too big to understand and the time pressures to get it to run as soon as possible are too great. Navigating the code this way is rather enlightening. We even project it onto a screen and group debug/navigate when it seems apropos.
As I said, I’d prefer to have a faster build cycle but it’s not there, so I’ve had to make do with what I’ve got. I certainly won’t claim this kind of workflow to be “the way”, but it’s worked pretty well for us so far.