Ever-decreasing cycles

This article was originally published in VSJ, which is now part of Developer Fusion.
Anyone who’s ever stubbed their big toe whilst fumbling around in the dark late at night will know the importance of feedback. Each blind step forward we take can bring us dangerously close to horrendous pain.

There was a time when programming was very much like that, too. You don’t have to cast your mind that far back to recall a time when programs were painstakingly typed into a text editor, and then – once completed – that program’s source code was submitted to a compiler on some underpowered and overworked central computer somewhere to turn it into executable machine code.

I remember as recently as 1995 watching COBOL programmers wait many minutes – and sometimes hours – to find out what the result of their compilation was. And almost inevitably, the result would be a list of errors that the programmer would have to fix before submitting the code again to the same lengthy process.

It should come as no surprise that getting even simple programs to work was expensive and time-consuming.

But the tools got better, and the compilers – and particularly the computers they ran on – got much, much faster. So much so that these days we’re used to getting feedback about programming errors – at least, syntactical ones – literally as we type in the source code.

Background compilation is a familiar feature to the majority of developers these days. We take it for granted just like Word users take background spelling and grammar checking for granted. And getting that feedback in real time has had a profound effect on our productivity. Those squiggly lines point to problems as soon as they appear, and fixing them is an immediate and inexpensive doddle.

By reducing the length of the compilation feedback cycle from minutes or hours to seconds and milliseconds, developers are able to spend much more of their time thinking about what their programs should be doing, and far less time fiddling about with syntactical minutiae.

Of course, getting our code to compile is just the beginning. It may be well-formed and syntactically correct, but will it work? Will the code do what we want it to do? Background compilation can’t answer that question, alas.

Many developers these days get feedback about the semantic correctness of their code (i.e., does it do what it’s supposed to?) by creating automated functional tests. This is another important feedback loop that has been shrinking in recent years, thanks to practices like developer testing and Test-driven Development. Whereas I might once have waited days or weeks for a dedicated test team to tell me that the code I wrote doesn’t do what it’s supposed to, I can now get a decent level of assurance by running a suite of automated tests and getting feedback in a few minutes.

Again, by detecting bugs much sooner, the cost and hassle of fixing them is massively reduced, and productivity tends to go up.

But it doesn’t end there. As computers get ever more powerful, it’s becoming feasible to run these automated tests in the background as we write our source code.

Background unit testing frameworks are already beginning to appear, all be they a tad clunky and sluggish at the moment. But in 5–10 years’ time, I see no reason why we couldn’t run a suite of thousands of unit tests in seconds or even milliseconds, and present the results in real time inside the IDE just as we see now with compiler errors.

But even when we are routinely producing code that demonstrably works with minimal effort, there’s still the challenge of making it maintainable and easy and cheap to change. Code design quality issues, like complexity and crippling dependencies, creep up on us quickly and present us with major barriers to maintaining the value of our software in the medium-to-long term.

I’ve worked with several teams who’ve run code quality analysis tools as part of their automated build process, which highlights problems much sooner in development. Indeed, most other teams are blissfully unaware of the design quality of their code – though they always seem painfully aware of the symptoms of poor design quality!

This is another feedback cycle that is currently shrinking. Ten years ago, code analysis of any reasonable-sized piece of software (100K lines of code or more) took some serious number crunching. As with old compilers, we would submit our source code for analysis and wait sometimes hours for the feedback. So we didn’t do it too often, naturally, and the quality of our code reflected our reluctance.

Now tools like NDepend and FxCop can crunch through large software products in minutes, making it quite feasible to incorporate code analysis into a build script. As the analysis tools get faster, and as the computers they run on get faster still, I foresee real-time background code quality analysis – where little quality dials flicker literally as we write the code – in maybe another decade, possibly even sooner if we all put our minds to it.

These ever-decreasing cycles of feedback will, I hope, raise the game of the average software developer to the point where we routinely expect code to not only compile, but to work correctly and to be of a good internal design quality.

And, just as background compilation has freed us to focus our minds on higher things – like functionality and architecture – this continuous automated testing and QA will, I predict, free us up to focus on even higher ideals like user experience, enterprise architecture and delivering better business value. (OK. We’re allowed to dream, aren’t we?)

In the meantime, without the constant real-time prodding of some ultra-fast, super-advanced background compilation, testing and code analysis process, we’ll just have to get into some good habits, won’t we?

Jason Gorman is an independent consultant and rabble-rouser, based in London, with 16 years’ software development experience. His web site offers guidance and advice on OO software development, architecture and design, and Agile practices to over 30,000 visitors every month.

You might also like...



Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Better train people and risk they leave – than do nothing and risk they stay.” - Anonymous