Automation = Virtual Intelligence

Even in XP, a methodology misconceived as vastly lacking design, before rubber touches road and code takes form - a high level design is sought out. A tentative plan is formed, technologies, frameworks and high level designs are chosen. Also before we’ve even needed to steer the rubber, we seek the guidance of a build process. From the outset we seek out an automated means of running tests and deploying applications. From the outset we seek to construct a being with intelligence.

It’s an intelligence that is cultivated and harvested by developers of all levels. Increasingly, the community at large is developing sections of the brain, evolving its lobes from knowledge of build processes to holding ‘technical lead’ knowledge - those that traditionally oversee the design and, in days thankfully passing, performed design and code reviews.

This build intelligence evolution is realized in projects such as Macker and Joodi, or even JDepend (side-note: I had horrendous difficulty understanding it’s API). Technical leads, or the ‘voice of the design’, are increasingly capable of expressing their thoughts and guidelines in the build, evolving those lobes and being less satisfied in producing documentation outlining ‘design guidelines’ that are never read. This is all at the heart of what Brooks was referring to in The Mythical Man-Month by ‘technical conceptual integrity’.

So build intelligence has evolved from being able to ‘do stuff’, such as configure, compile and deploy, to ‘policing the code’ - an automated resource thats a capable code reviewer.

In case you didn’t know, I despise code reviews. I’ve two main reasons:

• They encourage exploration of solutions after rubber has touched road.
• They tend to be considered as a negative, critical experience that is to be avoided.

Agreed, for those with a continuous improvement mindset, these points are largely invalid, but unfortunately for the majority of the community, as unfortunate as it is, the points hold. Given code reviews are really about governing quality, in my world I’d address this concern via upfront design discussions and investing intelligence in your build.

The policing intelligence I mentioned earlier has evolved from tools such as Lint and Checkstyle, to a second generation, such as those I mentioned earlier. I see two challenges confronting the community in the evolution of the build:

• Builds are still somewhat after the fact. How can builds be intelligent enough to be useful while coding? An excellent example of this is using a tool like FindBugs while you code, as opposed to after.
• Builds are particularly useful for continuous integration purposes. Integration typically occurs after check-in - allowing developers to still commit cruft. How can build intelligence be built into versions control systems to prevent crufty check-ins?

Regarding the latter point, I’ve recently been considering using separate branches to quell drops in developer productivity due to crufty check-ins - one for raw-development and the other for successful integrations. Developers commit to the raw-development branch, possibly cruft, continuous integration tools run and if successful promote code to the integration branch. Developers only update from the integration branch.