Thoughts from a Thirsty Bear

A term that I still hear occasionally is "SDET", or "Software Development Engineer in Test". It is also known by a few other terms - Developer in Test, Test Automation Engineer and so on. Essentially it is a job role for a developer whose main responsibilities are to write automated tests and frameworks to check software. And it is a truly awful case of missing the point completely . It is a job title that indicates a fundamental systemic problem in an organisation. First, some history. Back in the Bad Old Days of the 1900s, we used to develop software using a linear waterfall style process, mostly due to a bizarre and tragic misunderstanding of a single academic paper (Royce, 1970). There was a lot of management thinking that modelled software development as a factory production line, and assumed that there were cost reductions from specialisms - someone creates a software design, someone builds that design, and someone tests what has been written. At the end, som...

Established companies today are facing many problems. Recovering from the Covid pandemic. Adapting (or otherwise) to remote working. Keeping up with younger, smaller, faster competitors that seem to be able to adapt much more readily to today’s VUCA environment. The list seems to be endless. To do this, many are changing the way they work - they are undergoing transformation . But…many have a problem… I give you the Pitts Power Paradox of Organisational Transformation! (Not exactly a snappy title, granted). Let me explain. Having been involved in many of these transformations where ‘traditional’ companies are attempting to change the way they do business, I am seeing a common pattern of failure. They ignore one fundamental issue that can be summed up in a single quote: “ All organisations are perfectly designed to get the results they get. ” - Arthur W. Jones Every organisation already has a system in place - a way of working - that gets precisely the existing results. To change the r...

Recent posts by Dave Farley and Jim Kinsey , and the release of the Accelerate book by Forsgren et al appear to be bringing dysfunctional development practices firmly into the spotlight once again, most specifically the practice of combining feature branching and automated builds, while calling it “continuous integration". I have already written my own opinion piece on the practice . In summary, I hate it - in a modern, collocated team it is wasteful, suppresses fast feedback, and completely undermines the advantages of powerful teamwork enabled by continuous integration. It harks back to a software dark age that I honestly thought our industry had finally left behind. It really is Continuing Isolation. But perhaps the most damning piece of research about Feature Branching that has come out in recent years is best summarised by Dave Farley: If you are not merging your changes to Trunk at least daily, [the research] predicts that your outcomes are more closely aligned with...

Feature branch workflows appear to be the flavour of the month for software development right now. At its simplest, features are developed in isolation on their own branch, then merged back to the trunk. More complicated variants exist, most notably Git Flow . Git is undoubtedly a powerful versioning tool. It makes branching easy and reliable, and it is truly distributed. These capabilities open up a whole range of possibilities and workflows to support different ways of working. But, as usual, the sharper the tool, the easier it is to cut yourself if you don't understand what you are doing. My problem is this. Feature branching is a very effective way of working when you have a large, distributed team. Code is not integrated with the rest of the codebase without a lot of checking. Pull requests ensure changes - often done by developers who are in other countries, and often part of a loose-knit open source development team - are reviewed by a core team before being inte...

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 m...

Aka "Absent Scrum Master Anti-Pattern" There is a question that keeps cropping up when talking to clients. It is  “How many teams can a Scrum Master lead?”.  My answer? Just the one. Let’s take a closer look at why people persist in asking this question, and try to understand better why it is generally a Bad Idea™.  When a team is running well, everyone is happy, and product is being delivered successfully iteration by iteration, feature by feature. There is comparatively little for the Scrum Master to do aside from day to day housekeeping. Everyone knows how the process works, everyone plays their part. The system chugs along and delivers. The SM appears to have a huge amount of slack, which most organisations believe is a Bad Thing - slack means they need to squeeze out more performance (read “ profit ”), in this case by giving the SM something else to do. I.e. another team. And maybe another. And another. Or other random responsibilities. Ignoring the ...

I practice, teach and coach Test Driven techniques. Test Driven Design (i.e. using unit tests), Behaviour Driven Development, I use them all on an almost daily basis. I find them useful since they help me do my main job of delivering software. Yet once in a while I am asked  whether I could be more "pragmatic" and less "purist" over Test Driven Development and Behavioural Driven Development techniques. I always find this an odd request, especially when I have been brought in as the subject expert to teach a company, or as a lead developer with a solid grounding in these subjects. But maybe this is not obvious to some, especially those who have never used the techniques correctly - or at all. This article looks bit deeper into the request, and see why I am totally nonplussed by even the idea. Firstly, what does TDD and BDD (arguably the "pure" version of them) usually look like? To me they look like closely related cousins, which makes this brief summ...

“The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities. ”,  Edsger W.Dijkstra ...or in other words... "If you already have a hammer, it is very tempting to treat everything as a nail" My views on using electronic tracking tools  are already fairly well known . But another area that creates a huge impact is the choice of version control system. Using the right software will help your project deliver quickly and efficiently. Choose the wrong one, and the project will be nobbled by unnecessary, damaging and sometimes downright dangerous processes and maintenance overheads right from the start.  In order to avoid the trap highlighted by Dijkstra, it is essential to match the tool to the way you develop and not the other way around .  Let’s consider a fairly typical, highly productive and successful team. In my experience they tend to follow a fairly well defined pattern of working:...

"You want to buy an agile? We sell you an agile. Very cheap. Very easy." Doesn't make sense, does it? And yet many companies accept equally nonsensical marketing speak because they want to " do agile" . " Agile " is not a physical thing that can simply be bought or sold; it's not a commodity. It is a concept. A philosophy. A mindset. A way of thinking. You cannot just be handed one to use. It requires you to make a fundamental change in yourself. If you are not prepared to invest in that change, then you are wasting your time and money trying to achieve the goal. You have simply bought an agile , and put it on a pedestal in the corner. " Look, that's our agile. Do you like it? " (actually no. It's a dodgy colour and clashes with the curtains....) Equally, any company claiming to be able to implement agile simply by putting in place a simple process is making the same mistake. Unless an organisation changes the way it think...

Analogies are useful to a point. They allow people to relate new ideas back to something they are familiar with, giving them a safe framework from which to explore new territory. However they can also be immensely damaging and misleading. I was recently reminded of one  particularly well worn example of the latter type that needs to be laid to rest once and for all: Building software is not the same as building a car. Developing a software product is definitely not a simple assembly line process. When building a car on an assembly line, you make the individual components - wheels, engine, chassis, seats etc - and then construct the finished item from these. Each component has already been designed in its own right, and they have all been proven to fit together many times previously. There is absolutely no creativity involved in the construction process. There are limited opportunities for different combinations of components (and those that are possible are well tested)...

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...

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...

Via Coding Horror : "A recent episode of This American Life interviewed Will Felps, a professor who conducted a sociological experiment demonstrating the surprisingly powerful effect of bad apples. " This is not news. In fact it's something that I and other coaches have suspected for many years. But this study provides some more scientific backing for our suspicions. In short, even one misbehaving team member can upset the entire team and endanger delivery. Getting the right people on the bus makes life much easier, massively reducing the risk of introducing agile thinking to a company and increasing the chance of successful delivery. OK, the study also suggests that a good facilitator can defuse the effect of the Bad Apple, but as the study shows , people capable of doing this are few and far between (only one team out of the entire study had a team lead capable of counteracting the problem).

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 ...

"Never try to teach a pig to sing. It wastes your time and annoys the pig" (Robert Heinlein, Time Enough for Love) When trying to become agile, Team members quickly tend to fall into three main categories (the percentages are purely based on my empirical observations and should not be seen as set in stone or based on scientific study!). 10-20% will "get it". These are the guys and girls who will be able to use the techniques to learn from their mistakes, spread their wings and perform. They are the future of the new, agile Company. 60-80% don't "get it", but are willing to try, or at least toe the line. They need more guidance about how to work efficiently, and that things are OK. They need more reassurance that the Team does not need this, that and the other supporting items (eg the massive Big Up Front Design documents, or a full specification signed in triplicate). With careful nurturing some people in this bracket will "get agile" (and tr...

I am noticing a worrying trend amongst companies wanting to take advantage of the perceived benefits of the Agile Revolution – specifically the faux-agile project. These are projects that have stamped themselves as “agile” but do not adhere to even the most fundamental good practice. When you scratch the surface they do not continually build and test, nor do they actively refactor bad design out. Unit tests are at best given lip service, and coverage is low. In most cases the only nod towards anything remotely agile is the lack of unnecessary – or indeed any –­­ documentation. When asked, the excuses for the shortcomings are many and varied – “ We know the structure of the software is awful but we don’t have enough time to refactor it right now, but we will get around to it later when we have more time ” (yeah, right…), “ Our Company culture does not allow the Quality Department to be integrated into development teams ”, “ We don’t know how to implement the automated build ...