The gist of the book is, for me, captured in the following quotes:

• You can’t take pride and honor in something that you can’t be held accountable for
• QA should find nothing
• The true professional knows that delivering function at the expense of structure is a fool’s errand.
• Woe to the software developer who entrusts his career to his employer.
• Professionals speak truth to power. Professionals have the courage to say no to their managers.

Those who don’t suffer that much from poor team or software will not benefit that much from The Clean Coder, but there are a few gems in for them as well. I found the argument against flow (or “The Zone”) particularly interesting, as I’ve never looked at the topic in the way described in the book. References to probability based estimation were also interesting, as well as explanations of some more exotic time management strategies. Most importantly, through many interesting war stories, we as readers get to peek into Uncle Bob’s experience and learn from his mistakes.

If I was picky and had to choose a few negative things to say, I’d probably point out the start of the book as unnecessarily off-putting and negative. It paints a picture with a clear adversarial relationship between programmers and management or clients, which doesn’t really match my background or current situation. Sure there have been a few bad apples in my project basket, but the picture painted was a bit too negative for my taste. On the other hand, people who need to hear the message of this book will probably identify with that dark painting of their reality. I’ve also never been good at reading books with lots of invented dialogue, something in my reading circuits makes me skip invented conversations. This made it hard to follow the flow of thoughts in some parts of the book but it has more to do with my attention deficit and reading skills than the book itself.

So to conclude, this book is not going to replace the Pragmatic Programmer as my favourite “you have to read this first” suggestion to new members of our profession, but it deserves to be on that list.

The major themes in the book are curing from “excusits”, building confidence, getting into the action habit and using goals to help grow. As far as self-help psychology books go, this one is relatively interesting. It was recommended to me as “amazing” and “life-changing” but I wouldn’t go as far as calling it that. Actually, I did not read any revolutionary new ideas but it reminded me of some thoughts and attitudes I once had but lost for mysterious reasons. After being re-Gojkod, it was well worth the few pounds I paid for it.

The idea of “excusitis” really resonated with me as I still think that “provide options, not excuses” from Pragmatic Programmers is the best work related advice I’ve ever got, and it brought me much money and joy since I read that book over 10 years ago.

Another interesting idea is creating a weekly improvement programme, which the author attributes to an anonymous store owner with a stellar success. She explained it as collecting notes on how she can improve her business during the week, and then spending four hours to review those ideas every Monday evening. During the review, she identifies solid ideas and thinks about how to put them to business.

The third idea that stuck with me is “It’s very refreshing to mix with people who do something else for a living”. As a result, I decided to attend some non-software conferences this year.

The fourth interesting idea is a three-step procedure for generating enthusiasm about a topic: Dig Into It Deeper (learn more about it), Live it Up (do a good job, ensure that you are doing the most you can) and Broadcast Good News (let people know when they have done a good job, not just when they screw up).

The book has lots of other uplifting thoughts, unfortunately backed by mostly by anonymous anecdotal evidence (eg “a little over two years ago a young man asked me to help him…”). It often sounds silly. I like the message, but I’d love more serious explanations and better case studies. It also contains lots of (seemingly good) career advice aimed at people working for large companies that don’t really apply to me. As the first edition was published quite a while ago, it is also funny to read in places. For example, it lists examples where someone was earning $25 a week, or categorises highly successful people as the ones who earn more than $15000 yearly.

The book is full of great quotes. Here are my favourites:

• Thoughts, positive or negative, grow stronger when fertilized with constant repetition
• It’s better to wear out than rust out
• Stickability is 95% of ability
• Knowledge is power only when put to use
• Action cures fear. Indecision, postponement, on the other hand fertilize fear.
• Use Action to cure fear and gain confidence.
• Waiting even makes the experts nervous.
• “Motions are the precursors of emotions” – attributed to George W. Crane
• When you believe, your mind finds ways to do
• Eliminate the word impossible from your thinking and speaking vocabularies. Impossible is a failure word
• “Man belongs where man wants to go”, attributed to Wernher von Braun.
• “There are many ways in which a good job can be done – as many ways in fact as there are men to whom the task is given”- attributed to Crawford H. Greenewalt
• It isn’t so much what you know when you start that matters. It’s what you learn and put to use after you open your doors that counts most.
• Progress is our most important product (slogan of General Electric at the time when the book was written).
• People who tell you it cannot be done almost always are unsuccessful people, are strictly average or mediocre at best in terms of accomplishment. Opinions of these people can be poison.
• Go First Class when you have questions.
• (on buying expensive advice or services) “but I can’t afford to go first class”. The simplest answer is: you cannot afford to go any other way.
• [in adverts] “these headlines in effect tell people: buy this product and you put yourself in an important class”
• People do more for you when you make them feel important.
• The seed of money is service. That’s why “put service first” is an attitude which creates wealth. Put service first and the money takes care of itself.
• Always give people more than they expect to get
• A goal is more than a dream. A goal is a dream acted upon.
• You are not pulled to high levels of success. Rather you are lifted there by those working beside and below you.

A: A Four-Hour Work Week

I’ve been ranting about a book with that title long enough that I really have to publish a blog review. The Four Hour Work Week by Tim Ferriss is sort of a manifesto for a mobile life style. The author describes his journey from a small company owner who was in reality owned by the company to a globetrotting, cage-fighting, tango-record-winning, break-dancing company owner who spends four hours a week working (hence the name) to sustain such a lifestyle. It made me think seriously about my work, life and everything. (I’ll skip the universe to avoid a worn-out quote. Anyway, the book does not really have to say anything about astronomy).

And no, you won’t see me on MTV in Taiwan next week trying my latest break-dancing moves. This is not why this book was interesting to me. As a firm believer in modern software value-driven processes, it was fascinating to read about someone taking all those great ideas we apply to design software that matters and apply that to design a company and ultimately a lifestyle. Ferriss’ journey to his four hours per week is essentially a story about thinking really hard about value chains, finding the elusive core domain and focusing exclusively on that, outsourcing, delegating and automating the rest. Unsurprisingly, this has allowed him to increase his personal financial productivity while significantly reducing the amount of work he does.

Ferriss’ plan revolves around four ideas summarised by the acronym DEAL:

• Definition – What is it that really brings in the money? Is that the right thing? What is just stuff that doesn’t really contribute? What’s not core?
• Elimination – kill distractions and low-value work
• Automation – automate critical low-value work, outsource what can’t be automated
• Liberation – do whatever you always wanted to do with the spare time

The main argument of the book is that by following the ideas other people can significantly increase their effectiveness as well and then decide what to do with the remaining time, for example travel the world. My problem with this is that I love what I do, so reducing the amount of time I work is not necessarily my goal. So I don’t intend on flying over to east Asia to become a cage fighter, but the book made me think about spotting and reducing non-core low-value work I do personally. For example, I’ve taken the advice to hire a virtual PA to help with all the bureaucracy of running a small consultancy and I’m looking at outsourcing some other non-core work to other people, such as organising travel plans. I’ve also started looking seriously at information overload and the way it effects my productivity. I’ve turned off all e-mail alerts and started batching such work instead of letting it interrupt me.

Ferriss gives lots of examples of people following similar paths to design their own lifestyle and work, from employees of big companies to business owners. The book is quite dogmatic, presenting decisions without really explaining why they are right or trying to take a critical view at them, but it is fun to read. It is filled with interesting stories, motivational quotes and lots of references for further research into different options for automation and outsourcing of non-core work.

Here are some of my favourite quotes and ideas from the book:

• “If a recipe sucks, it doesn’t matter how good a cook you are.”
• When dealing with something unknown, look up the biggest experts and send them e-mails, chances are they will reply (Ferriss used that approach to get his book published and offers several other examples of that)
• “meetings are an addictive, highly self-indulgent activity that corporations and other organisations habitually engage in only because they cannot actually masturbate” – attributed to Dave Barry
• “Don’t suffer fools or you’ll become one”
• “Set the rules in your favour: limit access to your time, force people to define their requests before spending time with them, and batch routine menial tasks to prevent postponement of more important projects.”
• “The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency” – attributed to Bill Gates.

So far, this is my favourite personal productivity book and it deserves to be read by anyone in software development as much as something like The Pragmatic Programmer.

Developers prefer to talk in terms of value generation without developing related revenue projections. Business stakeholders usually don’t realize that delivery sequences and architectural options have a significant impact on project level ROI. Clearly, software development requires a more financially responsible approach […]. This situation clearly calls for a close collaboration between developers and business stakeholders.

The previous paragraph pretty much sums up the basic idea of Software by Numbers: Low-Risk, High-Return Development by Mark Denne and Jane Cleland-Huang. Iterative delivery and fast roll-out to production makes perfect sense and I do not think that anyone can doubt that, but can you actually put a value on it? Can you compare two alternative delivery plans for the same project? Denne and Cleland-Huang set to do exactly that. By developing a financial model to evaluate and compare delivery plans, the authors show how to make an informed decision about prioritisation on a project so that it maximises the desired financial effect, either reducing risk, optimising cash-flow or return on investment.

Denne and Cleland-Huang explain how to identify and evaluate the financial impact of Minimum Marketable Features, including “intanglibles” such as brand value or customer retention. Then they develop a system of heuristics that combines this information with technical and architectural constraints, prerequisites and timing constraints to come up with the best possible delivery plan, depending on what you want to achieve. Through several case studies, they show how just choosing the next most important thing isn’t as nearly as effective as considering the financial impact of the entire delivery plan. Somewhere in the middle, they also come up with a way to estimate the financial impact of the project by forces other than black magic which helps us answer a key question: should we do this at all or should we do something else?

Effect Managing It, by Mijo Balic and Ingrid Ottersten, deals with things that happen even earlier in the process – coming up with a list of features to achieve the desired business effect. Instead of focusing on functionality, Balic and Ottersten look at software projects as agents of business transformation. The authors argue that the ultimate goal of software projects is to achieve a business change, and that one of the key reasons for failure of so many projects is that the focus is often on the wrong things. They explain a model of structuring requirements analysis in a way that ensures achieving the desired business effect. That focus on business impact, not functionality or technology, is what they call “Effect Managing”.

Effect Managing shares many key ideas with behaviour-driven development and agile acceptance testing, but deals with things that are much earlier in the development cycle. Balic and Ottersten base their model on first considering who can deliver the desired change (stakeholders in the BDD lingo), then thinking about how these people can deliver it and what the software needs to do to support that that. Organising all these ideas in a hierarchy which they call an “Effect Map”, this model provides visibility similar to the Goals-Features-Requirements model, but in my opinion much more effective because it is visual. After trying out effect maps on two projects, I’m astonished how they open up a discussion and provide structure to the process of selecting the features for a project and probably equally important throwing away features that are less important.

Be warned, though, that both books are relatively hard to read. Although they are short, less than 200 pages each, the flow of ideas in both books is a bit hard to follow. Effect Managing IT at times reads like a literal translation (from what I understand, the original book was written in Swedish) and Software by Numbers is full of financial tables and formulas. Nevertheless, I think that both books have such great value that getting through them is well worth it.

Given the authors’ backgrounds, it’s not surprising that this book has a lot to say about using mock object libraries. Mock objects are arguably the most misunderstood and misused concept in software development today, so this book should be a valuable resource for most software development teams. In the part dealing with mock objects you will find strategies for using them successfully for software design, guidelines what to mock and what not to mock and lots of examples how all that looks in code.

The book isn’t written in the usual imperative way (“you should use this because of…”) but reads much more as an experience report (“we use this because of”). This might be unusual at first but I really like it, as it puts the things into a much more different perspective. Many of the topics addressed by this book are quite controversial and the authors have wisely chosen the voice to avoid any notion of preaching. I found myself disagreeing with parts, especially around bundling acceptance and end-to-end testing together. However, as the material doesn’t preach but tell what the authors are thinking about, this did not bother me at all.

All in all, an excellent book. Grab a copy from Amazon now.

Here are some related links:

• notes from Steve Freeman’s presentation on mock objects at CITCON Europe 09
• book web site
• Steve Freeman’s blog
• Nat Pryce’s blog