agile

What? You’re doing TDD!

h_4_ill_1022732_black-sheep-bisI’ve always been distrustful by default with the “main way of thinking”. Which doesn’t mean that I systematically reject the opinion of the majority. But given the strong tendency of human beings towards laziness and our natural tendency to sheep-like behaviour, the faster something gets popular, the more I question it.
Test-driven development has always fallen in this category for me. The problem it’s supposed to solve is real: software coding is a highly error-prone activity and we need to do everything we can to avoid shipping erroneous code. I totally agree with that. But then TDD is just one solution to this problem: to avoid shipping errors, let’s test and check our code in order to detect errors before shipping. But this solution leads to other problems:

  • tests are just more code where there can be other errors, and that need to be maintained. So what about false positives and negatives?
  • test writing has always looked like a very boring and chore-like activity to me, especially if it involves thinking about my implementation algorithm before I actually write the corresponding algorithm, which is often required when doing behavioral testing
  • I’m still not convinced that ensuring each part of the system is working is supposed to reassure me about the system as a whole.

And more importantly, there are other alternative solutions to the same original problems: for example, instead of waiting for tests to fail to fix mistakes, why not trying to avoid them in the first place? We have some pretty good tools for that: refactoring is error-prone, especially when you use a refactoring engine that is not reliable. Then stop using Eclipse, move to IntelliJ. You keep reproducing the same wrong patterns from some old language you’ve worked with for 10 years? How about static analysis? And instead of typing that much error-prone boilerplate code, why not use code generators or dynamic languages like Groovy? I’ve been using all of these tools for years, and I’m gonna say something bold here: I shipped some pretty decent software with not enough bugs to justify the  weight of TDD. A craftsman can also go a long way in improving his work by getting better tools, and training himself to use them. Actually that’s what really pisses me off with all the TDD religion thing: too much focus on techniques and processes, not enough on technologies and people. And I think I’m just more interested in the latter two.

Now most of the time, when I raise my objections about TDD to people who say “What? You’re not doing TDD!!!” with some sort of horrified look, they just answer me with disdain instead of actual arguments, which can mean one of 2 things:

  1. They didn’t look into it that much. They just followed the trend because it seems nice to say that you do TDD
  2. I didn’t look into it enough and some of them are actually right to treat me that way, because I don’t know what I’m talking about

I thought I had tried TDD enough in the past to avoid the second option, but this morning I attended an amazing talk by Robert C. Martin at Devoxx. In fact, there was another talk before by Ivar Jacobson. And the guy kept talking about software as an industry (comparable to manufacturing for example), about the fact that we have a big professionalism issue (which I totally agree with), and that in his view the best way to fix the problem is to add some theoretical foundations into the mix. Let’s say I didn’t agree at all with his view of where the problem lies, and with his inferiority mix up towards other industries. But on the other hand, I agreed a lot with Uncle Bob’s view of things… until he started talking about how silly it was not to do TDD these days. How can I agree with his conception of where the problem really is, and not with one of the main solutions he proposes. Maybe I’m missing something here. The best way to figure it out is to read in more details what he has to say. And given the incredible energy he showed in his talk this morning, his book is likely to be a lot more interesting than all the TDD manifestoes I’ve read in the past (or tried to read before falling asleep).

By Sébastien, ago

Meta-Agility

I’ve been a professional software development consultant for 3 years now and I’ve seen agile methodologies become very popular in the company I work for. A lot of people have started using SCRUM on their customer projects and the approach has proven to be very successful. I think that the most surprising realization people have come to is that for years, if not decades, we’ve been stuck with the old way of doing it, thinking that software development could be planned and industrialized just like any manufacturing process. And a lot of software projects have failed, over and over again, before some people actually started to think outside of the box and came up with a more pragmatic and realistic approach.

Now, even though the methodologies themselves are very interesting, even though those methodologies still have plenty of room for improvement, I’m starting to see people trying to map agile methodologies on other things than just software development. People extract small chunks of SCRUM, like managing tasks through post-it notes, frequent synchronization meetings, specifying deliverables in user stories. But after playing a few months with these fun tools, they are starting to realize that they don’t work so well out of context. Because what makes SCRUM so powerful is the fact that it is a small but very consistent set of practices that all work together with common objectives to reach: the four principles of the Agile Manifesto. And it’s becoming obvious now that we cannot just take a few of these practices out of context and expect them to work for other purposes.

In fact, I have the feeling that people are more and more seduced by the meta-level of agility, the reflexion that led us to rethink our whole way of working to reach better results. And in my opinion, THIS is what we need to reproduce: the approach that led us to design the methodology, not the methodology itself.

Let’s try to analyze this generic approach:

First of all, let’s define our scope. For SCRUM, it was software projects with everyone working on the same spot at the same time. In Axen right now, it’s change management, more precisely how do we introduce a new business model into our company while keeping up the good work on the existing one.

Second, what’s wrong with our current way of working? For software projects it was that everything was linear (analysis, design, development, testing) and offered really poor visibility on how things were going. For our change management process, it’s the fact that all the team work is pretty much done in disconnected after-hour meetings, because everyone has a day job to keep the existing model running. The end result is that a lot of energy is wasted in pointless discussions and motivation is lost inbetween meetings, people working pretty much on their own.

To be more precise, agile methodology gurus have come up with a very interesting way to think of failures and solutions in a very constructive manner: what do we value over what? For change management, examples could be:

  • remote collaboration over individual work and synchronization meetings
  • small manageable objectives rather than big multi-year expectations everyone loses sight of
  • professional evolution over personal sacrifices in exchange for fun

At least that’s my view of what’s not ticking in our current way of doing it. I know that other people have different views and hopefully we’ll soon have a debate and come up with a consensus on the four or five values we need to encourage for everything to work.

Then when you know the values you have to put forward in order to reach your objectives on any project in the same context, you can start to think of the tools and practices you need to implement:

  • remote collaboration can be helped with collaboration software easing communication and issue tracking
  • user stories are good for software, but the actor/action/goal paradigm might not be the most adapted to the implementation of new business practices. We have to be creative and find a new way to define our “requirements”.
  • change management cannot be free, and investing money to free up time is not enough. Maybe some of this money needs to be dedicated to training participants on new techniques and knowledge that will improve their professional experience while developing the global expertise of the company.

And of course, once again, plenty of ideas can come up if we allow ourselves to think outside of the box and stop trying to make new stuff with spare parts from old stuff.

I will soon try to initiate this reflexion inside Axen and hopefully we’ll come of with a new change management methodology that embraces the constraints of this context rather than trying to hide them under the carpet. To be followed…

By the way, if you work for Axen, you know that the company takes great pride in involving consultants into its evolution. So what do you find motivating or not when working on those internal projects? If you don’t work for Axen then maybe you’ve worked on similar change management projects and you have your own experience on how to make it work while involving everyone in the process. I’m very interested in your feedback.

    By Sébastien, ago