Pols Consulting

No one thought it was a bad idea to run acceptance tests on the live system.

What could possibly go wrong? Everyone knew that orders for “Mr Test Test” and “123 Test St were not real orders!

That is, everyone except the marketing department.

I though it was worth sharing some experience we are having speeding up our very slow build from 1 hour plus to around 10 minutes.

In the past we have spent a lot of time exploring why our tests are slow and have never really come up with a good solution. We’re continually extending the test suite, so any savings we make don’t last that long.

The unit tests are quick (~40 seconds), but it’s the acceptance tests that start up and run the application that are painfully slow.

We decided to group the acceptance tests into small logically grouped test suites that can run in 10 minutes or less. Then we added build agents (each running on a separate machine), so we can run as many of these small test suites in parallel as we can.

Every time the build gets too slow we break them down into smaller chunks and add another build agent. Hardware is cheap so it’s easy to sale this solution.

So far this is working really well.

Mike Hill and I are running a session at XPDay 7 on the subject of how Agile software development teams should collaborate and work with their customers.

When an agile team works with their customer, how do we ensure we speak the same language? How do we incorporate the business domain concepts into our code? How do we know we’ve got it right?

In this workshop we will explore how people approach these problems, what you’ve tried and how it worked out. We hope to reflect on our collective experiences and learn how we can improve.

It’s a great conference. Hope you see you there.

I know that journalists use pseudonyms on facebook to research a community,  but the BBC is reporting that busy people are paying someone to represent themselves online as they need a presence, but don’t have the time.

I met somebody the other day who told me that online networking was so important, and he didn’t have the time, he was paying somebody to be him online. To blog, network, post etc . £1,000 a month too.

“This guy is a busy entrepreneur and he says that wherever he goes, people marvel at the energy he still manages to put into blogging and networking – and he then tells them it is all being done by a guy he pays to do it.”

I feel an off shoring opportunity coming on!

Steve Freeman had an interesting post in which he wondered if there was a tendency for geeks to be B-people?

Well, I hate going to bed and hate getting up in the morning. So it must be true! It could also explain why there is so much bad software in the city (they tend to start really early in the morning!)

I have just discovered an old post by Jim Shore (http://www.jamesshore.com/Blog/How-I-Use-Fit.html) about how he started out using FIT. He started out by switching from a unit test driven approach to a more story driven development approach.

I encountered a big problem with this approach, though: I stopped doing good TDD. “Storytest-driven development” blurred the line between Fit and unit tests. The “STDD” cycle largely replaced the TDD cycle and, as a result, I had far fewer unit tests than normal.

That was a problem because Fit examples are not unit tests. Fit examples are just that: examples of a business rule in action, from a business perspective. In TDD, I write tests for every line of code that can possibly break. In my Fit examples, I try to talk about every possible business case. That’s a bigger net than TDD, and without TDD, my code wasn’t well tested.

I had the exact same experience. I also found that the design suffered due to the lack of tests (it did not force me to refactor as often as I should) and it had a detrimental impact on my productivity. Story tests are larger in scope and take longer to run. Unit tests provide a much faster feedback loop when you break something.

I wish I had read this before I started using FIT.

As a follow up to my post on pair programming based interviews, I noticed this on a recent job advert:

In chess it is possible to place eight queens on a board so that no one queen can be taken by any other. Write a program to determine all such possible arrangements for all eight. I am not looking for a Chess Games Developer. I am looking for Java Developers who have the OOA and OOD skills to solve this problem….

Which one would you prefer (to receive if going for an interview, or to use to find a good candidate to work in your team)? A test that’s abstract and has nothing to do with the work involved, or one that that involves doing the job you are interviewing for?

I wonder if they have run this test on all of their existing staff to see if their is any useful correlation.

I noticed an interesting discussion on the IXP mailing list about pair programming with developers during an interview. I was surprised by the number of people who thought it was a bad idea.

I have done a lot interviewing for various companies and one of the best ways to find out the beliefs and values of a software developer is to look at their code. The best way to know what someone is like to work with is to work with them! This is why I really like pair programming interviews. It’s one of the best interview techniques I know.

Another nice feature of a pair-programming interview is the continual conversation you have with the candidate. It provides you with ample opportunities to ask sensible questions about the code you are writing. This gives the candidate a better understanding of why you are asking the question. There’s nothing worse than crazy interview questions that make no sense!

There are certain things you have to be aware of. You have to be very good at putting people at ease. You need to explain why you are running the interview like this. Some people get very nervous at an interview. You have to treat it as if you are pairing with a colleague. If people get stuck, you should help them out.

An interview is a two way process . The candidate also gets a much more realistic idea of what it would be like being in the team. They see what it’s like working with the team and experience the development environment first hand.

I’ve been wanting to update the site for some time now. At long last I have managed to migrate everying to wordpress and hack out a new theme along the way!

Please let me know if there are any problems on your browser.