“Iteration means the act of repeating a process usually with the aim of approaching a desired goal or target or result.” (wikipedia)
In programming when someone talks about iteration they usually mean the time it takes to get from making a change to their code, to seeing the effect of that change. At least, that’s how I’ve always thought about it.
For years I’ve been doing most of my development in C++ using Visual Studio. The code base I’ve been working with has been in development for over a decade and contains a few million lines of code. As you can imagine, making a change can be a time consuming business – a full recompile can take anywhere from 10 to 30 minutes (depending what mood Windows is in) and even a one line change is probably going to be 30 seconds by the time the build system has checked all it’s dependencies and linked everything.
Then of course there’s the application start up times. Our application is relatively lightweight compared to some I’ve seen but realistically it’s at least another 20-30 seconds from hitting Run to actually being able to test the feature you’re working on, often a lot more. We build our application as many separate DLLs but we’ve never got to a point where they could be unloaded and reloaded on demand to allow recompilation without a full application restart. Similarly we’ve dabbled with the Edit and Continue feature in Visual Studio but found it to be singularly unreliable on large applications. Often it’ll sit there for minutes before informing you that, sorry, you need to rebuild anyway.
So for years I have cursed the length of our iteration time. Every now and then I get to work on a smaller application which builds and runs in seconds and I imagine how life could be without all that baggage.
Well, luckily for me over the last year and a bit that’s started to happen. What began as an attempt to improve our application by letting users script it through Python has led to a revolution in the way I think about tools development. It turns out that scripting the tools isn’t just for end users, it’s for developers too. A lot of ‘non-core’ functionality is really much easier to write in a high level language like Python, and much faster. Being able to make a code change and see the result pretty much instantly means iteration times are dramatically reduced. And the worries about performance and memory usage have so far come to nothing (touch wood!).
But (there had to be a but, didn’t there) life is never without it’s challenges. Take away the compilation time and the application start-up time and you start to notice the other parts of the ‘iteration’ that you’d never noticed before. In fact for me there was one big one… debugging.
I’d never really thought of debugging as part of the iteration cycle. I knew that I spent a fair chunk of my day doing it but, unlike watching a compilation progress bar, it’s a very interactive and brain taxing process. It’s not like I’m ever sat there watching the debugger and waiting for my turn. But in the shift from C++ to Python I became acutely aware of debugging. Not only did it take up a larger percentage of my time due to the reduced compilation times, it also took longer because I wasn’t familiar with the tools.
I’d got very used to Visual Studio, which has some pretty slick debugging features, and when I went to Python I was suddenly using print statements to debug things again – it was like returning to the dark ages. I wasn’t very familiar with the features or syntax of the language either so debugging took me longer.
Actually ‘longer’ wasn’t the only problem. I’d got hung up on iteration times and forgotten about the other important factor in the iteration-time * number-of-iterations = time-to-solution equation. Did you spot it? Of course you did, it’s the number of iterations. Debugging with print statements, in a language I didn’t know well meant I was making more iterations to find problems that I could have solved in one hit had I been debugging C++ code in Visual Studio. On reflection that seems obvious, but then what doesn’t?
I’m happy to say I’ve become a lot more confident in Python now and we’ve discovered some much better debugging tools than the humble print (Aptana Studio for the win!) so both my iteration times and number of iterations have dropped dramatically. I can go for days sometimes without recompiling our C++ code-base, or even restarting the application, and when I do it feels like walking through treacle…. yuk!
Since getting stuck into Python, I’ve also started to dabble in Javascript, CSS and HTML (more about that in another post), all of which bring their own syntax and debugging tools into the mix. So what did I learn from the first experience that helped me?
- Spend time learning the technologies you’re dealing with. There’s only so much you can learn without getting stuck in, because ‘getting stuck in’ is often the best form of learning. But make sure you’ve got books and bookmarks on hand for when you do run into something new.
- Spend time researching the tools available to you. In many ways this is both more important and more tricky that the first point. Reference books for languages are pretty comprehensive and if you’ve programmed in one language you usually know roughly what you’re trying to achieve in another. Debugging tools aren’t like that – the variety and quality of reference material is patchy at best, as are the tools themselves, and of course there’s the cost issue to watch out for.
- Analyse your iterations, find the bottlenecks, and work out what you can do to remove or mitigate them.
- C++ is lame ;P
And my replica:
