Thoughts from a Thirsty Bear

A little while back I wrote an article describing how to do continuous integration . But I left out one important step that happens before any code even enters the CI pipeline. A step so important, so fundamental, so obvious  that you don’t realise it is there until it is missing. You must be able to build and test your software locally, on your developer machine. And by “test” I don’t just mean unit test level, but acceptance tests as well. I said it was obvious. But once in a while I do stumble across a project where this rule has been missed, and it leads to a world of unnecessary pain and discomfort for the team. So what happens when you cannot easily build and test anywhere apart from the pipeline? Without being able to run tests locally, the development team is effectively coding blind. They cannot know whether the code they are writing is correct. Depending on where the dysfunction is - compile, unit test or acceptance test stage - the code checked in may or may n

A wise man once said, " I've got a plan so cunning, you could put a tail on it and call it a weasel! ” Unfortunately in software it isn’t quite so easy. Simply renaming a broken process doesn’t really change the way a project is set up. Unfortunately a growing number of managers seem to believe they can turn their projects into lithe, agile weasels simply by wrapping pre-planned waterfall projects into iterations and calling it “agile". Projects like these tend to ring several alarm bells, such as: The entire project is estimated up front (usually taking up a huge amount of development team time) Stories are split by service, and not by end-to-end functionality (usually a sign that key design decisions have already been made without being validated by working code). Ie the now discredited smokestack development approach. So a team (or even separate teams!) might be developing the front end first. Then later develop one of the services the front end uses later.

By now we should all be aware of the "broken window effect", not least because there is now concrete evidence that it exists. As a reminder, the "broken window effect" is that subtle, damaging change in attitude that causes perfectly normal, law abiding, sane people to break social norms if they see others doing the same thing. People are more likely to litter an untidy, graffitied street than a clean one. They are more likely to damage a car that has already been damaged. And they are more likely to write badly structured code and cut corners in a codebase if there is evidence of others doing the same thing. But I think there is an insidious, darker side to this. Accepting broken windows for too long desensitises and deskills your team . What happens is this. The bad behaviours that happen due to being surrounded by the broken windows - broken builds, releasing untested code, mend-and-make-do workstations and so on - become the new social norms. People get used

There has been a bunch of stuff written about the “Broken Windows” effect - the way that even good people will begin to do bad things if everything else is bad around them. In areas that look badly maintained, people tend to drop more litter. Where people are obviously flouting the rules others are more likely to bend them themselves. And in software, when you are working on bad code you are more likely to write more bad code. I first stumbled across the idea in an interview with the Pragmatic Programmers , but the evidence given is fairly apocryphal. So I was pleased to find something more definite . And it does make for interesting reading. The effect is indeed real, and significant. The number of people breaking social norms when they see that others have done something similar more than doubles. It's the 'no-one will notice another little bit of mess' effect. The study quoted in the article reinforces the need to maintain a high level of hygiene in your software.

The Independent has recently published an article highlighting the state of the UK Government's IT projects . Let's just say that it's not a success story: ...the total cost of Labour's 10 most notorious IT failures is equivalent to more than half of the budget for Britain's schools last year. Parliament's spending watchdog has described the projects as "fundamentally flawed" and blamed ministers for "stupendous incompetence" in managing them. Think about it. That's £ 26 billion of taxpayers' money down the drain because of " fundamentally flawed " projects and " stupendous incompetence ". Putting this into context, university funding is being cut by a mere £449 million next year - so we are cutting investment in our future, while frittering away £26 billion on avoidable failures. Epic Fail . I have already suggested that these failures are likely to have been entirely avoidable . So have others . But there nee

Once again the UK Government has a failed IT project . Failed as in almost three times over budget (an approximate overspend of a whopping £456 million ), 3 years late (and still not delivered) and not satisfying fundamental requirements. The chairman of the committee commented, "There was not even a minimum level of competence in the planning and execution of this project." Ouch! So what went wrong? From the Public Accounts Committee report it appears that some of the key issues were: Underestimating technical complexity Underestimating the need to standardise ways of working to avoid excessive customisation Poor planning Poor financial monitoring Poor supplier management Too little control over changes Costs and progress were not monitored for 3 years ?! Sounds familiar? It does to me - it smells like a typical "throw the requirements over the wall and hope" waterfall failure pattern. But would a more agile, flexible approach helped us here? Continuous delivery o

There are times when the software industry makes me despair. Making an analogy with someone building a house, you wouldn't: Hire the cheapest cowboy builders you can to build your house. (" 'We build you house very cheap. £500', 'OK, you're the cheapest. It's a deal!' ") Hire skilled builders but force them to compromise by refusing to supply them with the resources they need (" Oh we can't let you use electricity. Or petrol - it's a fire risk. Or let you move that fence that is in the way. Or... "), restricting their working environment (" You can plaster that room, but you have to do it through the letterbox ") or by unreasonably restricting budget (" you can only buy the cheapest bricks "). Hire skilled builders but tell them how to do the job, despite not knowing anything about building (" Don't lay bricks like that. Stack them, don't overlap "). Also you wouldn't make the same mistake

Just spotted in a job ad for a lead developer: "You will be expected to implement a rigorous Agile Development process and work with the Technical Architect who will define the technologies and toolsets"

Via Simon Voice : wagile adj a cross between agile and waterfall process. The mess that's left if agile is only partially implemented without cultural change. See also: failure , compromised , doomed

Have you ever noticed how some teams do not have a "buzz"? That certain energy that differentiates a good team from a great team. Anyone who has worked for any length of time in software will almost certainly have experienced the lacklustre plod of a team in crisis. But there is a rarer but not unknown phenomenon created by the further collapse of teamwork and common sense. I call it the Black Hole Team. Here, all joie de vivre has been crushed out of the team. All hope of changing, evolving and improving working practices has been extinguished. Team members are simply coding zombies, attending work not out of pleasure or professional pride, but instead simply to churn out second rate code that gets them from 9 o'clock to 5. By this stage the team has become so dense (sic) that new team members have the life and energy actively sucked out of them until there is just the shell left. So just how does a team collapse to this level? The ways are many and varied, but common

How familiar does this sound? Your Friendly Neighbourhood Architect flies in, makes a lot of noise, craps all over the design without any sort of interaction with the user or codebase and flies out leaving the Team to tidy up as best they can.... Unfortunately Seagull Architects are still out there causing a nuisance on all types of project, not just agile. So please, Do Not Feed the Seagulls.... (Note - there are unconfirmed reports that Seagull Architects are evolving. Into Vulcan Architects. Here they walk in, Vulcan-mind-meld with the requirements and codebase (again without any real interaction with customer or real world code), and announce the design required. "That's illogical, Captain")

If you think you're beaten, then you are. I have recently been involved with a team where key players spent enormous amounts of time and energy trying to identify reasons why we shouldn't try things. Working with people like this drags down the entire Team. It lowers morale because it becomes harder to make the changes that energise the working environment. The Team knows that it can never get better because the naysayers will do their best to block change and maintain the status quo . If only people would spend time and energy actually fixing the problems instead of finding reasons to justify substandard tools, processes, practices and behaviours.