Interview avec Robert Martin

Robert Martin : Software Craftsmanship means to do Software well. There is really little more to it than that. It is a discipline for doing the best job you can. In the US, a craftsman is someone who is very well respected and knows his job inside out. For example a surgeon, a lawyer or an engineer would be a craftsman. Someone who is extremely well known and paid a lot of money for his skill is a master craftsman. You could easily employ another word to mean craftsmanship so long as it had a connotation of expertise. In detail, software craftsmanship is a set of values and disciplines around writing the best code we can in the shortest possible time. It’s about writing code that is easy to change, easy to modify, that is well tested, that is something that we can all be very proud of.

Robert Martin : Software craftsmanship has always been a part of agile. When agile was first born in 2001, at the agile conference, the goal was to produce the best code possible and with optimal communication with the business side. The communication with business part was turned into SCRUM and the first part got lost. The Scrum movement has been very popular but it has not taken with it the original technical practices that we thought were essential back in 2001 at the Agile conference. So a few of us have created this software craftsmanship movement as a way of reintroducing these technical values and technical practices into agile. Is it related to Extreme programming? Sort of. Some of the practices are similar but I wouldn’t call software craftsmanship Extreme programming. Some of the practices are there. We certainly think that pair programming is important although we don’t demand it 100% of the time. We certainly think Test driven development is important as well as continuous integration or simple design. The core values of extreme programming are still part of software craftsmanship.

Robert Martin : It’s not. Everyone knows that testing is vital. What they don’t understand is that automated testing is vital. Nobody would ship code without trying it. All companies believe that testing is important and they spend enormous amounts of money doing testing. They will hire batches of testers. They will spend hideous amounts of money every 6 weeks or every six months to run though the manual test plan. The amount of money spent on testing is huge. My goal is to convince everybody is that it doesn’t have to cost that much money. I want to show that the automation of test is actually much cheaper, much more reliable than the manual operation of tests. My goal is to spend less time and money on tests by automating them. Now that does mean that programmers will have to be involved, that programmers will have to write automated tests but that’s a very fair trade off. There is something else. Is the dirty little secret behind the whole testing thing. Why have businesses created testing groups? The reason they have created these testing groups is that they had to defend themselves against developers that were releasing code that didn’t work. It seemed only natural that you would then get other people to test the code. The reality is that developers already had that responsibility. They were the ones that should have released a code that worked. They have shirked that responsibility. I want to reintroduce it. Developers should never release code unless they know it works. It should be considered the height of unprofessionalism to release code without knowing if it works. The only way to know that it works is to implement automated tests. Given those ideas, I don’t think it’s a difficult thing to convince anybody that testing is a good idea. Automated testing would save a heck of a lot of money.

Robert Martin : And test driven development sounds like extra work. Their reaction is: “well it’s even more code and I’m already going as fast as I can and I’m already under too much pressure and this is even more work for me to do…”. That the reaction. It’s wrong. By writing those tests you will work faster, you will do less work, you will shrink the amount of time debugging dramatically. It will be much easier to change and modify your code. You will get a much better outcome but that’s a hard thing to convince a developer of, especially a developer who already feels like they are treated unfairly. They already feel that too much is expected of them than they can deliver and that if they are slowed down by anything, they will get in a lot of trouble. So anything that they fear might slow them down, they are just not going to try. The job that I have is to convince developers that they will go a lot fast if they do the tests. They will get things done a lot faster.

Robert Martin : Of course! Software craftsmanship is about writing code well and most of those principles still apply, even in C. It might be difficult to do the Liskov substitution principle since that one is pretty much related to inheritance but the single responsibility principle, that’s been around for a very long time. Even the open-closed principle which says that a module should be open for extension but closed for modification is something that we were going in Unix with Unix drivers in the 70s long before there was Object orientated code. So those principles are pretty general. The solid principles are worded in an Object orientated context but if you look at them closely you will see that most of them are fine even in a non OO language. Now the question is obviously: Why would you be using a non OO language. In this day and age, this doesn’t make a lot of sense.

Robert Martin : There is a statement of values that was put on the software craftsmanship manifesto which can be found at manifesto.softwarecraftsmanship.org. You can find the values there and see how they relate to the agile values. A list of disciplines? Well there are a number of books that talk about writing code well. Kent Beck wrote a book called “Implementation Patterns” very recently. It’s an excellent book all about software craftsmanship. The pragmatic programmers wrote a wonderful book in 2000 called “The pragmatic programmer”, again a wonderful book. Chad Fowler wrote a book call the “Passionate Programmer”. Again the book is about doing everything well. I wrote a book recently called “Clean Code” which is very specific about particular things you can do with your code to do it well. So there is a tremendous number of resources that are available for people who are interested in doing software craftsmanship well.

Robert Martin : Yes absolutely!

Robert Martin : Your first question is an interesting one. Is software craftsmanship an excuse for coding in when you’re older? I think it is a way for older programmers to try and communicate values and skills to younger programmers. This is a huge problem we have in our industry because we hire people out of school and we assume that school has taught them how to program. But school has not. Most of the schools don’t teach that. They teach basic science and algorithms and data structures…but the Craft, the skill of writing software is something that’s developed over years. What we don’t do well is to take these younger people and mentor them. A large part of software craftsmanship is this notion that younger people ought to be apprentices first before becoming well respected and eventually masters. If we don’t do that as an industry then we continue to lose that knowledge.
Now about modeling and architecture. Model driven architecture is a wonderful idea, a grand idea that has never worked and probably never will. The idea is that we can elevate the language we are using to a higher level of abstraction. Maybe we could write our programs in UML and not in code. And maybe we wouldn’t need so many programmers. We could have architects draw models and somehow those models would execute. It is a grand idea but it has never worked generally. There are specific cases when people have made systems work that way but there has never been a general solution that works for everyone and I don’t think there can be. The reason for that is that program is all about detail, huge amounts of detail. To describe that detail requires a language that is detailed and a language that is detailed enough to describe a website or a very complex system is not going to be in UML. It will have to be a richer language with more facilities in it. It won’t be in a higher level of abstraction. Frankly I think the languages we’ve got are the level of abstraction for programmers. I don’t think there is a higher level. I think we’ve reached it. We have gotten out of the roman numerals of assembly languages to the Arabic notation of Arabic that everybody uses. There may be better ways of working or more interesting structures but I don’t think it will ever be model driven architecture, at least not the way it’s currently conceived.

Robert Martin : Imagine the absurdity of that idea, ie; programming is a low level, unskilled profession and that nobody should be a programmer for too long because one needs to move on to better things like management ect. We have created a situation where the priority of every programmer is to not stay a programmer. That is absurd because our civilization depends on software. If we don’t have software and people writing the software well, our civilization stops, our businesses stop. Think of your business. How much does it depend upon software? It’s inconceivable that you could get you business to work without it anymore. We don’t pay enough attention to this. This is a critical bit of our social infrastructure. This software is the lifeblood of most companies; it is the lifeblood of most countries. We should be looking at this very differently and people who touch that software had better be skilled. They should be seen as air traffic controllers who hold their jobs for a while and are well respected…pilotes who learn over a long period of time how to control a plane so that eventually they can be trusted with a 747 full of 300 people. These are the kind of position we should be looking at for programmers. Think of the damage that could be, and has been, done by a young programmer who makes a stupid mistake that a senior programmer wouldn’t with a cost for the company running into the many thousands, even millions. We are not paying the right attention to that.

Robert Martin :We have to do what the medical profession did 200 years ago. 200 years ago, anybody could be a doctor. They would simply come out and say “I’m a doctor”. There were no standards or rules. If you damaged someone because you didn’t know what you were doing, you just moved to another city and started all over. At some point, the medical profession started developing standards, training programs and a whole bunch of tests before one could call himself a doctor. We need to do that with software. It may not be as elaborate as the medical profession but I think it would be wise for us to come up with a training program, an apprentice model, and create a way for programmers to enter a company and not do any damage. Imagine young pilots flying their first 747, wouldn’t it be nice having someone sitting next to them able to take the controls if something went wrong. I think we need that in the software profession as well. We need some way of doing internship and graduating them to more senior positions.

Robert Martin : I am working on 2 projects at the moment. One of them is fitness, which I maintain. I spend, depending on the period, a week per month working on that. I’m also working on the clean coders website. This is the website that distributes my video programs. Lately, I’ve been spending a bit of time on that as well. I also fly around the world and give lecture and talks and although, my fingers are on the keyboard a lot, I don’t count that as programming. So in total a little more than a week per month.

Robert Martin : Yes, it should be coming out at the end of May. It’s called the “Clean Coder”. It is, in some sense, the sequel to the last book I wrote which is called “Clean code”. This book is all about the programmer and not about the program. How should a programmer behave? What does it mean to be a programmer? The book has no code. Instead it talks explains when programmers should say yes or when programmers should say no. It explains how to deal with pressure, how to make commitments, how not to make commitments, how to write code well after a big fight with your wife. These are the kind of topics I talk about. In the midst of the book, I tell of a lot of stories of my own long colored history. I talk about the times I got hired and the times I got fired, the times I failed horribly and some of my successes as well. I discuss at length all that I did wrong and what I learned about that. In some sense the book is autobiographical. I’ve also come up with some principles to help people avoid the mistakes I made.