Give your development project a heartbeat

Back in the early to mid-90's I did a fair bit of reading about Microsoft as they asserted their hold on the IT marketplace. One of the things that struck me was their use of daily builds to assert the condition of the software under construction and the mentality of always having software that was close to shipping quality. I loved the “don't break the build” mentality and started to introduce it into my projects.

What does a heartbeat involve? It's all about having your software compiled, tested and deployed in an automated way on a regular basis. This process is often referred to as 'the build'. Ten years ago, doing this once a day was considered good practice. Nowadays we run a build every time someone checks in new or updated code. Having a comprehensive build process reduces risk and provides an easy way to see how things are progressing. It also builds momentum on the team as the number of consecutive clean builds adds up.

Many projects back in the 90's were divided into multiple development streams with no integration or compilation of the whole occurring until very late in the project. Progress was tracked via written status reports, not by the presence of software that was compiled, deployed and tested every day. Custom business applications were not viewed as products that needed to be 'ready to ship' every day. Introducing the concept of a build as the heartbeat of the project helped to bring consulting teams closer to their commercial software counterparts and to take more ownership in the team 'product'.

As a project leader I like being able to check the heartbeat every day. How many builds did we run? Did the last build pass? What areas of the code did we create or modify? Did we run tests on them? Did they all pass? Being able to answer these questions in minutes every day is invaluable and lets me spend more time on the project challenges and less time on trying to figure out where we are at.

A regular heartbeat/build can also be a way to develop comraderie and have some fun on the team. Developers can sometimes cause the build/heartbeat to fail by checking in some untested code or getting sloppy in some other way. We typically have some sort of fun 'prize' linked to breaking the build and stopping the project heartbeat. This can range from a 'toque of shame' to a really big embarrassing sign that hangs over their desk. They typically have to own this until someone else breaks the build. On strong teams the stakes are high since you may wait for weeks or months for someone else to goof up and let you pass along the prize. The serious side to this is that a broken build is an 'all hands on deck' situation – we don't move on until the build has been fixed and the project heartbeat started again.

In the past several years it has become even easier to give your project a heartbeat. Tools like CruiseControl, Ant and XUnit have become defacto standards in software development and blur the traditional lines between different technologies such as Java and .NET. These tools tie together well and make it easy to automate complex build processes.

What are we doing on my current project? It's a .NET project so we use NAnt to automate the build script, NUnit for automated unit testing, Subversion for source code control and CruiseControl.NET to tie it all together and handle execution and reporting for the automated builds. We're still working a lot of issues on the business side of the project but it's nice to know the 'project heartbeat' is already going strong.

Are you working on a software development project without a heartbeat? Does your project have heartbeat but nobody is listening or monitoring it? It may be time to bring your project to life with a heartbeat that everyone listens to.

Project teams, evolution and genetic manipulation

It seems like we're always looking for decent analogies in IT. One that has occurred to me is that building evolving IT project teams is similar to evolution supported by genetic manipulation.

I work in a project-based IT services organization. Our ability to repeat success from one project to the next depends, among other things, on how well our organization can assemble effective project teams. The nature of the project, the client, and our team members change from one project to another, but we benefit from having teams that are improving upon their predecessors in an evolutionary way.

No two project teams are alike, nor should they be. The exact nature of an individual team is a function of its members strengths and weaknesses, the nature of the project (objectives/goals, constraints) and the client environment. Once created, teams evolve independently to either succeed or fail. The teams that succeed are often used to 'seed' later teams in the hopes of replicating success. The teams that fail are often disbanded to help populate other teams.

The genetic material, or DNA, of a strong team is a function of the individuals on the team. On a strong, effective team the individuals help to get the best out of each other, overcome negative traits, and reinforce the positive ones. In that sense, a strong team evolves rapidly into something that is increasingly more effective. The converse of this is that a weak team does not evolve to highlight the strengths of its members. Through this rapid evolution a strong team can become an order of magnitude more effective than a weak or mediocre team.

Once you have a strong evolving team you'll likely want to either start another team, or even improve an existing but less effective team. To do this we often 'transplant' some of the genetic material from the strong team with the desired traits into the new or existing team – a form of genetic manipulation, if you will. If done properly the recipient team will begin to exhibit some of the desired traits of the original team. As this team evolves the 'donated' traits will merge with the inherent strengths of the receiving team to create a more effective entity.

We don't always have the luxury of putting an 'ideal' team together – one in which all the individual members have a strong background in both the business domain and the target technologies. Sometimes, only a single member will have the desired experience. Despite this, we need teams that build upon our accumulated knowledge of similar projects.

Natural selection (i.e. Darwinian evolution) is also a big factor in the evolution of teams. The DNA of successful teams will be propagated out into other teams in multiple ways. Firstly, the successful team will not be disbanded or killed off before it reaches its prime. Secondly, the organization will want to transplant the characteristics of the successful team into other team – often by transplanting individual members to other teams in the hope of transplanting the desired team characteristics.

OK, so perhaps it's not a perfect analogy, but consider evolution and genetics if your organization needs to create successive IT project teams that are improving upon prior results in an evolutionary way. I know I am.

What is an IT heretic?

What is a heretic? Here's one definition:

Someone whose opinions, beliefs, or theories in any field are considered by others in that field to be extremely unconventional or unorthodox.

Here's another one:

Someone who holds or adheres to an opinion or belief that contradicts established teaching, especially one that is officially condemned by authorities.

OK, so heretic has been a pretty strong word down through the ages (think burnings at the stake) and I've never actually been called a heretic at work. I have often felt like one, however, when I've had and promoted views on IT that are considered unconventional or contradictory to established teaching.

So what is an IT heretic? Let's say it's someone who is willing to take an unorthodox position or use an unorthodox approach with the goal of producing some positive change or innovation. This last point (“producing some positive change or innovation”) is important – it's not enough to take a contrary position for it's own sake, you have to deliver results. There are lots of cowboys out there who just want to be different for the sake of being different. A true IT heretic embraces things outside the mainstream to affect change in the mainstream itself.

To do this you have to be willing to stand up for your beliefs in the face of criticism from the IT mainstream, have confidence in your reasoning, and trust your instincts. IT often suffers from a herd mentality. Things are often done a certain way because “that's the way it's always been done” or “that's what most IT shops are doing”. Being an IT heretic is about not following the herd. It's about trusting your own judgment about whether or not the herd is going in the right direction and acting accordingly.

IT is a very immature industry by historical standards. By this, I mean that IT professionals have a lot less historical context to draw on than, say, a carpenter or a farmer. Despite that, it does seem to be an industry that wants to be very set in it's ways. The low level technology is changing quickly, but the attitudes and approaches are often resistant to change. This, in turn, impedes the rate at which we properly harness or exploit new technologies.

We need to solve this with attitudes and approaches that embrace change. We need more IT heretics.