Posts Tagged ‘software development’

Good-bye broken builds

March 15, 2009

The smart folks at JetBrains just made our lives a lot easier. TeamCity 4.0 has an extra verification stage that ensures any changes actually work BEFORE allowing those changes to be commited to the repository.

Most continuous integration servers today (CC.NET) rely on teams to commit their changes to version control first, and then kicking off an automated build. And as long as the team members do an update and build locally before checking in, things are usually fine.

Being the humans we are however, builds still periodically break.


TeamCity 4.0 apparently fixes that.

Now, instead of monitoring the repository for updates and then doing a build, TeamCity does then builds first, and then commits the changes to version control only if the build succeeds.


This way, the build is always up and running, and if there is a problem, it never makes it into the repository.

JetBrains refers to this as a delayed commit and I think it is a fine refinement on the continuous integration process.

For more information on this and other features (like distributed builds), check out the TeamCity 4.0 web site.


How to become a better programmer

January 5, 2009

ride of into sunset

Life as a software consultant is pretty good. You come into a company, build an application or two, and once the project is over you climb back up onto your horse and ride off into the sunset.

* You aren’t asked to hang around.
* You don’t have to worry about any pesky bugs or support issues.
* You get to work on new greenfield projects.
* You often work with the companies best and brightest.

It’s great fun and life is pretty good.

It wasn’t until I stopped being a consultant however, and starting building and maintaining my own applications, that I realized I was missing out on a big opportunity for learning.

What you miss

When you build something, and then don’t stick around to maintain it, you are only watching half the movie. You don’t get to see how it ends.

* You miss out seeing where you got the design right – and where you got it wrong.

* You miss out on seeing which areas you tested well – and those not so well.

* You don’t get to see which features your customers love – and which ones they hate.

You basically miss out on all the great feedback that would tell you where you kicked butt, and where you screwed up. All of which would of course help you on your next project.

And that’s a shame.

So for those of you building apps and thinking about moving on – slow down.

See how the movie ends.

Your future customers will benefit from your broadened experience, and you will be stronger for it.

There is no spoon

November 4, 2008
there is no spoon

there is no spoon

Occasionally I am asked by IT managers to prove, with numbers, that agile engineering techniques like Test Driven Development (TDD) work.

Unfortunately that’s not possible. Academics have been trying unsuccessfully for years, and while I respect their efforts, I would be skeptical of any results proving or disproving that agile methods like TDD work.

The reason I would be skeptical, is because it’s not possible to apply the scientific method to things like TDD.

I remember being taught in grade 7 science, that when doing a scientific experiment you:

  1. Create a hypothesis
  2. TDD is better than non-TDD

  3. You pick a manipulating variable
  4. to TDD or not TDD

  5. You conduct the experiment
  6. Measure the result against your hypothesis.

This type of experiment can’t be done on software projects because the variables can’t be kept constant on both sides.

How many projects have you been on where you have:

  • the same team
  • with the same requirements
  • where you build something the same way
  • and you don’t leverage any learning’s or mistakes made from your previous experience

Dealing with questions like proving TDD works can be frustrating. One one hand you believe it works, yet on the other you can’t prove it (at least the way some managers would like you to).

So stop trying.

Accept that you will not be able to answer the question the way they would like it answered.

Instead, try looking at the question a different way.

Why they are asking the question in the first place?

Is the customer unhappy?
Did the last push to production not go smoothly?
Are projects costing more and taking longer to deliver?
Is there a concern teams are spending too much time testing?
How are we defining success?

You can’t discount the managers question. It’s a good one, and they very well be onto something in asking it.

Just understand that you can’t always answer every question the way the questioner would like. Especially when it comes to quantifying knowledge work like software development.