Principles and Rules

Some weeks ago I gave a talk at AgileDay.it. My talk was about a weird experimental Kanban board, and the Leitmotiv I used was around the differences between Principles and Rules. The topic was: we often learn methodologies mocking rules (often, without getting the point) rather than trying to understand the principles behind them. This bad habit sometimes leads us to take really dumb decisions.

Well, if only I had seen then what I saw today, I would have used in my talk, since I think it would have been the perfect example.

See what I found in a recent production code.
Right now, it hangs on the wall of our open space, for all the developers to see.

Preemptive commit comments

tl;dr version

Rule #1: write commit comments before coding
Rule #2: write what the software should be supposed to do, not what you did

You won’t believe how old TDD is

Kent Beck is credited as the the TDD inventor.
Yet, he claims he just re-discovered it.

Rule #1: don’t tell me the rule, state the principle behind it

Some days ago, one of my colleagues showed me an unit test, coded by someone else. It was something like

A brand new, iterative and analytic Agile Methodology is born. Don’t miss it!

Disclaimer

This post is going to be pretty long.
Feel free to scroll down, or roll the paragraphs, if you think.
I’m pretty sure you will entirely read it later, since it is really interesting.

In case of panic, click here to jump to conclusions.

Introduction

Managing The Development Of Large Software Systems

I am going to describe my personal views about managing large software developments. I have had various assignments during the past nine: years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post-flight analysis.

Unit tests lie: that’s why I love them

When a unit test for a method implementing some feature is green, it does not mean the feature is working. The corresponding end-to-end or integration tests reveal if it’s working or if it’s broken. To Product Owner’s point of view, end-to-end tests are all that matters. Unit tests are useless.

Unit tests are meant to lie. They rely on the often wrong assumption that the rest of the world is correctly working, but only because they are explicitly mocking it: using a fake world is a deliberate lie.

To me, that’s exactly why they are so useful.