Lately I’ve been receiving confirmation that the title I chose for my blog really is something that want to aspire to.

First, a talk with my colleague M. I wanted to know what the big deal with releases is. Since I keep hearing about release configuration and the company that I work at has hired a release manager it seems to be something very complicated. The manager of our IT departement tried to assure me that adding configuration management made their code testable. I failed to understand him but smiled and looked happy (it wasn’t a good moment for a discussion).

The answer M gave me was that it shouldn’t be a big deal. He then looked me in the eyes and added “And don’t let anyone tell you otherwise.”. It makes sense to me that if people make this huge deal about releasing code it turns into something scary and difficult. And there is a risk with that, it turns into something you would rather do as little as possible.

The conclusion, releasing code should be simple.

Another hint was a podcast from .NET Rocks that I listened to on my bike ride to Old Campus. The topic was James Kovacs on Convention over Configuration. The message was simple: by using conventions rather than configuration setting things up can be done in a much simpler manner. You don’t need to worry about the “plumbing” in the same way. Also it makes your systems easier to test since it is possible to test the convention and then be assured that it is working.

Here, implementing code should be simple.

As for me personally, I want to have the time for my 2 year old, roleplaying Star Wars, listening to podcasts, working out, sewing, etc, I don’t have the time or energy for complicated.

The perfect process

It is seems that everything is always about adapting.

There is no perfect process for software development, it is always up to the people to perform their best. With enough competence, it doesn’t matter which process you use, and without it, you won’t grasp the process.

Or is there an area in between where the process is helpful?

On an individual level perhaps, but for a group some will be above the process and some below.

So how do you raise the competence of the ones who need it and how do you keep the ones who “get it” from stumbling on the process?

Words of wisdom

On my Software Testing and Metrics course we had a guest lecture this week. It was a tester for Nasdaq OMX and he told us a little about how testing works in “real life”.

He started of by reminding us how the price tag on a defect rises dramatically with time and spent a  great deal of time on the fact that a lot of defect can be found in a matter of seconds or minutes.

A few techniques enabled this. The first he bought up was pair programing. Stimulating different sides of the brain in the two programmers, pair programming has (possibly) a positive effect on the correctness of the code. Both for small mistakes such as uninitialized variables and larger as design flaws. Of course, pair programming isn’t a simple technique, it requires a lot of factors to click for it to be as efficient as it is on paper.

A great deal of time was spent discussing Test Driven Design. He talked about a study done at Microsoft and IBM were two teams were given the same task and one worked TDD and the other didn’t. It turns out that the team using TDD worked 15-30% slower BUT after a time of use their code turned out to have 40-90% lessdefects. 90%! Amazing results.

Also something as simple as keeping the developers and the testers in the same room helped uncover defects in a quick way. Making it easy for testers to discuss the code with the developers meant that interpretations problems could be discovered and solved, making both the software and tests better.

And then he talked a lot about tools. How Continuous Integration could help you make sure that the code you checked in really worked and didn’t break anything else. How Static Analysis could give you warnings about possible defects. How code coverage helped you make sure that there isn’t any untested or dead code.

He finished the lecture by giving us a demo of how a test case at OMX could look like.  We looked at almost 2000 lines of test code for a single requirement…  Using this he stressed the importance of using code conventions and test case traceabilty. It was imperative that each test case contained a reference to the requirement tested.

I asked some questions about the size of their company. They had about 8 developers and 10 testers and were trying different project processes without finding one that suited them yet. They made sure that testers and developers worked on the same features.

Exciting stuff for a wannabe-tester. 🙂