Better Thinking for Better Software: Thinking Critically about Software Development: An Interview with Laurent Bossavit


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, 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?

About the author

Upcoming Events

Oct 01
Oct 15
Oct 24
Nov 05