About planning and emergency

The title was inspired by Davide Bianchi, that posted out of his office a sign that reads "Pianificazione schifosa dalla tua parte non è emergenza dalla mia parte", which more or less means "if you don't know what planning is about, don't come here complaining, because I have my own priorities". Or, to quote something a little farther on the timeline, "frankly, my dear, I don't give a damn".


It is true that no plan survives the contact with the enemy, but planning is essential. It is one of the core practices of risk management, which, as Tom DeMarco and Timothy Lister write in Waltzing with Bears, is "Project Management for Adults". What are the risks? You have to look ahead, and decide how you want to deal with them. Of course hoping for luck is an option... but how good is it? Sometimes you can count on it, maybe because even if your luck abandons you it'll affect but a small portion of the whole project. But, honestly, do you really think that none of those twenty or thirty bad events is actually going to happen? Do you know what the odds are for a chance like this? I was pretty good at statistics, and as far as I can remember the answer is "very, very, very low".

And this is when emergency comes into play. And, obviously, as there were no risk mitigation plans, there are no contingency plans, and your luck is having a holiday, there is a problem. As strange as it may seem, this comes as a complete surprise to many.

When planning fails (if ever there was any) the hunting season for scapegoats open. Little matters the fact that the scapegoats themselves have spent a good part of the previous months asking for a plan, or at least for directions, and trying to raise alarms of all kinds. Don't think scapegoating is something you can ad-lib, it is an art: there is also an article about the art of scapegoating in IT projects. Wikipedia reports that "Scapegoating is a known practice in management where a lower staff employee is blamed for the mistakes of senior executives. This is often due to lack of accountability in upper management."

Unlike as in Davide's office, in my experience bad planning by someone else does transform into an emergency happily hopping and bouncing on your desk. At this point, at least in the eyes of the stakeholder, quality becomes absolutely tradable, because the deadline has stopped soaring and is swooping down on them. Too bad, as what seems a saving today will cost blood and sweat tomorrow (not in a month, but within a week). Ok, maybe not blood. But I can guarantee for sweat - and money. Moreover

poor Martin Fowler
will feel so sad for all that
which is way too bad

featuring both a haiku and a link to an interesting article at the same time.

Manifesto for Software Craftmanship

A new manifesto is born in the world of software development: the Manifesto for Software Craftmanship. Have you signed it yet?

Is software quality expendable?

This is one of tose questions that has been around for a very long time. A recent study from Original Software shows that it will probably stick around in the next years, as the world of CIOs appears splitted in two: 46% of CIOs think that quality has a very important role, while 41% sees it as a "nice to have quality" or even as a necessary cost.


I'm not a CIO (yet) but I have a very clear opinion on the matter.

Many CIOs have a special bend for asking "low cost working software, ready for yesterday". The problem is that the real cost associated with software is not writing it, but - even after a considerable amount of time - reading it for further modifications, bug fixing, evolutions, refactorings, etc. Leave that mess now and it'll cost you much more tomorrow. Software becomes kippleized (read this book for more infos on the term), someone says this happens even if you're not touching it and, mostly, when you're not watching. Bad quality software makes your technical debt increase, thus increasing the cost of software. Add the fact that most of the time you're modifying existing software rather than creating fresh new applications and you'll have an idea about the huge impact this debt can have.

And... is that low cost software really working? The forces involved in software development are intertwined, so you can't modify one without affecting the others. Literature normally refers to time, scope, cost and quality. Cut time and cost and guess what happens.

Another very important aspect, albeit disregarded by CIOs, is that developers love their job (well most of them do). We try to do our best, and we are proud of it. We are not satisfied when time is cut and cost and scope are kept fixed, as quality necessarily drops. Nobody wants to produce sloppy code. Nobody wants to be forced to produce sloppy code. Somebody might even think to move to another company, which, again, means a non neglectable cost. That could even start a trend, and you can see a company slowly transforming into a sinking boat. I'm probably going too far, but it is just for the sake of clarity.

The whole study can be downloaded here (some informations required).

Scrum vs Lean?

Following this discussion I posted my thoughts on the subject. Even if I have just become a CSM, I have to agree about the importance of the certification itself; as our instructor Joseph Pelrine said, "I can only certify that we breathed the same air for a couple of days". This feeling seems to be shared by most hirers in the market. Nevertheless, I learned a lot in those two days, and I also had the opportunity to meet many skilled guys who share my very same interests.

That said, Scrum is about addressing the chaos you tipically get in a complex and fast changing environment, not about developing software: e.g. I always use it with my wife whenever we have to “refactor” our garden (ok, that’s not too complex an environment, but I’m sure you get the point). If you’re looking for practices to improve the quality of software, you’re looking in the wrong place. One word of caution: Scrum really fosters software quality improvement, but it does not provoke it. People improve software quality.

Scrum is not bad because you see many bad Scrum implementations; I’m sure you can find bad implementations of almost everything (OO is not bad because many programmers disguise their procedural code - which is not bad per se, but the mix of the two is often weird). I want to stress that a Scrum Master does not tell the team what to do, as he is not the leader; he is a servant to the team: sort of an istance of the “sacrifice one person” strategy by Cockburn, except maybe for the fact that in the latter you normally assign the sacrificed person a particular task.

I also agree with the fact that a team needs good leadership thus a good leader, even If I'm aware that many will not agree with that. I also think that the leader should emerge naturally in the team, and should not be superimposed. A team without a good leadership (I'm talking about an "internal" one) could easily end up out of action, especially an inexperienced one.

TDD being imposed in every quality discussion?

Following this discussion I posted my opinion on the matter.

When you have a "simplest thing that could possibly work" the first fit can be a good answer, but it could also be a horrible one. That is where refactoring comes in, and I must admit I'm pretty astounded that nobody mentioned it so far.

TDD means "let me think what this should do... ok I'll write a test that uses this class... there you have the class... ok it works... LET'S ELIMINATE ALL DUPLICATES AND SEE IF WE CAN SIMPLIFY IT FURTHER".

TDD helps quality not only because your software works, but also because it is simple and easy to understand (then to modify). TDD should not be imposed in every quality discussion, but it surely is a very good means to reach quality; writing tests surely is time consuming, but it is well invested time: you're paying for quality. As Philip Crosby said, quality is free but only to those who are willing to pay heavily for it. That's why also Clean Room works, because you're willing to pay.

To quote,

code quality is a function of thought and reflection, not bug prevention.

Sadek Drobi replied that

Code quality is not only about code simplification, but also and most importantly about reflecting correctly the domain (see DDD). TDD is applied to units, you can not build a coherent quality code while thinking locally. That is why TDD is not the "Tool" to quality code. Quality code is a result of good design skills (thorough domain analyses), a lot of discipline, and Functional tests.

TDD is not necessarily applied to units (I know I wrote on InfoQ that I agreed, but I was thinking of Unit Testing and not about TDD), but it's true you cannot build a coherent quality code while ONLY thinking locally. But it surely helps, and this is particularly true if when Sadek talks about functional tests he is referring to automated functional tests.

Sadek then pointed out how TDD is about short cycles and thinking locally, supporting this idea quoting Beck, and stressing the point that TDD does not produce quality code per se and reiterating the importance of design skills, domain analysis, discipline and functional tests.

Again, I agree with him: TDD surely helps to produce good code but is not "the" tool. I mean, if you have a perfectly analyzed class which perfectly represents a domain object (I'm fond on DDD too) but you find it difficult to be tested, probably there is a slightly different and slightly better metaphor to describe it (and maybe an SME can help in defining it). Being able to write a test for a class before actually writing it kind of "forces" you to have an attitute just like the one Sadek describes: you have to analyze the domain with a lot of discipline, because with TDD you are actually saying "what am I expecting from this piece of code? what is the expected behavior of the real object it represents?". Of course, you must also have funcional tests, and having good design skills is almost mandatory, otherwise one would blatantly miss the point of the whole question.