A round-up of my GOTO Aarhus experience

Let's pretend for a moment that it is not nearly two weeks since I got back from GOTO Aarhus, and thus this blogpost really should have been written at least a week ago. Let's instead say that I've let my thoughts mature, before writing this blogpost.

No, the truth is that I've been busy both at work and in my private life, so I haven't really had the time to sit down before now, and put my thoughts into a blogpost.

So, what can I say about this years GOTO Aarhus conference? Well, first of all, it was awesome. Great speakers, great people. Just generally great. GOTO Aarhus is definitely still one of my favorite conferences, and they manage to get some amazingly inspiring people to come and talk. Among the speakers at GOTO Aarhus I'd definitely recommend other people to listen to, if they have the chance, are Jez Humble, Dan North, Linda Rising, Michael Nygard, Scott Hanselman, and Martin Fowler. Each of them are not only very knowledgable, but are also great at speaking.

Overall, the tracks were well thought out, and it seemed like there had been some thought given to who was invited (though I think the conference could have benefitted from a bit more focus on diversity, if possible). One thing I did find problematic though, was that the level of the talks were a bit too diverse, even within the same conference track - some were obviously aimed at beginners while others were aimed at more trained people.

That is actually one major criticism I have of the conference: They were not very good at indicating the level of the talk. Often you went to something which seemed interesting, and found out that the level was too basic for you to get anything out of it. This is something that the organizers should aim at improving.

Another point where the conference might be improved would be the agile track. The speakers there were generally great, and the subjects interesting, yet I couldn't help feeling that they were generally covering ground that had been convered many times before. Maybe it is time for an advanced agile track for those of us who have worked with agile for a while? I can't imagine that I am the only one who feels this way.

This was actually something they aimed at with the dev-ops track, and it seemed to me that this was a good approach.

So, what was the highlights for me?

The absolute highly must have been Dirk Duellmann's keynote about Distributed Data and Storage Management for the Large Hadron Collider. It was a facinating insight into problems the rest of us never faces (who else have to take the moon's orbit or the amount of rainfall into account when analyzing data? huge, huge amounts of data).

Other than that, a few other things stood out:

• The Ada Aarhus meeting, where Linda Rising gave a great talk, and Martin Fowler argued that quotas might be the only way to get more women into IT (he finds quotas problematic, but empirical evidence points towards them being the only options).
• Talking with the vendors. A lot of people going to conferences don't speak with vendors, and they are really cheating themselves.
• Listening to Dave Thomas explaining something about the problems he work with to Jim Webber.
• Catching up with friends and former colleagues and meeting new people.
• The noSQL panel, where bloated claims by noSQL vendors were talked about. Panels can be either dead boring or brilliant. Any panel which have both Jim Webber and Martin Fowler on it, is bound to be the latter.

As can probably be gleamed, I had a great time, and I am definitely looking forward to going there again. Still, as I said, I would love for better markings of the levels of the talks, and also for there to be an advanced agile track.

Sexism in IT, again

I'm currently at the GOTO conference in Aarhus, where I am spending a lovely time going to some great talks and meeting some great people, and I had planned on spending the evening blogging a bit about my impressions from the first couple of days at the conference.

Had.

That was until I had lunch with a couple of other people, and I heard about this incident (opens in a new window). Please go there and read the post.

As people who have been around me since I heard about this will attest, I've been pretty damn furious ever since first hearing about it, and then reading Cerian's blogpost (which was posted shortly after I heard about the episode).

I don't think I really have to explain why this incident makes me furious, but for good measure I will try to do so.

First of all, it is an incredible rude way to behave, and even if there were no other considerations, I think that unwarranted rudeness against complete strangers at a conference shouldn't happen.

But of course, it is not just the rudeness - it is the sexism that really gets me angry.

Can anyone even for a second imagine that a guy would have been addressed in that way? Yes, I am sure that there a few men who have been accused of being hired because of their looks, but it is not something people would say about a complete stranger that they had never met before, much less to that complete stranger. I mean, WTF? How can anyone think that it is OK?

Unfortunately, for women, this is a common remark, though not usually said directly to their face (though it happens all too frequently as well).

And it is not just men who makes this sort of remarks.

When we had a meetup of the bloggers/web media people before going to GOTO Aarhus, there was a woman among us who expressed her opinion that among the women studying Computer Science, there were two types:
1) The pretty ones, who got their (male) group members to do the work, and thus, couldn't code.
2) The non-pretty ones, who had to do their own work, and thus, could code.

In her mind, it was obviously not possible to be conventionally pretty, and be able to code.

I could now make some kind of argument about knowing pretty female programmers, but that would just be feeding the sexism. Rather, I'll just say that I cannot fathom why anyone would think it is acceptable to make that sort of comments, yet here there was a woman publicly stating these things. Among people she didn't know.

We seriously have a long way to go. A very long way.

Now, back to the incident. The thing that made me furious about the incident was not the fact that it happened (though that should be enough), but the fact that nobody spoke up when it happened. This is not mentioned in the blogpost about the incident, but I asked Cerian about it, and there wasn't. Or rather, one person said to her that she should ignore it, but nobody said anything to the guy about it.

The GOTO conference has an incredible good track record when it comes to not only getting female speakers, but also getting female attendees (once having to go to court for the right to give a discount to women in order to make the gender less underrepresented - a court battle they won). Yet, even at such a conference, not only does a guy feel entitled to make this sort of remarks, but nobody spoke out against him.

That shows me that the whole culture is still sexist at its core. Not that I think that the people who was there with Cerian are particularly sexist, or even that they agree with the guy, but I do think that they can't see how this sort of remarks are not only incredible hurtful towards Cerian, but also helps create an atmosphere where women, or a sub-group of women, don't feel welcome.

We, the IT sector as a whole, need to change that. Not only because it robs the sector of so much potential talent, but also because it is the decent thing to do.

So, if you see this sort of thing happening, speak up, and make clear that you don't find that sort of stuff acceptable. This is the only way to change the environment, and get rid of the sexism. We need to stop implicitly accepting this behavior by keeping quite, and instead explicitly express our disdain of it.

And it is important to note that it is extra important that we men are very active in doing this, showing our support in changing the environment.

On those words, I think I only have left to thank Cerian for speaking up, and that I hope that there will be some kind of official reaction from the GOTO conference. I know for sure that I will be following up on this issue, so expect more blogposts dealing with sexism, GOTO, and IT in general.

My schedule at GOTO

It is no secret that I love to go to conferences in general because it expands my horizonts and for the social aspects. However, in order to get the maximum enjoyment and value out of a conference, it is important that I go to the right sessions - both in the sense that I don't want to miss the good ones, and in the sense that I certainly want to avoid the bad ones.

I have been busy the last couple of weeks, so I haven't really had time to look at the GOTO schedule to see what sessions I want to go to. Still, looking at the program, I can see that there are certain sessions I don't want to miss, and certain sessions that I definitely want to miss.

So, how do I pick what sessions to go to?

Well, there are certain criterias:

• Who is the speaker?
• What is the subject?
• Is the session technology specific?

The first point should speak for itself. There are certain speakers I don't want to miss. People like Linda Rising, Dan North, Michael Nygard (all of whom have sessions at GOTO), Uncle Bob, and Kevlin Henney. This is the most important criteria for me, since I know going into their sessions that I will be challenged and get my horizonts broadened.

The subject of the session is of course also important. The subjects that interest me, are the ones with broader perspectives, rather than those focusing on narrow issues or technologies. Good examples of the sort of sessions I prefer are the ones in the Agile Perspectives, Continuous Delivery, Professional Productivity, or Humans at Work tracks.

And then there is the aspect of how technology specific the talk is. This is a criteria for choosing to not attend. In general I find that technology specific talks are a waste of time, unless they address a problem I am currently facing. And even when they address a current problem I am facing, I find that a bit of google searching will work just as well for me, and allow me to spend my time on a session which gives me more in the long run.

It should probably be mentioned that I am not very visual. Which means I prefer that people either tell me something, or hand me something I can read. This means that pictures, diagrams etc. are wasted on me, as are coding examples and demonstrations. Really, they are. When people start showing how to code something or other, I am bored to tears, and frequently have to fight the urge to fall asleep.

Since technology specific talks often contains loads of demonstrations, this might help explain why I usually find them a waste of time. Still, even if that wasn't the case, I think technology specific sessions are a clear case of wasted opportunity. How often have you come out of a tech specific session and brought something with you, which you can use even just two years later?

This doesn't mean that talks with code examples can't be good. At QCon London, Kevlin Henney gave a keynote talk on cool code (different version of the talk can be seen here), where he showed loads of code. That talk was brilliant, and I highly recommend watching the video linked above, even though it is a less energic version of the talk. It also provided great food for thought.

So, to sum it all up, I haven't really taken a deep look at the schedule for GOTO, but the tracks I have linked above will probably be where I spend most of my time, since they are the ones that provide most value in my opinion. One exception will be the time I spend at Dan North's HTML5 talk. It might be technology specific, but since it is Dan North talking, I know that I will be learning some new perspectives from it which I can use in the future.

Why go to conferences?

If people know me, it is no great secret that I am a great fan of going to conferences. Within the last year, I've been to several (GOTO Aarhus 2011, QCon London, QCon New York, and Community Day), and as I wrote in my last post, I'm going to GOTO again this year.

So, why do I love conferences so much?

Well, there are many aspects, but a lot of it boils down to two simple reasons:

• Expanding horizons
• Networking

Or to expand a bit more on it:

Expanding horizons: When working on projects on a daily basis, one tend to get bogged down on the problems there, and loose the greater overview. Going to conferences not only expands your knowledge, but also gives you new mental tools and frameworks to approach problems.

Heck, some times, the talks make you realize that you have been looking at the wrong problems all along.

Conferences are also great sources for inspiration towards improving yourself. E.g. at last years GOTO, Kevlin Henney gave a keynote talk on Cool Code which fired up just about everybody who listened to it (a video of a less energic version of the talk, which he gave at GeeCON can be seen here).

And of course, conferences help you keep track of tendencies and cool new technologies.

Networking: I am a quite social person (to put it mildly), and at conferences I get the chance to meet a lot of interesting people. The speakers are of course interesting to talk to, but the other participants are also frequently very interesting - the sort of people who wants to go to conferences are often opinionated and have interesting thoughts on many subjects.

So, if you go to conferences, remember to participate in the social events. Also, try to strike up a conversation with strangers, and see where that takes you. You'll often be positively surprised.

Going to the GOTO Aarhus conference

It turns out that I will be going to the GOTO conference in Aarhus this year in my capacity as a blogger. The kind people arranging the GOTO conference have invited me and some other bloggers to come along, and blog about the conference. I obviously thought this was a great idea, and thankfully my employers at NineConsult thought it was a great idea as well.

Since I am a great believer in full disclosure, I thought I'd better be upfront about this potential bias.

This will be the 3rd time I'm going to the GOTO conference - or rather, the second, as I've been once to GOTO and once to JAOO, which was the old name for the conference.

I can easily say that GOTO is my favorite conference - it has the right mix of talks about methods, technologies, frameworks, and broader developer-related subjects for it to appeal to me. It also has the advantage of not being wed to one specific technology - neither in talks nor in vendors. Another great thing about GOTO, is that the speakers are immensely approachable (to be fair, the same was the case at QCon London).

My blogging from the conference will probably be focused on two things:

1) Diversity,  or rather, how we get more diversity in our field, at our conferences etc. GOTO has been great in trying to increase the diversity both among speakers and among participants, and many of the people helping with GOTO are involved in great groups such as Ada Århus, which is a networking group for women in IT in Århus.
Those posts will probably be crossposted at my other blog, since this is a subject I discuss alot on that blog.

2) The talks. If there are some great or thought-provoking talks, I'll be sure to write about them. I've noticed that there is usually some kind of theme going through the talks (e.g. in QCon London in March, it was the concept of knowing your tradeoffs when making decisions), and I'll certainly make sure to write about any such at GOTO.
If any of the talks relate to error-driven development or how to end it, I'll of course also write something.

Reversed roles

Note: I should probably point out that in the following piece, I will follow the Danish tendency to not use peoples’ titles. For people not living in Denmark, this might seem disrespectful, and if it is perceived as such, I apologize, but the habit of not doing so is too ingrained in me, for me to start doing so now.

I was considering calling this piece “through the looking glass”, but that would have connotations of weirdness which I found inappropriate, since what I wanted to was to indicate that I had experienced the “other side” of the divide for once.

What divide you ask?

The gender divide. The gender divide in technology to be more specific.

People who have followed my other blog and twitter stream are probably aware that I am an out-and-open feminist, and that I regularly criticize my field (programming and IT consulting) for how women are marginalized, e.g. by the male dominance when speakers are picked for conferences.

This year I participated in such a conference; the GOTO conference in Aarhus, Denmark (the conference was formerly known as JAOO). Here the lineup of speakers was also heavily tilting towards men, but it is one of the conferences which actively tries to get female speakers, and they had managed to get some really great ones, including Linda Rising, Rebecca Parsons, and Telle Whitney.

Telle Whitney held a talk on women in IT, and all three of them participated in a meeting with the Ada Aarhus group, which was held after the talks on the second day of the conference.

I went to the talk, and participated in the Ada Aarhus meeting, and both of these things introduced me to the concept of being the outsider. Something which I understood, or at least thought I did, yet which I hadn’t really experienced before. I cant say I enjoyed the experience, but it was certainly enlightening, and it forced me to re-evaluate what I thought I understood on this subject.

Before going into how this happened, I want to back away a bit, and give a brief introduction to myself and that part of my background which is relevant.

First of all, as the sidebar says, I am a Danish IT consultant in my thirties. For those interested in the details, I am a .NET consultant, working mostly with large financial or public systems.

What the sidebar doesn’t mention, but which many people know, is that while I am Danish, I am also Australian. My mother was Australian, and while I grew up in Denmark, my childhood was a mixture of cultures - not only Danish and Australian, but also several others, since my childhood friends were also mostly of mixed backgrounds as well (though all with Western backgrounds).

This upbringing has left me unable to entirely relate to a typical Danish upbringing.

It is the small things that usually trips me up - the children's’ stories and songs that I haven’t heard, and the ones that I grew up with instead (would you believe that most Danish children don’t grow up with neither The Wizard of Oz nor Snugglepot and Cuddlepie?) - but it is also the inability of many to look beyond the borders, and think globally. The distrust of foreign things and multi-culturalism that people hold, thinking that anything foreign must be dangerous or less good.

This means that I am the outsider in some cases. But given that fact that I’ve grown up in Denmark not entirely so, and since I look Danish, I can always act in ways which allows me to fit in.

Going back to the woman in IT talk, Whitney talked about what companies and individuals could do to ensure women could advance in IT. A subject I feel strongly about. Yet when listening to the talk, I kept feeling that I was left out - that Whitney wasn’t talking neither to nor about me. The reason was that I am not in a position to make company decisions, and that the individuals that Whitney was talking to, about what they could do, was the women. Not the men. All the recommendations didn’t relate to me and daily life.

You know why? Because it wasn’t about me!

I knew this at an intellectual level. Yet I hadn’t realized the full impact until I experienced being left out. It bothered me more than I thought it would. My privilege kicked in, and I felt a bit of resentment at the gut level, while knowing fully well that this was how it ought to be, at the intellectual level.

If this was how I felt during a 50 minute talk, how must it not be for people who experience it day in and day out? E.g. women whose wishes and needs are ignored or LGBT people who live in a heteronormative society.

I cannot in any way pretend that I can relate to how they feel. But I can say that I understand it a little better now.

The Asa Aarhus group meeting, where both Linda Rising and Rebecca Parsons gave brilliant talks, just strengthening my understanding of this, and my realization of how little I can relate to how it would feel to experience this every day.

Hotfix Hell

I am a firm believer in many agile processes and tools, including iterative development, where you work with many deliveries. This allows for early, frequent feedback, and allows you to find errors early, before the project turns into an error-driven development project.

Unfortunately, this is not always possible.

A type of project I often work at, is the large project which spans several years, where the customer involvement is minimal, except at the start and at the end. This sort of project is pretty much doomed to go over time, go over cost, have many errors etc. They are exactly the reason why agile development has become so popular. Even if the project is developed agile, the lack of customer involvement, will mean that the project could in the wrong direction, without anyone finding out, before at the end.

Typical projects where this happens, are public projects subject to tenders. Here the scope of the functionality etc. is determined before the contractors bid on the contract (though often with a clarification phase at the start), and after the bid has been accepted (plus initial clarification phase has passed), the scope, deadline, and price are fixed. The customer will then often not be involved until the final acceptance test phase, where the solution is often found to be lacking (to put it mildly).

As this approach has obvious flaws, there has been an attempt to fix it by introducing sub-deliveries, which each has to pass the acceptance tests. In my experience, there are typically two sub-deliveries before the final delivery at the end.

This approach might seem somewhat agile, and since it gives earlier feedback, you’d think that it would help. Unfortunately, in my experience, it actually worsens the problem.

The problem is in the acceptance test part.

Picture the typical two year project with three deliveries (two sub deliveries and one final). Given the fact that there is a lot of scaffolding etc. at the start, the first sub delivery will fall after one year, with a sub delivery half a year later, and the final deliver half a year after the second sub delivery (i.e. one year after the first sub delivery).

This is, in itself, not an unreasonable schedule.

Unfortunately, the programmers involved will often have to acquire domain knowledge, while doing the scaffolding and early development of functionality, increasing the likelihood of wrong decisions and/or errors in the implementation. Some of this will become apparent as the first deadline approaches, and might be changed in time - unfortunately some it won’t be possible to change it all, and some misunderstandings will only become clear during the acceptance testing.

Since the project is on a tight schedule, the work on sub delivery two starts - often starting by changing the flaws found before the deadline, which they didn’t have time to fix, but also start on new functionality etc.

Unfortunately, the errors will still be in the code submitted to the acceptance test.

Since the errors are found, the acceptance test fails, and the customer rejects the sub delivery as it stands.

What happens then? Well, this is where the hotfix hell starts.

Given the fact that the code submitted as sub delivery one has failed the acceptance test, the developers have to fix the errors in the submitted code, which is now out of date, compared to the code base. This is done by making a patch or hotfix to the code.

The patched/hotfixed code is then re-submitted to acceptance testing.

If this passes, then all is well. Unfortunately that’s rarely the case. Instead, new errors will be found (perhaps introduced by the fix), which will need to be fixed, re-submitted, tested etc. This will take up considerable amounts of time, calender wise, but also resource wise - meaning that programmers, testers, customer testers etc. will use a lot of time fixing problems in the code, which they could have spent on other things. Other things, such as sub delivery two.

Just because sub delivery one has failed the acceptance test, doesn’t mean that work on sub delivery two has stopped - it is, after all, to be delivered six months down the line.

Unfortunately the plan didn’t take into account the hours need to work on sub delivery one after the delivery and/or date for expected acceptance test. This means that sub delivery two is in problems, since the developers won’t have time to do all the work required for it to pass acceptance test.

Meanwhile, sub delivery one and sub delivery two move more and more apart, resulting in developers having to fix problems in obsolete code - this is frustrating for the programmers, and introduces the risk of errors only being fixed in the old delivery instead of being fixed in both, since porting the fixes is difficult.

At some stage, the sub delivery will pass the acceptance test, or (more commonly in my experience) it will be dropped, as the next delivery either is about to be delivered or has been delivered.

Due to the work on the sub delivery one, the second sub delivery is unfortunately either late or in such a mess that it cannot pass acceptance test (or, more likely, both).

This means that when sub delivery two is handed in, hotfix hell starts all over again.

So, how can this be fixed?

Well, one way is to do iterations the agile way. Unfortunately, that’s not particularly likely to happen.

Another way is to base deliveries on the date when the acceptance test of the earlier sub delivery has passed. So in the above example, the second delivery will be handed in six months after the first delivery has passed the acceptance test.
Given the nature of the projects using sub deliveries, this is also unlikely to happen. Often the last deadline is defined by a new law or regulation, and is firm (until it becomes completely apparent that it cannot be done).

A more likely solution would be to take the overhead to hotfixes into account when planning. This would mean that the time spent on hotfixes on sub delivery one wouldn't take time set aside to sub delivery two. The problem with this approach would be that this would make the price higher when bidding, since more people would be needed to finish the work on time, than if one assumes that not hotfixes are necessary. On top of that, it is also hard to estimate just how much time is needed for this (in my experience, everybody vastly underestimates this).

My suggestion would be something more simple. Timebox the acceptance test - and call it something else.

Before the project starts, the customer and the contractor decide how much time will be used for testing the sub delivery in order to make sure that the fundamentals are fine, but without resulting in the developers having to fix obsolete problems.

When the timebox is done, the customer will either accept or reject - a rejection would mean that the customer think the code is so fundamentally flawed that it cannot be used. If that’s the case, the customer and the contractor will need to sit down together and figure out how to get on from there. Perhaps the final deadline will have to be moved, the contractor will have to add more people to the project in order to get it back on track, or the customer will have to become more involved in the development process (e.g. by providing people who can help testing during the development of sub delivery two).

I am well aware that my suggestion breaks with the concept of sub deliveries, but I would claim that the concept of sub deliveries is fundamentally flawed, and instead of helping a problem, it actually makes it worse. Since this is the case, I think we have to re-think how they are used, if at all.

Michael Nygard interview in InfoQ

I haven't abandoned this blog, and am working on the next post in the series on ending error-driven development, but unfortunately I have some problems committing my ideas to a blog post, so until then I'll point people to a great InfoQ interview with Michael Nygard, author of Release It!. It takes half an hour, and in my opinion, it is well worth spent the time watching it (but then, I am a fan of Nygard, and have been so ever since seeing him at JAOO last year).

Michael Nygard on Building Resilient Systems

If people aren't aware of it, Michael Nygard is a track host on this year's JAOO

Seeing is believing

Some times it really pays off to verify things with your own eyes.

I am a big proponent of automatic testing, and think that people should use it as much as possible, but I'm also aware of the limitations of automatic testing, and I've come across a great example of why fully automation is not enough.

Currently I'm working on an application which is very much reliant on stored procedures, and to ensure that these works as they are expected, we've added a lot of integration tests, where we run the code executing the stored procedures, and ensures that the data are as expected afterward.

One of these test was quite simple - it took the user id and a user role, and updated the user role of the given user identified with the user id.

The automatic tests we made ran as the should, executed successfully, and the role of the user was successfully updated. Or so it seemed. Unfortunately there was one minor thing we hadn't thought of, and it had to do with the nature of the application code, calling the stored procedures.

Given the limited options for user roles, they are implemented as an enumeration in the code. In C#, an enumeration (enum for short) is a set of numbers with an associated value (e.g. 1 - "Administrator"), so if you set the value of the enum to 1, it can be translated (with the ToString() method) into "Administrator".

As I said earlier, the stored procedure took two parameters - an user id and an user role. In the code calling the stored procedure, we did pass these two parameters along, but we forgot to "translate" the role from the integer to the actual human readable value. This meant that in the example given above, we would pass the value 1 down to the database, rather than the value "Administrator".

This was not detected since the code could correctly understand the value when it was fetched again, and thus it appeared that the database value was correct. Unfortunately this wasn't the case, since the association between the integer value and the text only exists in the code, and not in the database.

The only reason this error was found, before it caused problems elsewhere, was because I was looking at the database data directly in the database for other reasons. Had I not done so, this error would most likely not be found until other systems started using the database as well.

So, today's lesson is: while automatic testing is definitely important, it's also important to verify the results with your own eyes once in a while.

Ending error-driven development, part 4 - setting the team

My last post was focused on problems which might exist in a team, and what measures which can be done to avoid, or at least compensate, for these problems. This post focuses on the roles which should be filled in a team which has problems, and has turned into the error-driven development phase.

As always, these are my opinions and my opinions only. I’d love to get feedback, and hear what roles other people find necessary or unnecessary.

I am not claiming that the roles that I mention are always necessary for a project to succeed, or even that they are necessary when in an EDD project. They are, however, roles that I find will help the project along the way towards becoming a better project.

The roles are not necessarily full-time jobs, and a person could fulfill several roles at the same time, as long as that person has the right skill-set for each of those roles.

So, apart from a project manager, software architects and developers, what roles do I think should be part of a team’s setup?

• QA manager


• Configuration manager


• Deployment manager


• Defect manager


• Test manager


• Release manager


• End user representative

QA Manager

Let’s be honest, when a project is under a great deal of pressure, and has been so for a while, the developers start cutting corners. This is the only way they can remain any hope of making it on time.

This means that it’s necessary to have someone who is responsible for the code quality, and who have the jurisdiction to enforce coding standards.
Depending on how bad shape the code is, this can either be a small task among other tasks, or it can be a full-time job. If there is a lot of legacy code, the QA manager will have a hard time getting the code up to par, even if the legacy code is ignored. It’s a sad fact that code which is being written for a crappy code base will most likely also be crappy – it’s the “broken window syndrome”. Why bother with writing clear, beautiful code, when it’s going to be part of a messy, unclear code base?

The QA manager needs to be respected by the other developers, and must be able to help mentoring less experience developers on how to solve problems in the correct way.

Configuration manager

We probably all know this situation. The tests have gone well, everything seems to work, but when it’s deployed out to the production environment, the system suddenly fails, and no one knows why. After some frantic work, it’s found out that one of the settings in the configuration was wrong – it might have been overwritten by a test setting, it might not have been deployed, or there might be something else wrong. Whatever the reason, it’s a situation which should be avoided at all costs.

This is where the configuration manager comes in. That’s the person responsible for ensuring that the configurations are correct and the right version on all systems. Every time a change is made to the configurations, the configuration manager should be involved.

Deployment manager

Deploying systems is a hard, thankless task, and most developers don’t want to do it. The deployment manager is responsible for the deployment of the system, ensuring that all the correct information is filled out, that the people who need to know that the deployment is happening get to hear it, and that the deployment went well. In case the deployment didn’t go well, the deployment manager is responsible for finding out what went wrong, and to fix the problems.

If you get the right deployment manager, he or she will try to ensure that the deployment procedure gets automated, so he or she will have fewer things to worry about in the deployment phase.

A deployment manager is not the same as a release manager (see below), as the deployment manager is focused on the entire system, while the release manager should only focus on the parts of the system affected by that specific release. This means that while the deployment manager should ensure that each and every subsystem is running after a deployment, the deployment manager is not responsible for smoke testing the system – that’s up to the release and test managers.

Defect manager

When you are in an EDD project you will get a large number of reported defects (called defects for short), and it’s a quite good idea to have a single point of entry for those defects. The purpose for this is to ensure that the developers don’t get disturbed by defect reports all the time, and to make it easier to weed the defects for duplicates and hidden change requests (a future post will go into these differences).

The defect manager should also be the single point of contact, regarding defects, for people outside the team. This means that if a tester has a question regarding some behavior which might be a defect, the tester should talk with the defect manager.

The defect manager should have clear guidelines from the project leader about how the defect should be prioritized, both in relation to each other, but also in relation to other tasks, such as new development.
My rule of thumb would be that critical defects (e.g. parts of the system doesn’t work), should be have highest priority, but otherwise defects should be solved when someone is working on the general area they are connected to. Of course, in the case of defects found in new functionality for the release, they should always be fixed straight away.

Test manager

Given my heavy focus on testing (see my earlier post on the subject), I guess it should not come as a surprise that I feel that there should be a person dedicated to coordinating the tests.

The test manager is responsible for ensuring that all relevant tests are run every time a new release is on the way, that tests are modified as required, and that new tests are added as new requirements appear.

A good test manager should focus on automating as much of the test process as possible (but not so much that the test quality suffer), and ensuring that everything is tested sufficiently. The test manager should also always be on the lookout for new tools and techniques for testing.

Release manager

A release manager is the person responsible for a particular release, keeping track on everything related to that specific release.

During deployment it might be hard to tell the differences between a deployment manager and a release manager, but there are some key differences. A deployment manager is responsible for ensuring that the deployment process goes as it should, while the release manager is responsible for ensuring that the correct things are deployed for that particular release, and that that particular release works as it should after deployment. In other words, the release manager is responsible for making the package which should be deployed, while the deployment manager ensures that the package is actually deployed.

End user representative

If at all possible, there should be at least one representative from the end users in the team. This person should be available to answer any questions the other team members might have regarding the domain the system should work in.

Sometimes a requirement seems ambiguous to a developer, while being quite clear to someone who knows the domain better. If there isn’t an end user representative available, the developer will often end up guessing how the requirement should be understood, and design and implement based on that guess – often resulting in a wrong design/implementation – or the developer will have to waste time finding someone who correctly understand the requirement and pass the information on to the developer.

Having an end user representative on-site, will allow the developer to quickly get feedback on how to understand the requirement, reducing the development time and/or number of wrong design decisions and implementations.

How should the work be divided between the roles?

There is a certain amount of overlap between what can be considered the area of responsibility of the different roles, so I thought I should try to explain how I see the divide.

• Defects should be handled by the defect manager, but the release managers should be aware of what defects are solved in their releases. The test manager gets to say whether a defect has been solved or not (do they pass the tests).


• Configuration managers should handle configuration of servers etc., but should work closely with the release managers to ensure that all configuration changes in the releases are taken care of. The configuration manager also needs to work with the deployment manager to ensure that configuration changes are deployed correctly.


• Release managers should work closely with the deployment manager to ensure that the releases are deployed correctly. By “correctly” I mean that they should not only make sure that the system is up and running afterwards (this is the deployment manager’s job), but ensure that it’s the correct releases which are up and running. The test manager should be the one responsible for testing that all the additions, modifications, and corrections are deployed, but the release manager is in charge of keeping track of what additions, modifications, and corrections are part of the deploy.

For a different way of explaining this, let’s go through the process:

1) A new release is defined, and a release manager is appointed. The release manager work together with the rest of the team to ensure that the release is finished on time.

2) The test manager starts ensuring that there are tests covering new functionality, and modifies any existing tests as warranted.

3) While developing the new release, the code is continuously committed, built and tested. The test manager ensures that all errors found during the testing are reported to the defect manager.

4) The defect manager prioritizes the errors, and make sure that they are added to the tasks for the release if relevant. When doing this, the defect manager ensures that the release manager and QA manager are aware of the open defects.

5) Any fixed defect goes to the test manager, who either confirms the fix or reopens the defect as not solved.

6) The release manager informs the configuration manager of any changes to the configuration.

7) During the development of the new release, the QA manager will do general QA work, enforcing coding standards, do code reviews etc. If any area gets a large number of defects, this area will be in the QA manager’s focus.

8) After the release is done, passing the tests sufficiently, the release manager makes sure that all the relevant code is made into a deployment package, and hands this over to the deployment manager.

9) The deployment manager goes through the deployment steps, ensuring that the deployment goes well.

10) After the deployment has gone well, the configuration manager ensures that the configuration is correct.

11) The test manager tests that the deployed version corresponds with the release version [go through steps 8 through 11 as many times as necessary until it’s right]

12) Finally, the release manager signs off the release, filling out whatever papers are necessary, informing the necessary people about the release etc. [this might be handled by the project leader together with the release manager]

Note that there frequently will be several test environments which the deployment should go through, but the release manager is only responsible for the first deployment, while the rest presumably can be handled by the deployment manager alone.