March 2012 – In Search Of

Software Engineering

Posted on March 27, 2012Leave a comment

I am not a fan of software methodologies, third party libraries, hyper-generalized frameworks or other so called productivity enhancers within the software development process. At the same time, I abhor the idea of a thousand developers at a thousand keyboards creating a thousand screens, features, pages and trying somehow to stitch them together into a cohesive software product.

What do I like? Small teams of smart developers who understand how to build small re-usable frameworks to solve problems that they have already solved, and are likely to need solving over and over. Guys and Gals who are likely to re-factor their initial solution into a mini-framework. Sometimes these frameworks “adhere” to each other, and grow into something more comprehensive. Other times they are simple labor saving through code re-use.Continue Reading

Starting Green

Posted on March 20, 20121 Comment

One of the most useless project management conventions I have ever worked with is the status stoplight or RAG status. From a simplicity perspective, it is designed to convey a general state of the project. Green means things are “OK”. Amber means things aren’t that OK. Red means things are not OK at all. The convention is to get the attention of stakeholders when the status changes from green to amber to red. It is a beacon, or warning signal that something needs to change.

When Task Estimates Fail

Posted on March 13, 2012Leave a comment

Of course, the only valid reason for estimation is prediction. We want to predict the cost and duration of delivery for some set of working software capabilities. If we didn’t care about time and cost, we wouldn’t waste our time trying to predict. We realize that software task estimates alone are insufficient for this prediction. But at the heart, the task estimates being predictable; correctly representing the work that the team needs to do within some finite predictable variance is essential. Task estimates are the core of the plan.Continue Reading

Fail Fast Furiously

Posted on March 13, 2012Leave a comment

The other day, I read a tweet by @gnat (nat torkington), saying that fail fast as a mantra was misleading – because the objective was to learn, not to fail.

Actually when I exhort people to fail fast, the objective is to retire a risk. Sure, learning is important, but what is really important to the delivery of software is retiring risk. Either we know something will work, or we know it won’t work. Risk retired, the rest is just work.

What is necessary to fail is a set of success criteria. If it doesn’t meet all the criteria (at the same time), it fails. So when you send your team down the path of a POC or a Spike – with the exhortation to “fail fast”, you also need to provide them with some hard criteria to compare their results against. These criteria should give you an ability to predict whether your POC or Spike has really retired the risk, or whether you are simply kicking the can.

Weaponized Metrics

Posted on March 6, 20124 Comments

Software teams hate metrics. They don’t like to estimate work. They don’t like to tell you how much progress they have made. I remember my first “team” project. PM asked me to estimate how long it would take me to finish a task I had never done before on a platform I was new to. I replied that I thought it would take me about 1 week. PM was furious, ya know, Jack over there could have that done before noon. You software developers are all alike, padding your estimates. And so it went the whole project.

To software developers, metrics are like uranium. It is a dangerous substance, waiting to be converted into a weapon, easily used by management to destroy the team’s morale, and worse, productivity.Continue Reading