In this interview, software developer Laurent Bossavit talks about why we need to think more critically about software development. He dispels common misconceptions about the industry and suggests better ways to improve the development process, such as agile and lean methods.
Josiah Renaudin: Today, I'm joined by Laurent Bossavit, a software developer who'll be delivering a keynote at our upcoming Better Software Conference, Agile Development Conference, and DevOps Conference West. Laurent, thank you very much for joining us.
Laurent Bossavit: Hi, Josiah. My pleasure.
Josiah Renaudin: First off, could you tell us just a bit about your experience in the industry?
Laurent Bossavit: There isn't a whole lot to say. I was a developer for the first ten years of my career, working essentially within startup-sized companies. I guess the closest I have to this claim to fame is being part of the first French internet IPO. That takes us to the year 2000 thereabout. After that, I became interested in agile and extreme programming to start with and after a few years of that, mostly because I wanted to be sure that I would be able to find projects working that route, I became a consultant and so that's how I spent the next ten years of my professional career, more or less. As of today, well, as of very recently, I’m with the French government to tackle a number of very interesting challenges like addressing the technical debt of the administration and heading towards government 2.0, so it's a very exciting job.
Josiah Renaudin: Now, your keynote focuses on the lack of credibility of some key software engineering assumptions. What led you to tackle this particular topic for the keynote?
Laurent Bossavit: It's kind of paradoxical, so the story starts two, three years back. Actually, maybe little more than that, but it's always painful to think about how fast the time passes. I was working on what was to become the Agile Alliance's Guide to Agile Practices. You can find that online actually, at guide.agilealliance.org, and it's basically a repository of short descriptions of the agile practices that I was able to identify. They're only just the first layer, actually. They're v1 and they were supposed to be followed by v2, but a lot of things intervene. Now the guide is in the capable hands of the Agile Alliance and they are no longer involved in the evolution of that, but it's a good start.
My ideal reader at the time was someone who was fairly new to agile, who was interested in being able to reap the benefits of that for their projects but had a hard time cutting through the jargon and maybe had some questions about the solidity of those claimed benefits because you could see a lot of hype around agile. I started investigating for things like pair programming, because we were in development, managing backlogs with task boards, the whole panorama of practices in agile and scrum, where they came from historically. I tried to write short but accurate descriptions of each practice to give people a sense of why they emerged, what problem they each addressed and whenever possible, I wanted to dig into the research that could provide some kind of justification for using those practices and letting people know whether they were going to get the benefits that they thought they were going to get.
I started digging into some academic research, some history of past jargon references, and pretty soon, I was up to my ears, basically, in the history of software practices in general because those things tend to be interconnected. For instance, one of the arguments advanced for doing a lot of upfront design tended to be some claims about the origin of software bugs, the distribution of software bugs in various phases of the project.
Another example is in order to justify doing tests within development, a lot of speakers in the community were referring to the so-called exponential cost curve for the cost of defects. Because I wanted to make sure I covered the right bases, I would be able to cite the papers that were appropriate to each practice, I started looking into all those things. What I found was not exactly what I had expected to find. It was an eye-opener.
Josiah Renaudin: You mentioned the origin of software bugs as one of the assumptions that lacks credibility. Can you kind of expound on this thought?
Laurent Bossavit: That's a very good example. If you look around, if you search for things like where do bugs tend to crop up in software projects, you are going to come across claims like, "56 percent of all bugs in a typical software project," and I stress the word typical, you will find people making that claim with those terms, "originate in the requirements phase." That's one of the most common phrasings.
I was obviously interested in learning more about how people had shown that to be the case. I wanted to get at the original research, so I went looking for the primary source. One of the annoying problems when you investigate those kinds of things is that there's kind of a telephone game where the first article that you come across repeats that claim, cites somebody who is in turn citing someone else so you follow the links back and when I got to the original source, it's one guy, one author making a claim about one company. I'm not even sure if it's not one project. It's basically a sample size of one and of course that doesn't have any credibility.
To be credible, you would have to investigate a great number of projects and even if you did have the time to investigate a great number of projects, you would have to make sure that you mean the exact same thing by bug and requirements in each of those, so it's a very thorny problem and I don't think anybody has actually invested that much time and effort. Still people repeat that claim because it's ... I think basically because it suits their purposes.
Josiah Renaudin: You just mentioned it: People repeating these different claims. What's interesting about these assumptions is at this point, it just feels like some people think they're set in stone, like they are just facts. Can you briefly explain why some of these claims and assumptions became so widespread?
Laurent Bossavit: You know the word "proofiness"? And I just very recently, a few months ago, read a book called Proofiness. Sort of the same concept as truthiness, but it applied to claims that contained a number—apparently what seems to be going on as if I tell you, "Many bugs come from the requirements phase," you're going to give a, "Well, yeah, that's plausible but it's essentially your opinion." If I come at you with, "56 percent of all bugs come from the requirement phase," that claim, that statement in those exact words, has a degree of proofiness. It carries more authority, whether or not the backing of that claim, to use a technical term, is actually sound.
One reason is simply our tendency to be more easily impressed by claims framed in numerical terms. Another reason why those things become widespread is because they kind of flatter our existing prejudices. We don't look at them too closely and we tend to be a bit uncritical when repeating them and citing people making those claims.
Josiah Renaudin: How can lean and agile practices lead to an alternate approach for software development?
Laurent Bossavit: What's interesting is many supposedly empirical claims in software engineering turn out not to be that solid. One way of looking at agile specifically, and by that I mean the whole complex of discourse that revolves around agile, is as sort of a competitor to the historical approach to software engineering. I think one of the distinguishing characteristics is agile explicitly encourages people to be more inquisitive, to confirm their beliefs through the experience of reality whereas ... Not just ... When I say people, I mean the people doing the work. To contrast that with software engineering's approach which is, I think, more tinged with a sort of Taylorism or a Fordism, if you will, where there is a clear distinction between the people doing the thinking and the people doing the doing.
There's kind of an underlying assumption in the agile discourse that people who are best equipped to investigate why we are getting the results we are getting and what we might do to get better results if we are not satisfied with those is the people actually doing the work. That was not necessarily the original intent to improve the state of empirical research in software engineering when people formulated the original agile approaches and then elaborated on those with additional practices, but I think that has become a very critical aspect.
Josiah Renaudin: What can software developers do to dispel these common assumptions within their teams and encourage new smarter critical thinking? After listening to your keynote and everything that you say about this topic, what can they do to go back to work and make sure that there's some sort of change being affected in their environment?
Laurent Bossavit: One very practical answer to that is after attending the keynote, they can come to the workshop. We're doing ... We being Michael Bolton and I ... Michael is a tester, also a friend and someone whose work I admire and he has been doing a lot of work on his own in critical thinking for testers. I come at this from the programmer side of things. We found a lot of common ground obviously because critical thinking is critical thinking whatever the domain. We put together a half-day workshop on very specific tools that people can use to immunize themselves against proofiness basically. It's very hands-on.
We invite people to come in with laptops and master a few proven techniques. There is a very practical aspect to this. When I started out investigating some of those iffy claims in software engineering, I was often blocked by not being able to access the articles I wanted. I developed a set of techniques for locating information I needed, locating other sources of information, framing a problem in a way that made me better at finding the weak aspects of the claims and we're going to cover all that. That's the tactical answer.
The broader answer, the overall answer, is to maybe start thinking of their role as software developers in a different light. One of things I often say is our job is not to produce code, it's not even to produce solutions, it's not even to listen to our customers and stakeholders, although that starts coming close. I view software development as a process of knowledge capture, as essentially a learning activity.
In my view, every software developer should also take on the role of a scientist, of an investigator in the mysteries of the wonderful world of software which also includes, and that's one of the things I appreciate about the agile discourse, it also includes the human aspect. We are, I think, involved in a learning process that involves primarily other people and secondarily, although it is obviously a huge element, it involves computing machinery. I think all of us would benefit from being more curious, being scientific and methodical in the way that we go about deploying this curiosity and there's a whole lot to learn in that respect.
Josiah Renaudin: You'll have a lot to say during the keynote and during your workshop, but kind of boiling it all down, more than anything, what message do you want to leave with your audience?
Laurent Bossavit: It's not the things that you don't know that are going to kill your project, it's the things that you know that just ain't so, to borrow a saying. If you want to learn how to avoid that because it's easier said than done, come to the workshop and maybe read the book The Leprechauns of Software Engineering. I'm going beyond the key message here, so be careful about what you think you know which just isn't true.
Josiah Renaudin: All right. Thank you very much. I appreciate your time and you sitting here and talking with us, and I'm looking forward to hearing more of what you have to say in Las Vegas.
A software developer with more than twenty years of development experience and a few years as an independent consultant, Laurent Bossavit heads Institut Agile which aims to help agile software development become better established as a disciplined development process. Passionate about helping people in agile communities network and support one another, Laurent is a former member of the Agile Alliance board, recipient of the 2006 Gordon Pask award for contributions to agile practice, and co-founder of the Coding Dojos. He is the author of The Leprechauns of Software Engineering: How Folklore Turns into Fact and What To Do about It.
