Write Better Software by Talking to Each Other

February 25, 2016

The Effectiveness Formula and Software Development Productivity

I came across this formula recently, in the beginning of the book Improving Software Development Productivity by Randall W. Jensen. It’s call the Effectiveness Formula, and it looks like this:

E = C * (M * (T)) Where:

E = Overall effectiveness (0–1)

C = Communication Skills (0–1)

M = Manager Concept Awareness (0–1)

T = Computer Science Technical Skills and Processes (0–1)

You can extrapolate a lot from this. It makes a ton of sense as an explanation of general effectivenessI’m not sure “effectiveness” is the word I would have used, but it’s the one Jensen uses in ISDP, so I’ll stick with it. I mentally translate it as “a given organization is effective at successfully delivering software projects”. of a software development effort.

Multiplication is commutative, so these terms are essentially of equal weight. That is, if any term is zero, the entire product will be zero. You can have the most perfect technical proficiency and the perfect process, excellent management, but if your team communication is awful, the effectiveness of your development organization will approach zero.

It seems obvious put this way, but I don’t think it’s obvious in practice. Perhaps it’s understood that poor management will adversely affect the effectiveness of a software project, but I’m not sure it’s understood how much of a role communication plays; that is, an equivalent role to the technical skills and processes of the individual contributors, and the effectiveness of management.

If the role of communication in software development productivity were more fully recognized as a key component, I feel like I would see more articles and blogs posts about communicating effectively within a software organization. You see these sorts of articles in business and sales-focused publications, or management-targeted periodicals like HBR, but I rarely see discussion of this in software circles.

Maybe because we aren’t very good at it?

What I took away was this:

For the most part, improving management is outside my control, though I think I’m fortunate to be somewhere with great managers. To a point, I can increase my technical skills, by practice, experience, and study. It doesn’t happen overnight, and there’s not a shortcut, but I do work towards it. Almost every software professional I’ve worked with has felt similarly, and most developers are learning all the time. Improving communication, for myself and (to some extent) my team, is also within my control. I can take the time to learn to communicate better, which will hopefully have spillover effects in influencing the team to also improve communication generally.

Communicate early, communicate often. Use Yammer, Slack, Hipchat, or some combination of one or more of those. Use email, if you have to. But do communicate.

A software manager I know has a saying:

There’s no such thing as a late project if you’ve been communicating throughout the process.

In other words, if something comes up which will affect the delivery date of the project, communicate it right away. Instantly, if possible. Then the expectation for the delivery date is adjusted, and you are no longer late. What is not acceptable is failing to communicate, and then approaching the deadline with: “Surprise! We’re not done!” If you communicate regularly and honestly, this never needs to happen.

Go thou and do likewise.

Originally published on Medium

Write Better Software by Talking to Each Other - February 25, 2016 -