Investing in Automated Tests

I remember reading a while back about system administration professionals being fired because they clearly weren’t doing anything because there was nothing happening. It was a bit tongue in cheek, but the “no news is good news” philosophy applies to System Adminstration (and network security).
After watching and reading about the behaviour of non-test infected developers regarding testing, I’ve come to a similar conclusion. They view regression testing, automated testing and unit testing as “a waste of my time”. They don’t remember all the times it’s saved their asses, or the risk mitigation that goes along with knowing what and where something is broken. All they see is the “constant” investment required in running the tests, and keeping the tests up to date. Just like the organisations see the constant investment required in keeping the System Administrator sitting on their asses, drinking coffee and playing World of Warcraft.
The worst thing is the negative feedback cycles that occur. When non-test infected developers change code, they don’t care about the tests, so the tests break, and then it’s a hassle for somebody else to clean them up. These developers see the effort keeping the tests up to date, and as a result it reinforces the amount of time required to keep the tests working. Of course, if things were kept synchronised then this would all just be a trivial exercise.
I’ve worked on projects with and without good test suites. I’ve walked into projects that are too scared to change any code because they don’t know if things are going to break. I’ve seen corporations put newly compiled, untested code into production because “this change couldn’t affect anything else”, to have it not work, and to corrupt production data and other things best left unmentioned.
At the end of the day, I like to work with good test suites. I get to go home early, and not work weekends. That’s good enough reason for me.

Being wrong…

Darren has expressed my sentiments exactly. I’m a very passionate person, and I love learning new things, and I love telling people about the things I know. I need to work on my delivery at times because my enthusiasm is often mistaken for arrogance. But I can live with that, for the sheer enjoyment of doing the things I love, and letting people know how cool they are.
The most exciting experience is to get into a rip-roaring debate with somebody and both parties walk away having learnt something new. Actually, I take it back, it’s even better if you can get a room full of people doing this.
That’s why I put in my 43 things list, “Never stop learning”.

Goal alignment – steps to the right culture

Many people who have to suffer me on a daily basis (mostly at work) hear me harping on about “goal alignment”. I’m going to describe in this entry why I think goal alignment is very important, and how it influences the culture of an organisation.
Goal alignment is the strategic setting of reward and recognition processes to facilitate the community wide achievement of an objective.
This consists of a number of parts, the first being strategic. This is not a tactical process, this is a strategic process that requires a top down approach where appropriate objectives are communicated and at each level the goal alignment is structured to facilitate the objective at that particular level. Each level should be supporting the levels above and there should be a direct link of objectives between layers and it should be clear how the successful achievements lead toward the high level goals.
Reward and recognition processes are a key part of goal alignment. It involves understanding the stakeholders at each level and what motivates them. For many people this might be a KPI and linked to salary, to others this might be the opportunity to play with new technology. The reward and recognition process must be carefully selected so as not to demotivate others, but still provide the necessary guidance towards objectives.
Finally, the community is the group involved in the objective. This might be an entire organisation, a department or most importantly a project. However, many lower level groupings (project) are directly affected by higher level layers (department or company).
With the preamble out of the way, the question is “so what?”. I believe that the major cause of breakdowns of commitment and success in organisations is a lack of goal alignment. If the developers don’t have their goals aligned with the business outcomes that are expected from their project, then there is a very limited chance of success. Of course, some people might get lucky, and the reward for their project can be “have the time and resources to do good work”. It’s not all about money, it’s what motivates people and teams, and what is required at each level.
For example, I’ve seen reward and recognition schemes go horribly wrong because the goals aren’t aligned properly. Notable candidates are;
1. Rewarding people for doing extra hours. This leads to people slacking off during the day, just to work late at night and pad timesheets.
2. Rewarding people for completing their work. This leads to lack of project success as everybody only cares about finishing their stuff, regardless of the project.
Reward people for the behaviour you want. Align these with the strategic goals. Be careful you’re not rewarding people for the wrong thing and sending the wrong message to everybody else. You will get the behaviour you deserve, which may not be the behaviour you want.