Archive for July, 2010

So much has happened this week, and I would love to share it with you, but I have to wait for it to be completely official.

Soon…

While you wait, you can check out my favorite link from this week: Couchio. Great page design with interesting content. CouchDB is one of my favorite topics to read about right now – CouchDB and Android… I’m using CouchDB for a few homebrewed programming projects and in my opinion CouchDB is the best thing since sliced bread…

Our industry is plagued by an epidemic of very bad code

– Robert C. Martin (known as Uncle Bob), founder of ObjectMentor and author of several books including Clean Code: A Handbook of Agile Software Craftsmanship.

Of course Uncle Bob would say that because it serves his purpose of selling the Clean Code-book, but I would still agree with him on this one. I often hear a lot of programmers complaining that in a world of perpetual recurring short deadlines there will be a lot of technical debt and code debt in our line of work. Unfortunately.

But what can we do about it? There is never time for a spring cleaning and the business usually can’t see the point of such an activity, but hey, they are not the ones having to live in that messed up codebase.

Sometimes I even hear the technical debt argument as a anti-agile argument – because an organic not-designed-up-front architecture is inevitably going to end up with a lot of technical debt IF NOT REFACTORED on a regular basis. My answer to that, is that refactoring is a part of any agile programmers job – your story is not finished before you have refactored the code and considering architectural refactoring should be part of sprint planning.

A similar point is made by Uncle Bob in this video from the IT-conference JAOO (about 7 minutes in);
When Uncle Bob asks Pete McBreen how a programmer can get the time to write good code and his answer is: “you should cheat the boss – just write good code without permission to use the time”, Uncle Bob comments, that he doesn’t consider that cheating – he considers that professionalism!

I still believe that an organic REFACTORED architecture is better than an up-front-planned architecture, that is outdated and worked around when adding new features.

Is your work also impeded by bad code? Do you consider it professionalism to cheat your way to a liveable codebase?

P.S. Michael Feathers (also in the video) just wrote a blog post about learning from bad code. Please consider helping him with this project.

As a geek I love going META – and a TED talk about TED talks is a hit with me.

Sebastian Wernicke analyzed TED talks and concludes that when you deliver one you should talk about how “french coffee spreads happiness in your brain” because that is the top words from the most popular talks. He also concludes that if you want to make a bad TED talk the top 5 words you should mention are:

1. So
2. Oxygen
3. Aircraft
4. Project
5. Girls

Considering how popular a topic number five is in other places of the Internet that is quite funny. Other unpopular words include “computer”, “feet” and “design” (and I conclude from that, that you shouldn’t be giving TED talks about how you designed a creative way to control computers with your feet)… et cetera, et cetera…

Watch the video:

I wonder if these facts are transferable to any kind of talk – like maybe a thesis defense?

I no longer believe in doing Scrum by the book!

This will be considered a provocative statement for some but let me just explain myself: I’m not suggesting that we shouldn’t follow a well-defined, tried and tested process, but I AM suggesting that we adapt the process to our current needs and maybe as far as you couldn’t call it Scrum anymore.

Now some seasoned agile people will say “DUH, of course you have to inspect and adapt. That is what agile is all about”, but I have also heard a lot of people saying, that “of course that project failed – they didn’t do Scrum properly” (whatever that means).

In my opinion what matters is that you reflect on you proces and continuously improve (Kaizen) – if you do that you can start out with Scrum and adapt into something that is a better fit for your organization. It is much easier to fit the process to the organization than to fit the organization to the process.

At JAOO last year I attended a tutorial called “Scrum tuning using Organizational Patterns” (by Jim Coplien and Gertrud Bjørnvig) based on the book Organizational Patterns of Agile Software Development by Jim Coplien and Neil Harrison. It transitioned me into what I jokingly call my post-Scrum phase – a phase where I can see agile as a collection of good ideas to choose from; a toolbox. The organizational patterns book adds to that toolbox and provide ways to guide the adapt part of inspect and adapt.

Now I have the feeling that I know more about why Scrum is precisely that collection of good ideas (organizational patterns) and what kind of problems Scrum is aiming to handle and that feeling gives me the confidence to reflect on the Scrum method and adapt to the concrete needs of the projects I’m involved in.

As Jeff Sutherland writes about Jim Coplien and the Organizational Patterns-book:

Jim was surprised when he found that Scrum compresses at least 33 patterns from his book into a concept that can be explained in 2 minutes. It takes over 60 pages of rather dense text to describe these patterns.

The connection between Scrum and Organizational Patterns can be seen in this overview that I stole from the slides by Jim and Gertrud:

I recently found a link about the Top 10 Organizational patterns – As far as I can tell they are presented as in the book, but the links to other patterns are dead links (and remember; content is more important than form in this case).

Organizational patterns have really helped me move beyond Scrum and to value some of the more social aspects of software development higher. If you are having problems with your process consider looking into this concept. I know that patterns are sooo 90’ties, but they are still a reasonably way to transfer knowledge.

And I should probably revise my first statement – I no longer believe in doing Scrum by the book, but I do believe that a book can inspire me to fine-tune Scrum maybe transforming our process into something completely different – if that is what we need.

My previous post about the Lego Turing Machine could (for some) be a contender for the title of “The most useless machine ever built in Lego”, but it is certainly a step up from this useless but entertaining machine: A machine that turns itself off.

Useless but cute. How do people even think up these things?

>”Honey, you’re my treasure.”
>”No, the Lego is the treasure. Dad – We’re Lego rich!”

Combining TED talks and Lego is a winning formula. This guy is really Lego-geeky – I love his story: