2012-10-18

The development process.
This is something that can help or annoy the team, and most of the times those who created don't even realize it.

Last month I just met some team with a very interesting process.
They have only 1 tester, all the tests are automated.
Everyone is responsible for their bugs.

So far, so good, no problems but nothing new.
Now we have the interesting part:

The build process.
VMs are generated with a script downloading the latest code from Team Foundation Server.
This is the same script that creates the test environment L1 and L2, and production.

Why did I put that emphasis to the "and production"?
Simply because everyone is always too scared to mess with the production server, and this is the source of so many problems.

Just to compare, in the same company, I saw another team's server. But this one had around 10 different folders with different versions, and the production published folder was called staging.
There was a folder called prod, but this one wasn't being used.

Now the thing is: why did they let this mess?
Simple, no one wanted to be responsible for taking the server down, so the pile of crap just grows as more people touch it. And I have to confess, I wasn't exception... I just published my files in the weird named folder and left everything as it was.

Back to the story, the development / testing database is also reset every night (copied from production). Because of that, the developers have to make a script for loading the data when the tests takes more than one day.
Once the bug is fixed it in their environment, a routine runs to destroy the test environment, and recreate it with the updated code.
Once they receive the green light from the tester (and this is something that made me impressed, THE tester. That's right, just one for a big team of developers), the code is marked as good to go.

Then, around once a week, this code is published to the production server. the production server has its vm destroyed, and recreated using the latest approved code from the version control. This rolls so smooth that I was there during a new publish, and most of the team didn't even know that it was happening. they just do a quick test when it's done to make sure everything is ok.

This makes them more responsible for their code, but the problem about giving someone too much responsibility and not enough time is that things are not going to be as good as they could be.

Yes, the time, this is the downside, and it isn't a small amount of time. Their development cycle is quite slow, and any unforeseen task can take weeks or months to be developed. They have a fast lane of small tasks, but this only works for some features.
They have no problem with that, for this team it is more valuable to have less bugs than more features, but this is not always the reality, in fact what happens in most companies is exactly the opposite.

The golden rule for development is: you can have Time, Cost or Quality. pick TWO, and only two.
And by cost I mean getting more developers to give smaller proportion of work for each.

That being said, if you can afford to spend more time in order to get more quality, congratulations, you are already half way to a good product. Now it is time to pick a development methodology, and I really think this guys are using a pretty good one.

I feel this would have made my life so much easier in a few projects in the past.