Mathieu Gueydan

Here are 6 mottoes I believe in :
- First : Make it work. Then : Refactor - Anonymous
- To lead people, walk behind them - 老子
- Inherit, not to reuse, but to be reused - Sutter / Alexandrescu
- Quality is not an act, it is a habit - Aristotle
- Why programm by hand in five days what you can spend five years of your life automating - Terence Parr
- Cease dependence on mass inspection to achieve quality - W.E. Deming

Collecting them has been proven to be very useful. It allows me to display clear messages to my bosses, customers, co-workers... I use to write them on walls or whiteboards in my workspace and even printed them on my business cards

I'm not sure I'm smart enough to say something new and useful on Sutter's and Alexandrescu's work or on Lǎo zǐ's thinking, but what I will try to do in this post is to explain what's hidden behind the very first one :

First : make it work. Then : refactor

Basically, this is a procedure on how to build something new, especially software.

Let's look what one may want to do, when before build something new (a new feature, a new product...):

1. spend a lot of time thinking about what should be done and then writing specifications. These thinkings and specifications of course include technical details like configuration files, protocols used etc.

2. spend a lot of time building everything that will be used by the application. Among them: environment, unitary-tests, nice object model, tools and components like loggers, rpc ...

Of course you want all of theses. Going on without any unitary test or without a good logger is a waste of time. Everybody knows it. I know it.

What this motto means, is that before all of this, you want to do a PoC. A fast-coded prototype that will demonstrate the main feature of your software, and only the main feature. And you want your customer to have this in hands very early.

There are at least 3 reasons why you want this are :

1. Because you're not sure of the feasibility of what you want to do. Most of the time, even after a very careful thinking and a nice specification, coding it make new issues appear you was not able to anticipate.

2. Because you want to provide something concrete to your user/customer. Your user/customer will have something to focus on very early. Every discussion that takes places after that may be done with concrete demonstrations. It drastically reduce the customer/coder misunderstandings.

3. Because it make you shine. When your competitors need 2 weeks to provide something, you will come back to your client in 2 days. Of course, in the end you may not be faster. But what will stay in mind is that you came back with something in 2 days.


I don't spend too much words on the second part : "Then refactor", it's pretty obvious. You wrote some bad-code in order to provide a PoC. You don't want this code to stay in your final application. You need refactoring.