The Technical Debt Myth

We assume that less design effort allows producing features faster, in the short term.  Less design effort generally means less abstraction, and tighter coupling, in order to produce working code faster.

But we tend to overlook the fact that it slows future modifications, even of unrelated features, because of tight coupling. We usually call this fact « technical debt », the term was first coined by Ward Cunningham. A better name was suggested by Steeve Freeman: unhedged call option.


Financial debt vs. Unhedged call option

Financial debt is predictable. You know how much you get, and how much you will pay back. A debt could be useful from a business perspective. A cash boost at the right time can create a major competitive advantage.

An unhedged call option also comes from the financial world, and is a really risky operation because it has unlimited downside. The buyer pays a premium to decide later if he wants to buy. The seller collects the premium, and will have to sell if the buyer decides to buy. It is not predictable for the seller.

Transpose to software, the difference with the concept of debt is the predictability in the amount of work required to fulfill our engagement.

When we write crappy code (tightly coupled and without tests), we collect the premium: we immediately get benefit from the new feature.

But as soon as we have to maintain or evolve this codebase, the option is called, and we have to pay an unpredictable amount of time (thus money) to achieve our goal.moneystack

Why? Who?

Every time this kind of tradeoff is required, we should ask who is asking for this, why, and who is going to pay it. Fun fact: those who ask for it (and directly benefit from it) are not often those who will pay it.

The sales team for example may ask for a quick hack because the customers « really, really need it yesterday ». But it may be paid by the production team, because next time the customer will want something, we still have to produce it quickly, without any regression. That’s where we will support more pressure, and may do some overtime.

In the end everyone will be impacted, because more pressure means more bugs, more regressions, and finally unhappy users. No company can survive unhappy users forever.

That‘s why good design matters. We want to produce current and future features in a sustainable and predictable way. sustainable_development_and_you

But what‘s good design?

We all try to do our best, but some of us lack knowledge and/or feedback. Plus, good design is contextual.

But regarding of our context, good designs have common points. It allows to think clearly about our software, and to evolve it easily. It allows to know where we should add/modify/fix a feature. The evolution-ability gives us an option on how to add/modify/fix this feature.

Software must be able to evolve because we know we don’t know what the software will be. We must design to be able to discover (as explained by Dan North in the 3 ages of innovation)

Decoupling is then required because we need to think about small parts in isolation, without side effects.  This kind of good design allows producing predictable software: robust, resilient and without regression when it evolves.

If we use shortcuts, and couple our code in order to rush it into production, we must be aware there will be an unpredictable amount of time to pay to get back into a predictable state.
It does not mean we should never do it, but we all have to understand this trade-off before asking for a “debt”.


What about speaking of predictability?

The more shortcuts you take, the less predictable your software will be. If you pay more for well design software, you get the opposite effect.

Unfortunately it is hard to judge, as we usually think we design software well. A good way to know if we are on good track is to rely on how predictable is the software we produce. Are the customers happy? The production team? The sales team? Do we have very few regressions? Do we produce features at a regular speed?

If not, we should consider investing more on design and refactoring, before entering into a vicious circle of unmanageable software.

Order Or Chaos Directions On A Metal Signpost

The technical debt Myth.

That’s why the comparison with a financial debt is sub-optimal. Money debt is predictable, whereas software debt is not. Unhedged call option is a better name, but still comes from the financial world.

Maybe we should stop financial comparison and speak of predictability instead. I find it is a better description of the consequences of shortcuts in the design.



Thanks Brian Gibson, always here to help me to improve!



We did not forget how to code

In a recent article, David Haney asks if we have forgotten how to program. I think not, rather we evolved.

We evolved from writing technical not so useful code to writing specifications.

Don’t misunderstand, when I am talking about specifications, I am talking about code. I am talking about coding crystal clear specifications even a computer can understand.crystalClearHow can we write “good” code?

Good code has two characteristics: it is useful for the business and usable for the developers. (usable in the meaning of Alexandru Bolboaca  and Johan Martinsson , for more information please refer to Alexandru’s book currently in writing, or Johan’s blog).

To write useful code, we need continuous domain knowledge crunching and refining. We want to avoid  technical stuff producing no direct value for the business.

To write usable code, we want to write code with clear abstractions, and easy navigate around these abstractions. We also want to replace/modify some code without pain.

From a business point of view, unless they are in a really specific context, they don’t need to know how to pad left. They don’t need to explain it either, because it’s obvious.

From a programmer’s perspective, we also rarely navigate in such an obvious low level of abstraction.designRewrite everything?

In most modern languages, these obvious and technically common operations are part of the core framework. Even if we know how to code them, even if it is quick to code, we don’t want to, because it creates no value for the business, and no usability for the developers. It does not make our code better.

 It’s dangerous to say « We should not depend on other libraries, we should rewrite what we need! » Where do we put the bar for « rewriting? »  Should we stop using NPM? JQuery? What about .NET and Java?    rewriteIt’s not the user’s fault, it’s the design’s fault.

That’s a core rule from UX translated to usable software design. We should always keep it in mind when trying to understand a problem.

The lesson from this “left pad” story is not that we should re-write everything to depend on nothing, but that NPM’s design allows a library to be deleted, or worse, to be changed.  

Imagine if Microsoft decides to change the behaviour of something widely used like String.Concat ? (or String.PadLeft if you lack imagination)

Asking every .NET developer to write these themselves is not the solution, even if writing a concatenation function is easy.

It’s unsustainable, a whole ecosystem cannot be built on an unstable foundation. If we want an ecosystem to evolve, we need a rock solid foundation.

This story shows how immutability is fundamental when thousands of users are depending on us.  

This kind of dependency, when hiding obvious stuff, is not necessarily bad. It’s more like solid roots allowing us to grow up.goodBadUglyDependency: the good, the bad and the ugly

The difference between bad dependencies (big frameworks) and good dependencies (little libraries) may be tricky. The key is: if the hidden part seems obvious to us and adds no value to our business, then it’s a good dependency. Otherwise we should prefer to rewrite it in complex contexts, because we will quickly be limited by what we don’t understand in our framework anyway.

This story should teach us that building an ecosystem is hard, and requires immutable, solid foundations. Please don’t re-write everything.

Let’s evolve together.


As usual, thanks to my kind reviewers: Brian Gibson, Jean Helou and Jérôme Avoustin


About hiring the best

A few years ago, three co-workers and I decided to work on the concept « hack your job ». We were convinced there was something wrong with recruitment and set out to find a technical solution. We wanted to find a better way to match great developers unable to find interesting jobs with great companies unable to find interesting developers. We concluded this problem required a human solution. Today, I would like to share a potential human solution to improve the recruitment process.


Disclaimer (edit)

I had some feedback accusing me to try to find a generic solution to hiring. As explained in conclusion, I don’t. My context is a start-up context with highly passionate and motivates people. I don’t claim the proposition I do here is generic, I don’t even claim it’s a good solution, I just assert this is how I would personally try to find great co-workers in my start-up.

I could even write a general disclaimer, I don’t try to teach anything to anybody in any blog article, I just give my feelings and experience.


What’s wrong with recruitment

I think the root cause is our mental bias for judgement. We believe ourselves to be good judges. We actually do it instinctively, anytime we met new people. Fact is: We are very bad at it. Humans are complex creatures. We can’t understand them within a few hours. It is known as the sampling bias. We believe a sample of time with someone will be enough to know if she is a fit for the job.


Military recruitment 

Daniel Kahneman is the psychologist who wrote Thinking Fast and Slow. In his book, he describes this error very well, because he did it himself. He worked on a team in the army to evaluate new soldiers. Their task was to determine if the soldiers would be good leaders (thus candidates for officer training) or not. They worked really hard to create a comprehensive series of psychologic and physical exercises to determine the soldier’s leadership skills. Tests were run over several days, the team’s confidence in the results they produced was high.

However, after a few years, the feedback they received was disappointing. Few soldiers they recommended for officer training were considered good leaders in the end. And many less recommended soldiers reveal themselves as good leaders.


Software recruitment  

Jeff Atwood recently wrote an excellent article on the topic. For him, software recruitment is wrong. I strongly agree and will reiterate many of the arguments and solutions from this article, adding my personal understanding and experience.

I see two general approaches to interviews:

Either we conduct an easy and short interview where how a candidate “looks” has a larger role than what they are able to do (not on purpose, but this is how our instincts work).

Or we conduct very long and complex interviews, often in several steps, lead by technical gurus. In this kind of interview, we believe we’re looking for talented people, but actually end up selecting technical clones of the gurus leading the interviews.

I’m not sure which one is the worst. With the first kind, chance is a big factor, but at least we may add diversity in our team. Maybe we won’t hire the best technically, but we will more likely find the disruptive employee with the ability to challenge our work. With the second kind, we will find people fitting our technical needs, while rejecting, more diverse candidates who just did not perform as well during the interview.


Hard interviews do not produce great candidates 

They produce great CV writers able to perform well under pressure. Are we hiring engineers for their writing skills? Do we plan to let them work under pressure ? Under pressure we can’t see the big picture, we can’t challenge and improve ourselves. We sense and react to whatever comes next. It’s not a professional behavior.

Removing pressure is the main goal of what I do almost everyday as a software developer. Unit testing, decoupling, context analysis…Whatever I do, I do to improve and manage my work in my context. Understanding our context and mastering the code we produce reduces the pressure we have to support.


How to find great candidates?

A software engineer writes code, with a team to solve business problems. An interview should be exactly that. Instead of simulating stuff, perform a selection based on the developer’s passion, as advised by Sandro Mancuso in his book. Can you find her on Twitter? On GitHub? Can you see some code she wrote? Is she active in local user groups? Any blogs? StackOverflow profile? None of that? Nevermind, take a coffee with her and find clues of her passion. Does she code at night? Any side project? How does she feel about new technologies? Does she realize we developers are changing the world?

As soon as you think you found someone passionate, find a way to work with that person for a few weeks. Jeff Atwood suggests asking them to work at night, or on weekend, or take vacation (if someone does that, it’s a clear sign of passion), and of course, pay them. Consider them as part of the company during this period, so they can really show you how they behave as software engineer. At the end, decide together if they are a good fit or not. You must especially hire them if they are better than you.


How to find great companies?

Be the candidate we want to work with. Recruiters cannot take the whole responsibility for bad hiring processes, candidates must adapt their behaviors too. An interview  is a two way process. The company learns about you and you learn about the company.

Show your enthusiasm, give some feedback to recruiters if you think their processes or mails are not that good. Show some respect and passion. Show your interest to understand their problems and how they plan to solve it. Be a Professional, always raise the bar. You can’t wait for the perfect company if you don’t try to be the perfect co-worker.


Hacking the interview

It is certainly not a perfect recruitment process, it is not meant to be. You still have bias, but by increasing the time sampling, you reduce the overall judgement bias and luck factor.

Fighting our biases, as candidate and as recruiters, is one of the hardest and most useful things we can do to improve our hiring process.


Thanks Brian Gibson , Clement BouillierAlin Dicu  and William Huart for the reviews and feedback.


Let’s be people centric

DDD, like agile and software craftsmanship, is very hard to teach.

We can explain concepts, describe patterns and practices, show some good habits. Still we can’t easily teach them, they are too large. The cognitive load is too heavy.

The consequence is that we usually focus on a subset of practices, and claim this is the essence of the principle. This is why some people believe DDD is tactical patterns, software craftsmanship is TDD and agile is SCRUM. It also explains why frameworks or simple patterns like micro services are over used.

I find this dangerous and believe it’s important to understand what these hard topics have in common. If we understand what is intrinsically hard in them, we may learn how to teach them in a more efficient way.information

It’s not about answers

It’s about questions. The three topics do not bring magic answers to our problem. They usually bring more questions. These questions allow us to evolve, to improve ourselves, and to dutifully accomplish our jobs.

They require being mature to accept that every answer we find will lead to more questions. They require courage and perseverance, but it’s worth it, because improving our habits will improve our professional life.darrell-fraser-quote-there-are-many-questions-but-no-answers

It’s not about a generic solution

It’s about context specific situations. There is a single answer to these three questions: What should we do to be craftsmen? What should we do to be agile? What should we do to be great DDD practitioners?

The answer: It depends.

What is our context? Do we work in a multinational or a startup? On a web or desktop application? In the finance or healthcare industry? The combination of all the specificities of our jobs is our context. For each context, different implementations are required.

What makes sense in one context is not necessary what makes sense in others. Every single architectural pattern coming out of Silicon Valley is not necessary a must have for your next project.


It’s not about technical stuff

It’s about people. The deep roots of DDD, software craftsmanship and agile are about people. Unfortunately, we mostly apply technical practices hoping to solve people problems, but fixing people is really hard.

Instead we should concentrate on understanding how they communicate and their particular business needs that are crucial to helping them create conversations

Should we stop talking about it because it’s easily misinterpreted?

Of course not, but we should be aware of this problem when we are trying to communicate these subjects. I heard more great advice from Liz Keogh at DDD Europe 2016 that we could apply here: “Don’t strive only for the ‘whys’, put some ‘whos’ inside.” When speaking of practices, don’t forget about the team, about the context, and about why we think they make sense or not for us.

This is how we could be more effective transmitting passion on these subjects. By speaking about what it brings to us in our daily work, others may apply it, if they recognize a piece of their own context in ours.

It took me seven years to realize that I shouldn’t be an evangelist trying to push what I think are good practices. Instead I should have contextualized for others habits that improved my professional work.


Let’s be people centric

Let’s stop being technical monkeys always defending what we know as the only viable solution.

Let’s improve our communication about deep topics like DDD, software craftsmanship and agile.

Let’s be people centric.


Great Thanks to Brian Gibson for helping me to improve my English writing.


Mob programming is a great BDD implementation

“All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer”  Woody Zuill

A few weeks ago, a co-worker proposed to experiment mob programming. I expected to enjoy this practice, I was actually delighted.


We are a pizza team (3 devs, 1 BA, 1 QA) in an agile context, not working perfectly but striving to improve. We have an automatic delivery process and a code coverage around 80%. Collaboration is quite good and we’re trying to follow some BDD practices.

We decided to give mob programming a try to develop a new feature. Our job is to develop a library to communicate with some hardware whose data model is changing. Our target is to be compatible with both versions of the model with no impact on end users. pizza-10


We did it in a meeting room, not in an open space. We had a computer, a big screen to display the code, two keyboards and two mouses allowing two developers to code without having to switch.
We also had a smaller screen to display useful technical or business data, and a big whiteboard.


The collective intelligence emerged. Questions and answers kept on coming. We drew the big picture, and saw which implementation choices we had. It was crucial to discuss with the domain experts the why of the model evolution, it allowed us to understand the business impact expected for this feature.

The test suite showed again how useful it is, we saw the impact of our choices within a few seconds. It was interesting for the BA because he had never seen these red/green lights in action. We refined our Ubiquitous Language, and it allowed our domain experts to understand our implementation, just looking at the code with us.

It was exhausting, much more than pair programming. In a mob, there is always someone or something to bring your focus back. It’s really productive, but it’s unsustainable if you don’t manage regular breaks.

Business experts were really involved, they were focused to understand and challenge our implementation choices. We challenged them back on some business terms and use cases.
They were reassured because they see how we technically deal with the problem.

We went out of our comfort zone together.comfortzone


BDD is about communication, and communication is about (professional) empathy for your co workers. You want to understand their perspective to (well) solve the (right) problem together. For this reason, mob programming is the best BDD implementation I know.

No framework, no process, no bullshit. Just bring the 3 Amigos (or more!) in one room and focus all together on one specific issue to solve.

Even if it was meant to be a hard problem to solve, we needed only a few days to find a satisfying implementation. Put enough knowledgeable people in the same room, let them produce code and you will obtain a robust and well understood solution quickly.

Think about it, how many useless meeting do you usually attend to grab enough knowledge to implement something? And what do you produce with this knowledge? Word specifications and/or powerpoint explaining the workflow? How effective is this knowledge transfer? Remember the first principle of the manifesto?

“Individuals and interaction over process and tools. ”


Do we need some meetings first

Absolutely, don’t do it if the topic is absolutely unknown. You need to have enough knowledge in the room to explain the problem and think about a few solutions.
A method like event storming would be more useful to explore the problem. You can’t just jump into the code, you have to explore the problem first.

But don’t look for the perfect solution during this exploration phase. I would even argue that you can’t find the best solution during this phase. The goal is to grab enough knowledge to understand the problem, and think about options.


It was definitely a really good experience, and I’m looking forward to do it again. There’s still lots of unchallenged habits in our traditional ways to develop software.

It makes sense to get people who know what to do and people who know how to do, in the same room, and let them build something all together. No Word/Excel/PowerPoint document will create value for your Company. Why not just remove them from your process?

Invest on methods such as Living Documentation instead, to generate documentation directly from your code. Get a documentation which is a true representation of what the software is, intrinsically.

Mob programming is definitely a new good habit I’ll try to share with other passionate co-workers.


Thanks to my team for the experiment, and to my reviewers:
Charles Bouttaz
Jean Helou
Nadège Rouelle
Maxime Sanglan
Woody Zuill



Remote working as a norm

Remote working as a norm

A few weeks ago, I was around the coffee machine at work, looking through the window the usual traffic jam of downtown  Lyon in the morning.  I was asking myself do people really do this every fucking morning? I mean, I understand we need to go to work every morning, but how many people stuck in the traffic jam every morning have really no other choice?

And by choice I don’t necessarily assert everybody should use a bicycle. What about a scooter? What about public transport?

And what if you just don’t need any commute at all because you can work from home? What would be the global impact if remote working was actually a norm, and not an exception?



This is my personal experience, feel free to challenge me at any point. For a little context, I’m a software developer with 7 years of experience. I had worked remotely during 2 years (2013-2015).

This blog post happens because I was astonished with feedback about this simple tweet. So I believe it deserves a little more explanation than 140 characters.


“What do you mean by remote working?”

I mean, normally not working in your company’s building.

In my personal experience, we worked at home but met together for a full day at least once a week. Also if some of us met a pretty hard issue, we worked together for a full day, either just on hangout, or physically in the same office.

I hope you notice ”not working in your company’s building”, working at home is certainly not an obligation. There are plenty of great co-working spaces out there.

Also we know some great companies like Github (ok it might not be great anymore) who were able to run distributed teams across different countries. A common mistake about remote working is: we assume you won’t be able to communicate with your co-workers.

Communication does not necessarily require two people to be physically in the same room. It’s a matter of tools and culture.

Even if I agree that remote communication may be harder than physical synchronous communication, I believe it’s a question of practice.

Good code requires good practices, the same is true for communication. Distance forces your team to improve its communication skills, to be more efficient.

Now let’s imagine the different impacts if globally, we all try to work remotely (I know you already want to scream: “But every jobs do not fit for remote working!” don’t worry, we’ll speak about that in the limits section)

remoteEnvironmental impact

First of all, imagine the impact on traffic if most people work from home or in co-working spaces nearby. Less traffic Jam, less fossil energy used. Of course it’s really hard to estimate what the impact would exactly be, but a quick search on google confirms that traffic is responsible for more than 25% of the global atmosphere pollution.

Because cars are mostly used to commute to work, It’s easy to imagine how big the impact would be if we avoid using them. And I haven’t even mentioned car accidents and related tragedies we could avoid as well.

It would definitely be great for our planet if we stop using our cars for unnecessary commute.


Social impact

Some people react to my tweet thinking I’m an introvert. Funnily enough, I think my remote working period was one of the most social I ever had in my professional life. Let me explain why.

When working remotely, when people ask you to come out for a drink or a restaurant after work, you’re pretty happy to go because you are not tired. You are happy to see people and you know you could wake up a little later next morning if you come back home a bit late.

Currently, I work 1 hour from home, I wake up at 7:30am and come back at 7:00pm. I feel pretty tired when I come back, and certainly don’t want to go out. Even when I do, I can’t come back too late or I will be really tired the next day.

Also you know all these places you can never go because they are open when you are at work? Yep, post office, bank etc. Well it’s no longer a problem, you can enjoy going anywhere without the crowd, and without the stress of losing your weekend in endless queues at some administration.

The consequences are: you are less stressed, have more fun and are rarely tired during the day.

Another interesting aspect is that it would also allow to spread population density and revive some rural or semi-rural areas. If we no longer need to commute in the big city where all the offices are, we might have a better population repartition. It would definitely benefit to little local businesses.


Professional impact

Simple personal observation: I’m globally more productive when working remotely by a factor of 1/3. No rocket science here, I use Pomodoro to track my productivity in a day. At work (classic open space) I perform 6 to 7 Pomodoros per day (around 3.5 hours of focus work), unless I’m working in pair or in mob programming.

At home I perform 9 to 10 Pomodoros per day (around 5 hours of focus work). For several reasons I guess. But as I explained, one of the main is that you have to communicate efficiently when working remotely. The rest of the time you can easily focus without being interrupted.

In an open space, communication is often chaotic, unorganized, and inefficient.  People walk around, and in the space of one minute you can hear about a birthday, a joke, and a critical bug in production.

Being less tired is probably very important as well, I have more energy which could explain my increased productivity.

Another great point, like explain here  is that you are judged with the work you actually do, not by the work you appear to do.
We all know workalcoolhics working very long hours in a very inefficient way and still being often congrats by the management.
In remote, nobody in your team is here to see “how hard” you work. Your only value is the quality and relevance of the code you produce. Maybe a “remote management” would actually lead to better result, at least in the IT industry for this exact reason.


Here we are, I hear you thinking: “But how can a school teacher or a physician work remotely?”

Yes, I agree, not all jobs  are a good fit for remote working. Jobs around software (building or using it) are the most suitable for this model I guess. But remember software is eating the world, right? So we could probably find a lot of jobs that actually fit this model.

Even for those who basically don’t fit, we could imagine different models. I agree, some jobs cannot be done remotely, but remember traffic generates 25% of atmosphere pollution. Even if we could find remote alternatives for 10% of all the existing jobs, it would definitely have a visible effect.


Let’s recap

If we would consider remote working as a norm, we could look how any job could be performed remotely. I understand it’s not possible for all the jobs, but I’m also sure that our everyday commute to our company’s offices is in part due to unchallenged and useless habits.

If we consider remote alternatives when possible, my feeling is that we could have less pollution,  more happy people  and more productive companies.

What’s your feeling?


Great thanks to Haikel GuemarLaurent Caron and  Nieve for the review.


Do you need what you want?

lol« Yeah, I know you’re testing and doing other xDD stuff. Looks great, really, but you know, our customers don’t want it…»


How many of you have already heard this? I heard it from many managers, trying to explain me that they are my friends, but that «real life does’nt work that way ». It was hard for me to argue with them, after all they were much more experienced than me, so they should be right, don’t they?

Of course I never agree with them, but it was hard to find good counter arguments when I started my developer career. Now I have arguments, so I hope this post, could help you if you need to argue on the same topic.

Instead of debating infinitely with people pretending to understand what I was talking about, I just left my job and started as a freelancer. I had only one goal: unless I desperately need the money, I will work only with people trying to improve the external AND internal quality of their software. This currently translates to: «I won’t work for you if you do not understand at a bare minimum why unit testing is not an option on a complex information system».

Business concept image of a hand holding marker and write Freelance word isolated on white

It’s been three years now and here is my current status:  I work less, I earn more, and I am a much better developer than before. And I now believe these managers were both right and wrong.

They were right, because I still don’t assert that customers want unit testing. And yes if you try to explain to them that you need to code to validate your code, you just make a fool of yourself.

But I still assert that customers need unit testing, because they need to change their mind a lot in order to be aligned with their challenging business, without introducing new bugs.

And for that, managers inspiring this post were wrong. They believe developer’s job is to provide what the customer wants. But if you just give people what they want, you have no value.


Imagine a parent raising a child by giving him all he wants. Such a parent will have no respect from his child. Worse: the child will probably end up very badly because he eats too much candies. And what about a doctor giving a patient all the meds he wants? Can we consider that professional?

What you want is not always what you need. Especially when you do not know enough to understand what are your needs.


As a professional developer, your job is to provide a solution to customer’s issues. To achieve that, you have to understand your customer’s needs. And it’s a hard thing because he will only insist on what he wants. The trick is, the vast majority of them need at least better software. So your job is at least to know what are the different possibilities to improve the software, and to apply the most relevant one for your customer.

So don’t bother too much with what the customer want. Understand his business enough to provide him what he needs. This is your job. This is how you can create value as a developer.

Customer needing software may not want unit testing and xDD stuff, but I never met one that does not need it.

Special thanks to NieveCharles Desneuf and Nadège Rouelle  


Agile is hard

Principles, values, concepts and practices. This is a good reminder of what agility truly is: core principles such as continuous improvement, supported by practices like daily stand up, continuous delivery and TDD.Agile550So why the hell do I see so much teams agile in principle, but absolutely not in practice?

Of course it could be for a lot of reason, but the main one I believe from my (short) experience is that we abuse Scrum and Kanban, which are mainly about management practices. We let people believe that agility in software development is only about index cards on a wall.

Worse: we let them think that be agile is an easy thing.

Apply Kanban practices, such as flow management and limit work in progress, is not really hard. Apply Scrum practices like daily stand up, retrospective and sprints could be a little harder. But still, this is nothing but some change in management practices.
It looks huge, but you can do it without changing your mindset. You can easily follow Scrum practices by creating successive little waterfall project instead of a big one (I agree, it is already an improvement).


Why are Scrum and Kanban so well accepted? I believe it’s because it can be understand by:
– Less detailed specification
– More deliveries
– The right to change your mind and priorities during the creation of the software

And yes, this is an easy thing to sell to managers.

A few months ago I have this discussion with a manager:
“Why do you ask the team to release every week, when you see that it takes half a day to package each release, and that we have regression each time?
– Because this is agility right? Deliver often!” 500px-HomerFacePalmThe only way I know to be agile in software development, is to be able to improve your code continuously. To do that, you need to be really confident about any change you do in your codebase, because you don’t want any regression. This is why unit testing, pair programming and TDD are so important.
By the way, these practices are first class citizen in XP, which is an agile method as well. But obviously, it is easier to sell Scrum than XP to managers.

TDD is a technical agile practice. Like continuous integration or pair programming. These practices will improve your life, as a developer, much more than daily stand up, you can trust me.
Thus, this is your responsibility as a professional developer to know and use these kind of practices, at least when you pretend to be agile. Actually it will improve your life even on a non-agile project, but this is another story.

And if you are an agile evangelist, please do not forget to learn and talk about these fundamental technical practices.


I realized a few weeks ago, reading the excellent Software Craftsmanship by Sandro Mancuso, that I am not the only one to feel this problem. What I did not understand before reading this book is that the whole Software Craftsmanship movement is partly born because of this lack of consideration for technical practices. Software Craftsmanship is, beside other things, the technical part of agile methods.

This probably explains why I feel so close of this movement since the very first time I heard about it.
Almost the same people that created the agile manifesto have been feeling the need for another manifesto, insisting on the importance of technical excellence.

As Sandro explains, all the successful software did not have an excellent codebase, but having a bad codebase is definitely one of the main reason for failure (and also for developers burnout by the way).

Yes, be agile means better client satisfaction with better product. And guess what? This is fucking hard to achieve! So you won’t be able to do it if you are not interested in the technical practices allowing to produce great software.


I know what you think: “I am interested but I do not know where to start!”
The good news is that Sandro Mancuso himself propose a public training in Lyon next 14th-15th september. Don’t miss the chance to learn with one of the leader of the Software Craftsmanship Community. Find it’s a bit expensive? Get a 40% discount with the code “I_WANT_TO_CRAFT” !


Thanks to Frédéric James for the kind review.


What’s legacy code?

Last saturday, I had the chance to facilitate a code retreat with Haikel Guémar and Charles Bouttaz. The subject was legacy code, and we tried to explain it with an unusual approach. Instead of the classic coding katas like gilded rose or ugly trivia, we decided to explore the very definition of legacy code, and the conditions under which it is created.


After all, legacy code is probably one of the things with the worst name in our industry. Chad Fowler gave an excellent talk on the subject.
I believe we call it “legacy code”, but we think, “awful code that I am afraid to change”. The literal definition of legacy code should be “code that I inherit from someone else”, but we don’t really speak of legacy code in that way.

A common definition is “code which runs in production”. But one of my favorite definition used to be from Michael Feathers: “Legacy code is code without tests”.

Thus, during this code retreat, we started by creating their own legacy code, following the Feathers definition. In the first iteration, we use the DNA kata, which is very close of fruit shop kata (but you manipulate string instead of integers). We added constraints like no unit testing, no pairing, and an incentive to create haste: a book for the first to complete the exercise (the book was, of course, Working Effectively With Legacy Code).

The following iterations started with the code produced in this first one, and we added other constraints like removing implicit dependencies, pair programming, unit testing etc. We observe different things during the retrospectives:

  • When working on your own code, you did not always feel the necessity to add tests, especially if you’re using a type safe functional language
  • When working in an unknown environment, or with unknown code (even if you knew what it should do),  you feel the necessity to add tests
  • Most of the time, even if we proposed new functionality to add after the first iteration, the whole iteration was spent paying down technical debt from the first iteration (refactoring with or without tests)

I think we can draw different conclusions from that.

The first is that it is easy to create an environment to write bad code: put pressure on people, short sighted vision, micro-management and working in isolation.

The second, and it was a word we heard a lot during the retrospectives, is that to produce good code, you need to be safe. You need to be in a safe environment, with safe code that you don’t fear breaking with each refactoring.


And I think this is a better definition :

Legacy Code is code you are afraid to change.

It could be because it is in production, and/or because it has no tests, the point is: you fear changing it. It will lead you to write more bad code with  lots of copy/paste and other common anti-patterns.

So, if you do not want to work on legacy code, start by producing code that you and your colleagues won’t be afraid to change. Yes, this is almost impossible without tests, so don’t take the risk, and write tested code.


Special thanks to Brian Gibson for the kind review


How I hacked my job

A few months ago, Florent Pellet invites me for a Brown Bag Lunch for CEGID about BDD. The presentation I did  was close of this one from the Lyon Human Talks.

After the presentation, I had this interesting and surprising question: “Well, that was nice, but how much is is to put it in practice?”
My answer was:”It costs nothing but the required energy to understand the method and to use the appropriate tool (SpecFlow in your case).
– Really? This is just a question of choice then?”

Exactly. This is the choice to work better. And this is what we endlessly repeat as software craftsman. Doing TDD, BDD, DDD, having build server and continuous integration, or even continuous deployment, in other words: work with serenity, it is a choice.
Corollary we can assert that work under pressure, be seen as a code monkey without any value to add, working 12h a day without the possibility to be proud of your product, it is also a choice.

And if I do this assertion today, it is because I started working in bad conditions as well, trying to convince myself that I had no other choice. You know TDD looks pretty cool, but it is clearly not possible “in real life”, because, after all, “it is different for us”. We had these impatient and unhappy customers, the short deadlines; we just have “no time for this”. We are doing real work!


And one day (the read of Clean Code acting as an electroshock for me), I understood that if I started to test my code, if I try to work in TDD, no one will come and stop me. Ok I tried to speak about it to my colleagues without success, but does it prevent me to do it on my own work? No. So I started to produce new tested modules. I learn about code legacy management, what’s the best architecture to use to test a Silverlight application. I quickly see the difference: tones of questions arise as I learn.

Of course, I often doubted, I even accept to develop a product for more than 6 months without any tests. (You know, the prototype was produced in a week, how could you imagine you’ll need 6 months to turn it in a professional product…And It was really dependent of a SDK, so it was pretty hard to test…Anyway, we always find some excuses). I still regret it. I quit my job a few months after this product was realesed. I choose that after that, I will only work on project with unit tests at least.

This is one of the main reason I started working as a freelance. I was tired to listen to managers explaining me that customers are not ready to “pay for tests”. And guess what? Now I earn more, I work less, I am more proud of my work, and I learn more in 1 year and 6 months than in the previous 3 years.

But how could you enter in this virtuous circle of continuous improvement? As a developper, I can suggest two starting points:
– Do some technological surveillance via twitter, blogs, conferences, formation, User Group… To know how to test your code
– Then, test your code


From that point, everything will run smoothly. To have good tests, you will learn to write better code. When your code will be better, you will learn to improve your tests.
When both will be in an acceptable level, you will think about a better software factory (build server, continuous integration, continuous deployment…).
Then you will be able to make your team more productive, because you won’t be slow down by little technical details day after day. You will improve yourself by spending more time to learn. In the end, your customer will thank you instead of be feared for each new version of the product.
As the pressure from your customers will go down, you will have more time to improve your code…And so on.

I you do not like your way to work, hack your job, change your method, learn to be better, change of company if this is the only solution!

Don’t panic, just hack your job.