Agile Management | NOOP.NL

Join the CLUB (Coding Like Uncle Bob)

Today I thought of a solution to the wide-spread problem of programmers writing crappy code and causing problems with the delivery of low-quality software.

I call it joining the CLUB.

Here's how it works:

1. Get yourself a copy of the book Clean Code, by Robert C. Martin;
2. Read it and learn how to write clean, elegant, high-quality code;
3. Tell everyone that from now on you will be Coding Like Unce Bob;
4. Then choose one of the following two options:
5. a. Buy a new copy of the book for a friend or a colleague;
   b. Or give your copy to a friend or a colleague
   (Note: don't lend him your copy! Buy it, or give it!)
6. Make your friend/colleague promise to do exactly the same (starting with bullet point 1);
   (If your friend/colleague won't read it, take the book back, and give it to someone else.)
7. If you have a little cash to spare, do the same thing again with a second friend/colleague.

If all works well (and depending on the percentage of people able to give away two books), then in a matter of just a few years, all programmers on this planet will be Coding Like Uncle Bob! And all the problems of shitty software will go away. At last. The world will be a better place. (And because users won't be so frustrated anymore, there might even be world peace...)

It doesn't happen that often that I am enthusiastic about a book. But when it happens, I want to tell everyone all about it. Clean Code, by Robert C. Martin (aka Uncle Bob), is the most useful book I've read in a long while. It's full of great advice on formatting, naming, comments, functions, classes, error handling, concurrency, unit tests, and much more. It also has plenty of interesting acronyms like DIP (Dependency Inversion Principle), IoC (Inversion of Control), DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), SOLID, FIRST, TDD, and many more.

This is the book that new software developers should be required to read, before pushing their first lines of code into production.

One of the principles Bob Martin described is the Boy Scout Rule:

Leave the campground cleaner than you found it!

In software development this translates to:

We should all check-in our code a little cleaner than when we checked it out.

And we can translate this principle to global proportions:

Each of us must increase the number of people Coding Like Uncle Bob with at least one.

So, I bought Clean Code and I'm loving it.

I'm finally learning how to write good code.

From now on I will be Coding Like Uncle Bob.

I'm going to buy the book for another programmer.

I will see to it that he reads it and joins the CLUB as well.

And I might even do that twice.

A better world, with fewer crappy systems, has to start somewhere. So why not try and let it start here and now?

(image by karpov the wrecked train)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
People Don't Listen
To See Is to Follow
The Decline and Fall of Agilists

Joel on Software: Book(s) Review

WARNING! This is an experiment!

I have been asked to do a book review on two books by Joel Spolsky: Joel on Software and More Joel on Software.

However, given the fact that anyone can just go to Amazon.com and read lots of reviews over there, I tried to think of a way to make my book review a bit more original.

This is how it turned out...

I should warn you that this is a straight recording, with no post-editing, dubbing, special effects or whatever. After a lot of testing (and cursing) I was glad enough to simply have the recording part working properly. And after that much time, I didn't care that much about the details anymore. Therefore, all errors and ugly bits are exclusively mine.

So, what do you think?

Would this be an interesting format for other book reviews as well?

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
How to Handle Many Simultaneous Projects
Top 100 Blogs for Development Managers (Q3 2008)
Professionalism = Knowledge First, Experience Last

Book Review: User Stories Applied

The concept of writing user stories, as a way of documenting requirements, was introduced and popularized with Extreme Programming, and then picked up by Scrum and several other agile methods. Nowadays, for many agile developers, a project without user stories would be like a world without pizza. Impossible to imagine.

User Stories Applied
The book User Stories Applied, published in 2004 by Mike Cohn, is a landmark publication that has brought together everything the agile movement has learned about this important subject. Mike's book deals with all the activities that people have to perform when writing user stories, like techniques for requirements gathering, defining roles, working with user proxies, and preparing for acceptance testing. Mike also clearly explains how user stories can play a pivotal role in the wider agile project management processes of estimating, planning and monitoring.

Healthy Opinions Applied
User Stories Applied also contains information on difficult and controversial issues, like how user stories relate to user interfaces, nonfunctional requirements, use cases, user scenarios, IEEE 830-style requirements and the horror of the Happy Meal Pizza. OK, I lied about that last one. But it's nice to see that Mike doesn't shy away from some sensitive subjects, offering healthy and strong opinions for his readers.

It seems to me that reading User Stories Applied is simply the best and easiest way to familiarize yourself with user stories. Just about everything I found on the Internet about this topic is neatly covered in Mike's book. It is well written and complete. And best of all, it's easy to finish in just a couple of evenings. Either with or without a pizza.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
Book Review: The Systems Bible
Book Review: Fish!
Book Review: Agile Project Management with Scrum

Alistair Cockburn's Latest Presentation

I recently attended a presentation by Alistair Cockburn, one of the 17 signatories of the Agile Manifesto. The presentation was superb, as could be expected. Even though many ideas had already been presented earlier in Alistair's books, he also shared some interesting new concepts and insights with his audience. The entire presentation has 75 slides, and you can download it here (9MB).

Let me show you some examples of what you can expect to find in this presentation...

Try making videos of people talking with each other, instead of making paper documents.

Use the Shu-Ha-Ri model to determine people's skills in adoption of new techniques.

Bottlenecks in an organization will depend on the way you've set up your teams.

The Declaration of InterDependence is a relatively new appendix to the Agile Manifesto.

After the presentation I was able to exchange a couple of words with Alistair. I thanked him for his valuable feedback on two of my articles that were published in some magazines. However, it appeared that my presence was overshadowed by several trays of hot snacks that mr. Cockburn was hungrily trying to chase. After giving such a long and inspiring talk I could hardly blame him.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
Don't Trust Your Backups
Architects vs. Agilists (1 - 1)
The Agile Blind Spot

Book Review: The Systems Bible

I just read the first part of a very interesting little book called The Systems Bible: The Beginner's Guide to Systems Large and Small, by John Gall. Software Engineering guru Jim Highsmith wrote that it is one of his personal favorites, and I can easily understand why.

The book is full of scientific insights, wisdom, irony and humor. Here's a small number of the many theorems, axioms, laws and principles collected in this little gem:

The Big-Bang Theorem of Systems Cosmology
Systems Tend to Expand to Fill the Known Universe

Le Chatelier's Principle
Systems Tend to Oppose Their Own Proper Functions

Operational Fallacy
The System Itself Does Not Do What It Says It Is Doing

Rohe's Theorem
Designers of Systems Tend to Design Ways for Themselves to Bypass the System

Newtonian Law of Inertia
The System Continues to Do Its Thing, Regardless of Circumstances

Axiom
Systems Don't Work for You or Me, They Work for Their Own Goals

Fundamental Failure Theorem
A System Can Fail in an Infinite Number of Ways

Fail-Safe Theorem
When a Fail-Safe System Fails, It Fails by Failing to Fail Safe

Basic Information Theorem
Information Decays (or Knowledge Does Not Keep Any Better Than Fish)

Agnes Allen's Law
Almost Anything is Easier to Get Into Than Get Out Of

Systems Law of Gravity
Systems Run Best When Designed to Run Downhill

Second Law of Systems Survival
In Order to Remain Unchanged, the System Must Change

Everything you read in The Systems Bible applies to all kinds of systems, whether computer systems, biological systems, economic systems or political systems. In fact, the book is so packed with systemantics (and jokes) that my own mental system quickly overloaded. I had to put it aside for a while, and I will try to absorb the rest later, at a slower pace.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
Book Review: Fish!
Book Review: Agile Project Management with Scrum
Book Review: Agile Management for Software Engineering

Book Review: Fish!

I just finished reading a little book called Fish!. It's subtitle is "A Remarkable Way to Boost Morale and Improve Results". I'm always interested in management literature, and with a size of only 107 small pages, this booklet was simply too hard to ignore. There are quite a number of publications on the Top 100 list of Software Engineering Books that (more-or-less) deal with the same subject: how to improve job satisfaction (among software developers and other team members), and how to improve the quality of software delivered to customers.

Well, this is what Fish! has to say about it:

Choose Your Attitude
No matter what kind of work you do, your attitude towards it is your own choice. When you are working on some stupid project you have two choices: You can choose to be bored while doing mundane maintenance work on a 100-year old legacy application. Or... you can choose to become a World Famous Legacy Maintenance Superstar. Your attitude towards your project is your own choice.

Play
According to the book some people on a fish market had fun by throwing around the fish, and customers loved to watch. But everyone can choose to have a little fun while doing their job. Share positive energy with your co-workers, in a professional way, to make the work more enjoyable for everyone involved. Make the team that introduced the most bugs wear pink shirts for a week; have a monthly contest for the most beautiful single line of code; or steal the CIO's business cards and use them for writing user stories.

Make Their Day
Engage your customers in your positive energy and goodwill. Make their day by letting them share in some of the fun. Don't make fun of customers, have some fun with the customers! Make good on a bad release by sending your customer a picture of the team in pink shirts; let your users vote for the coolest feature ever devised; or ask them to contribute to your collection by giving you their CIO's business cards.

Be Present
Make sure that you actually notice your customers and your co-workers. Be there for people by asking them what they need and how you might be able to help. Don't wait for someone else to approach you with a question. Be the one that actively seeks out what needs to be done, and really listen to what people have to say.

These four principles are the core of Fish! (or at least my interpretation of it). Though the book is often described as a management book, the actual target audience is the team, not the manager. The team members are the ones to throw around the fish, and make the customers laugh.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
Book Review: Agile Project Management with Scrum
Book Review: Agile Management for Software Engineering
People Don't Read

Book Review: Agile Project Management with Scrum

Jurgen! What's your opinion on Scrum books?

For many agile practitioners, particularly the ScrumMasters among us, books by Ken Schwaber are a must-read. I can explain, using a wide range of both original and lame excuses, why I still hadn't read Agile Project Management with Scrum.

But I won't. Let me just tell you how this book compares to all those other agile books out there. There are plenty of alternatives to choose from (by Cockburn, Highsmith, Anderson, Coplien, Poppendieck, Larman, Beck, Fowler, to name just a few...) so it's interesting to see what Ken's unique contribution is to this crowded field...

1. The book is very rich in case studies, and I think this is the best reason for reading it: there's a lot we can learn from real-life examples. Theory is always important, of course. But sometimes it's even more important to see where theory has failed in practice, and how Ken has managed to solve some problems in ways you won't find in the standard Scrum process descriptions.
2. The book is poor in details on best practices. Ken does not elaborate much on daily stand-ups. He doesn't evaluate different types of burn charts and task boards. He doesn't explain how Scrum compares with (or differs from) XP or any of the other agile methods. But that's not the point of this book. There are plenty of other sources where you can get that information from. This book is about implementing Scrum, and it has lots of stories about the problems Ken has had to overcome. In that area the book is quite unique.
3. Ken Schwaber makes a number of references to the science of complexity. Scrum has its roots in self-organization, emergence, and other principles of complex systems. It's my favorite subject, so I was quite pleased with the explicit mention of complexity science. (The only other author I've seen making similar connections is Jim Highsmith.) It's a pity Ken's elaborations on this subject were only superficial. But who knows... he might have left that topic for me to explore!
4. The cover is horrible. I really don't see what a bunch of lines, circles and cubes have to do with Scrum. It's one of those rare books that looks best when only the spine is visible. I honestly hope someone was fired for delivering such a crappy cover.

If you want to know more about implementing Scrum in various organizations, read this book! But if you want lots of information about many agile practices, read something else.

Agreed? Not? Let me know!

Book Review: Agile Management for Software Engineering

I have finished reading Agile Management for Software Engineering, a book by David J. Anderson, and I am very impressed. Granted, the book is already four years old (I'm a little behind with my reading) but it's still relevant. It is the first book I've read that tries to back up the agile approach with solid theory. In this book David uses the Theory of Constraints to explain why lean/agile project life cycles lead to success, and a higher return on investment (ROI), more often than traditional life cycles. He also presents an interesting in-depth analysis of Scrum vs. XP vs. FDD.

However, since I am Dutch, you can usually expect me to have found something to complain about (or disagree with). And, being the considerate person that I am, I would never try to disappoint you. So, here are my three gripes:

1. David doesn't hide the fact that he has a preference for Feature-Driven Development (FDD). After all, he has been practicing it for many years. And I have no trouble with that, except that I felt he was favoring FDD a little too often with some of his analysis. Whatever the subject, and whatever his reasoning, FDD always seemed to come out on top. It seemed as if an Italian was trying to prove that Rome is the greatest city in the world. (Which it isn't. It's London.) Though I could not bother myself to find any specific flaws in David's logic, I did find it a bit suspicious.
2. Another thing that annoyed me was his view on the complexity of software projects. At one time David admits that software projects are nonlinear (and therefore complex) by nature, while on other pages David tries to convince his readers that his linear estimation technique (involving feature lists) has produced accurate results for years. I think this is a contradiction. You cannot have an accurate linear estimation technique for a nonlinear phenomenon. It's like estimating the noise Italians will make on a bus by counting the number of Italians. (Everybody knows the correlation is exponential.)
3. However, the worst thing about the book is that it wasn't funny. It does not contain any jokes. You might find this strange, but I always need a bit of lightness to help me through the tough parts in a book. Unfortunately, there was not one little bit of silliness to help me crawl through 300 of pages of dry theory. David made me feel I was back on the university; the only difference being that David's formulas weren't hand-scribbled in illegible writing and photocopied with a twenty year old copier. I think, after having reached the last page of the book, I let out such a big sigh of relief that I must have left my neighbors wondering.

Nevertheless, if you're looking for a book that does more than simply saying "Agile is great, and traditional methods stink!" then I suggest you give it a try. The book is solid and important. Go buy it!

Death March

I just finished reading Death March (Second Edition), by Edward Yourdon. I liked the fact that it referred to Dynamical Systems Theory (which is basically the mother of Complexity Theory). Yourdon tells us that software projects are dynamical systems (complex systems in my terminology) and that anything you do in such a system has non-linear and often unexpected effects. Of course, I already knew that.

But what I had not realized before was that Brooks' Law ("adding manpower to a software project that is behind schedule will delay it further") is in fact a perfect example of that! I feel like I'm handed a jewel that was right under my nose and had never noticed before...

The Craft of Maintenance

I just finished reading Facts and Fallacies of Software Engineering, by Robert L. Glass. It is a good book. I particularly liked Glass' claim that maintenance on an existing code base is more difficult than writing something from scratch. I like that because this is something I've been telling people for years.

Unfortunately, most software engineers think building something new by themselves is more fun and more satisfying than working on maintenance and improvements on an existing system that someone else has built before them. (And I'm afraid I am one of those people.) The problem is: what can we do about it? Because, as Glass correctly points out, succesful projects tend to need more maintenance. After all, as a happy user I want more and more features built in a good system, while as an unhappy user I wouldn't want to touch a bad system with a stick. Unless it's a very, very long stick, with something explosive attached to the other end.

Fortunately, at my company we have built lots of systems for which users demand many new features. This means we spend twice as much time on improving existing systems than we spend on building new ones. But it also means we seek developers who like working with existing material and bending old code in new directions. I would claim that writing code in our company is much more complex than in many other environments. So if you fancy a real challenge, let me know!