So far, I think I have undervalued the importance of some practices when it comes to working in a large-scale development shop with lots of teams. One of the major problems with software development in the large is that we as an industry of software developers are terrible. We have bad development practices in place, and it’s strikingly easy to hide your bad software development skills in larger corporations. I also think that the Craftsmanship movement could come up just because we have badly educated software developers since decades.

The problem

Last year, I did a training class with a development company. They had three teams. I had a training with three developers on TDD with Javascript. I never programmed anything in Javascript. I prepared well enough for the class to be able to help out with Javascript. The most junior person on the team had been working with the company for half a year. We worked together on a code kata during the class. I noticed a pattern. That guy was basically using Google in order to find snippets to copy and paste, and try them out. Half a year into a programming language that guy was still using the same pattern that I used a few days earlier to get familiar with the language.

He hadn’t advanced in the language for half a year.

At another client, I worked with a colleague together to run a training class on TDD, and help with some technical coaching for the transition. We paired with programmers over the course of the day. One guy explained to me that he just had left university (half a year ago), and asked me for a book on unit testing, mocking frameworks, and so on. At that time, I didn’t know one concise book on that, and provided him with a couple of books instead.

Even after visiting university and working for half a year, that guy did not advance with unit tests for half a year.

Do you see a pattern here? I think it comes back from the 90s and early 2000s when people exclaimed that programming was the future, and we needed to have more programmers. People entering university were also told that you can earn a whole bunch of money if you joined the programming business. Skip forward a few years, and I can see lots of programmers in the IT departments of this world where programming is merely a job, not a passion.

What Bob Sutton taught me in “The No Asshole Rule” is that these folks over time infect your company. Motivation drags down from all these Wallies out there. Also people stop advancing, and put more energy into fighting with each other in order to justify their salaries. It’s bad, and I think it’s a problem we constructed years ago by demanding more programmers even though we could have been aware of Brooks’ Law – and the generalizations of it.

That said, also notice that the problem is not the problem, but how we tried to cope with the problem years ago.

I strongly believe that coping did never work, does not work now, and will never work in the future.

How to fix it

While reading through Larman and Vodde’s Practices for Scaling Lean and Agile, I noticed their strong belief that Continuous Integration and Acceptance Test Driven Development help there. A notion that I never actually got so far – until now.

Figure two companies. Company A has component teams. Company B has feature teams. Company A needs the teams to coordinate among each other. They need architects and requirements analysts to split customer requests among the different teams. They also need integration testing in the end when all the teams delivered there piece of the mix, and they need managers that keep track about that.

Company B delivers functionality from each of their teams. They don’t need architects and requirements analysts that break down requirements and architecture on various components – they need these folks as part of their feature teams. They don’t need integration testing in the end, since all that needs to be integrated can be dealt with within the delivery cadence of the team. They also don’t need to manage stuff between the teams, since they are self-organizing between each other.

I know, I probably drew a false dichotomy here. These might be ideal pictures, and I have seen some companies being more like company B. Most companies though I have seen are more like company A.

But what enables folks in company B to deliver working software more quickly? Continuous Integration with a high degree of coverage for their unit tests, and a combination of Acceptance Test Driven Development with Exploratory Testing.

What?

Really. Instead of relying on a manager to coordinate these folks among each other, with these practices in place they can coordinate themselves more easily. ATDD will help them understand the customer requirements better, thereby getting the functionality right the first time more often. They will also uncover hidden risks and assumptions with Exploratory Testing. They will also be able to work on the same code base since unit tests guide them once they introduce a problem. Oh, and the CI process makes them aware whenever they oversee something.

Yeah, right, so what?

Now comes the hard part: these practices are hard to learn. Maybe that is why universities skip these practices in their courses. My mentor during my diploma thesis urged me to use a version control system. I was pretty surprised when I worked with a team a while back that didn’t have SCM in place – that was years after my diploma thesis.

We as an industry are terrible at some practices. That is why we are suffering so much. We are suffering so much because in times of urgency and pressure it’s ok to skip all this hard stuff. But as a drug addict, that will eventually dramatically hurt us and slow us down in the long run.

I think we can improve as a profession. I think we have to improve as a profession. I think we have to show that we can do better than what we currently do. So, next time someone asks you to skip that particular practice – probably because he doesn’t understand it or doesn’t see the value in it – refuse. You will be better off in the long-run – and won’t hurt your profession. That would be the morally right thing to do.