Archive for the ‘Story’ Category

The project manager was obviously a little irritated. “By this stage of the pre-study, we really should have the requirements a little more nailed down than this. That’s two new requirements since last week. Or what does everyone think?” he looks around the table, expecting support. The business representative looks disappointed and hangs his head.

Without really thinking, I follow my instinct and jump in. “It seems wrong to me to say to the customer that he can’t have any more features at this stage. Perhaps he should be prepared to drop something else instead, but surely we should be prepared to respond to the needs of the business? We are still in the pre-study, after all”

The project manager was not impressed. “This pre-study has already been going on for nearly 2 months, we really need to put together a budget and project plan so we can pass the next tollgate and proceed to the implementation phase.” He looked around the table sternly, then his frown softened a little. “Well ok, you can have these two new requirements. Let’s take a look at them”

A few days later, the project manager called me into his office.
– “You can’t go telling the customer he’s allowed to change his mind. After that meeting he came to me with more requirements. Your comments confused him as to how our software development process works. Please don’t do it again”.
– “But I though we were trying to be agile in this project? You know, short release cycles, end of iteration demos, like in Scrum”.
– “Yes, we are following a process which is more agile than the standard company mandated process. We have got permission to skip two of the tollgates, and 5% extra in the budget for ‘adjustments’ so we can respond to the customer feedback we get at each demo. We are not doing Scrum though. Who told you that?”

Sigh. I heard “agile”. What I should have heard was “more agile than the standard company process”.

Michelle the manager has two small children. She regularly puts in a 45 hour week. Alan the project manager also has two small children. He officially works 80%. The first architect, Steve, has one small child. He officially works 90%. The second architect, Flo, has two small children. She officially works 100%. Also on the project team are a number of developers, testers and other experts.

The project isn’t doing so well, and when there are about 6 weeks left until the delivery deadline, Alan the project manager starts coming in on Fridays – the day he usually spends at home with his children. Luckily his wife’s mother lives just round the corner, and since she is retired there is no problem with childcare.

A short time later, he starts to make impassioned speeches to the project team about how important it is to make the deadline, and presents a strong case that overtime is needed. He asks everyone has to email him with their availability over the coming two weekends.

Michelle already works weekends semi-regularly. Her husband is in a business that is suffering from the recession, so he is only working 75% anyway, so there is no problem with childcare. She is available.

Steve is hardworking and ambitious, and his wife is happy to spend more time looking after their child. Steve is available.

One of the developers, Paul, has one small child, but his wife’s mother is also keen to help, so childcare is not a problem. He is available.

None of the other developers have children. No problem with their availability then.

The thing is, Flo does have a problem. She has no extended family within reach who could be called in at such short notice. Her husband is already at home on paternity leave 100% and is finding it tough. He doesn’t want to take up the slack, and she doesn’t want to spend any less time with her children than she does already. After some thought, Flo tells Alan she is not available.

So what happens? Everyone works extra, except Flo. Alan is frustrated because he feels he can’t give her any important tasks to work on, because he knows she won’t stay late to finish them. Then Flo requests to work 80% in the new year, so she can spend more time with her children. (By Swedish law, all parents with young children who have a full time job have the right to reduce their hours.) Alan is not pleased, and talks to his boss about the situation. The project must go out on time, and he feels Flo’s behaviour is endangering this. The upshot is that Flo is told her contract will not be renewed.

The official reason given is that “working 80% is not compatible with the rate of productivity we require of an architect at this workplace”. The secondary reason given is the unwillingness to work overtime. As a contractor and not an employee, Flo has no recourse, the law doesn’t apply, and she is left searching for a new contract to work on.

It turns out that even in enlightened, feminist Sweden (1), even when the boss in question himself has small children and normally works 80%, even when the other architect in the team officially work less than 100%, it is still the case that a mother working the hours specified in her contract, is not able to keep her position.

If this is what it is like in Sweden, God help working women in the rest of the world.

(1) Just as an example how the feminist culture affects the political agenda: The main opposition party, (who polls indicate will win power at the next election), wants to quota parental leave so that each parent will be forced to take half of time available. This must be the only nation in the world that expects fathers to stay home from work for 8 months with each of their children.

What is the quality of this codebase on a scale of 0 – 100? Zero means “perfectly designed, clean code” and 100 means “total spaghetti, impossble to make changes”.

Without hesitation, Andreas answered. “70”.

Andreas was standing at the whiteboard, sketching a timeline and drawing boxes labelled with the names of the parts of the system and the people involved. His task was to give a history lesson to the latest batch of newly arrived programmers. How did we get here?

It seems that way back in about 2001 when Andreas and the rest of the team of hotshot young programmers began building this system, it was pretty good. In six weeks ten programmers had achieved more than 100 consultants from had achieved in 3 months. That code was ditched shortly afterwards and Andreas’ team code is still at the heart of the system today.

It seems that for several years things went pretty well, Andreas’ team grew slowly and the system gradually took on more and more functionality. Their focus was on working closely with the business and delivering value quickly. The team was so successful that it started pulling back work from the firm’s outsourcing partners, since they were so demonstrably better at delivering valuable functionality quickly.

Unfortunately the programming team is not so productive now. Over the last few years more and more people have been added, a fourfold increase in fact. Many of the original team have either left or disappeared on protracted parental leave. The quality of the codebase has deteriorated as developers unfamiliar with it have implemented new functionality at cross purposes to the original intent. It’s not that they are bad programmers, but rather without guidance from more experienced people it is very hard to introduce new functionality cleanly without breaking anything. The almost total absence of automated tests doesn’t help either. Programmer productivity is dropping steadily.

There are various initiatives to improve the situation. For example, Andreas’ training courses for new programmers. Also, several experienced programmers are working on refactoring projects. (Without the aid of tests). The question is whether this is too little, too late. Rumour has it that the size of the codebase has increased 25% in the past 6 months. Emergency patch releases are now routinely scheduled after every major release. Obvious bugs have are present in the production system that no-one seems to know how to fix.

So the question I really want Andreas to answer is not the absolute quality of the codebase, but whether the quality is increasing or decreasing. Unfortunately, he couldn’t tell. I fear the worst.

My cousin held out the keys to his flashy looking sportscar and said “Do me a favour. If you crash into something with my car and it’s nearly written off, but not quite. Please back up then hit it again, harder, until it really is written off”. I laughed nervously. “yeh, sure. Of course”. Needless to say I returned his car in perfect condition a few hours later.

The architect grinned as he reviewed my design proposal. “Don’t worry about making the code beautiful, just make your changes work without causing extra test cyles. In fact, ugly changes are better. The sooner this code becomes legacy, the sooner we can rewrite it” I laughed nervously. “Sure, of course” He handed back my uml diagram and I went back to my computer to write some code. Beautiful code. Carefully.

Let me tell you a story about a young developer called “Sue”.

Sue has just learnt all about eXtreme Programming. She has worked on an XP team with lots of pair programming, unit testing, refactoring, simple design etc and is totally converted. The world should be doing XP!

Sue hears about another application at her company which is in trouble. Let’s call the application “Squirrel”. Squirrel has been in production for a few years now, the codebase is rather large and the internal design is somewhat confused. The Squirrel team is having increasing difficulty adding the features the customer wants in a timely manner. Sue is convinced what they need to do is to refactor the codebase and add lots of automated tests.

Sue manages to persuade her manager “Paul” to let her work on refactoring Squirrel. She gets a copy of the code out of the version control system and sets about writing unit tests and refactoring. A few weeks go by and Sue reports to Paul that everything is going really well. She has solved some significant technical challenges in order to put in place some unit tests and has a small suite that she runs regularly. She proudly shows Paul the test scores and some UML diagrams of how the code looked before her refactoring, and after. Paul is pleased at how much better the UML looks and when Sue asks for more time to improve the code further, he grants her request.

A few more weeks pass and Sue is starting to attempt quite ambitious refactorings. She really feels the Squirrel team is going to be delighted when they see how much better their code looks and how many tests it has.

Meanwhile the Squirrel team has been continuing to add features and fix bugs and are actually quite proud of the progress they have made with the small team available to them. The users of the Squirrel application have complimented them on how much more stable and usable the application is becoming.

After a few months, Sue, Paul and the Squirel team agree that the next release of Squirrel should include Sue’s refactorings. The approach chosen is for the Squirrel team to take Sue’s copy of the codebase, and integrate all the recent bug fixes and new features into it. Everyone thinks this will be straightforward using the advanced diff&merge tools provided with the version control system. Sue persuades Paul that this would be better than applying all of Sue’s refactorings to the Squirrel team’s version of the codebase, since she had made so many sweeping changes and her codebase had extensive unit tests.

It was a total disaster. Sue had introduced a huge number of bugs when refactoring. Sue didn’t understand what the code was really doing, having never actually worked on the application before and having only the documentation to go on. She had hardly spoken to the Squirrel team in all the months she had been working on their code, even though their project room was a short walk from her desk. The unit tests she had written covered only a fraction of the codebase and often reflected her poor understanding of what the code ought to be doing.

The diff between the two branches of the codebase was huge and the integration work was difficult, time consuming and error prone. After a week or so the work was stopped, Sue was in the doghouse, “Refactoring” was a dirty word, and the Squirrel team went back to their old codebase.

So what went wrong? Sue clearly did not have enough understanding of the codebase in question and was not skillful enough to pull off the refactorings she attempted. She had too much faith in the few unit tests she had written and lent on them too much. Sue didn’t think about the integration cost rising exponentially the longer she worked apart from the Squirrel team.

However, I think it is Paul who really carries the blame for what happened. As the manager responsible for both Sue and the Squirrel team, he should not have allowed Sue to continue working alone for weeks on end producing only UML diagrams and unit test reports. Paul should have anticipated the integration problems even if Sue didn’t. He should have asked to see working code – if he had sat down and manually tested Sue’s copy of Squirrel, he would have found serious bugs within minutes.

Well, thankfully Sue wasn’t sacked immediately and was given a chance to redeem herself. Sue joined the Squirrel team and started working on bug fixes and customer features. She quickly gained more understanding of the code than she had ever got working alone. Sue did put in place a few unit tests and do some refactoring, but it was always in the context of whatever bugfix or feature she was working on at the time. Most of the big sweeping refactorings that Sue thought would make a difference were never implemented.

The customer was happy for a while but the pace of new feature addition was still a bit slow for them. The customer also discovered that they could get a much better product from a competitor. So a couple of years later they dropped Squirrel. Happily for Sue, by then she had found a better job with a more competent manager.