Managing the software development process has been likened to herding cats. In other words, you can’t really do it, but you can sure give it the old college try.
It’s no secret that managing the development of a software project is an imprecise science. Here are nine truisms that I’ve learned over the years that have helped me to understand the limitations of our ability to manage the strange world of software development projects.
1. Estimates Are Always Wrong
Whether you estimate something at one hour or one year, your estimate is wrong. That’s just the way it is. They won’t necessarily be extremely wrong — they might only be a little bit off — but they will be wrong.
If you look at a bug report and think, “That will take an hour to fix,” it almost certainly won’t take an hour. It might take 45 minutes, it might take three hours, but the chances of it taking exactly an hour — even give or take a minute or two — are slim. Now, you might say, “about an hour” instead. That’s a better estimate because actual, precise estimates are wrong.
Now for short projects that might take an hour, this isn’t a big deal. But…
2. The Bigger the Project, the Less Accurate Your Estimate Will Be
The bigger the project, the less precise the estimate will be — especially if estimation takes place at the very beginning of the project. As with the hour estimate above, if you estimate a project at a year, it might take nine months or 36 months. In some cases, it might take five years. There is no way to know when the project is starting out.
The bigger the project, the more “unknown unknowns” there are. There are usually more people involved. That is, as a project’s size increases, there are more variables and more things that will happen that you cannot anticipate. All of these things will add time to the project that you can’t plan for at the beginning because by definition you don’t know that they are going to happen.
3. Focus and Concentration Are Our Most Valuable — and Scarcest — Commodities
When building software, the single most valuable thing required to complete a project is the ability of the developers on the team to concentrate in an undistracted manner.
The fewer distractions, the more productive the team will be. It’s really that simple. One of the main responsibilities of a software development manager is to reduce the number and duration of distractions to the team.
Software developers, when left alone, can be quite productive. When they are interrupted — whether for meetings or by people asking questions or anything else — they can lose that productivity very quickly. We all know about “flow” and how hard it is to get into the flow and stay there. That flow time should be valued like bitcoin and protected as such.
4. Hofstadter’s Law Is the Truth
Hofstadter’s Law is stated as follows:
“It always takes longer than you expect, even when you take into account Hofstadter’s Law.” — Wikipedia
This is related to estimates, but it’s important to note the beauty of this aphorism. You can pad your estimates because you think it will help buy you time to get things done. You can add in extra factors, plan for “unknown unknowns,” and increase your estimates to take into account the belief that it will take longer than you think, but in the end, it will still almost always take you longer than you think to get a project done.
5. You Can Only Run in the Red for Very, Very Brief Periods
You can demand the team put in more hours, come in on weekends — all those “crack the whip” kinds of things — and you might get some (very) short-term gains out of that.
But if you try to make it the norm — if you try to run your team’s engine at the red line of RPMs on a consistent basis — you will burn out the engine. You will see diminishing returns pretty quickly. Employees will leave. People, like race car engines, cannot be overstressed for extended periods of time without breaking down.
6. Brain Time Is More Important Than Butt Time
This one is so important, I wrote a whole blog post about it.
Nothing will decrease productivity more than demanding Butt Time (i.e. that your developers be seen sitting in their chairs for hours on end). You can measure Butt Time and feel like you’ve got a metric that will really show how productive people are being. But you’d be wrong. Demanding Butt Time will demoralize a team that really wants to spend Brain Time.
Brain Time is what really matters. Think about it this way: Let’s say you are a manager and it is most important for you to see your team sitting at their desks “working.” You wander around the office seeing those developers sitting in their chairs, pounding away at their keyboards. All is well with the world.
But then you run across one developer, and they’re just sitting there staring at their screen. That’s it. They’re sitting and staring. For like half an hour. What the heck! They’re not doing a thing!
But of course, they are. They’re thinking. They’re spending Brain Time solving a very difficult problem. Maybe they even get up and wander around the building for a while. In the end, they sit down, type 11 lines of code, and mark a user story complete.
Did they meet your “Butt Time” criteria? No. Did they produce an elegant solution to a very difficult problem? Yes.
Butt Time proves nothing. Brain Time means everything.
7. Hardware Is Cheaper Than Developer Time — Way Cheaper
Developers are expensive. You pay competitive salaries to attract top talent. An hour of their time is not cheap. Despite this, many companies don’t realize the incredible value of an hour of a developer’s time and skimp on hardware for the team.
But come on, computers are expensive! That extra RAM will bust the budget for hardware!
Well, it might bust the budget, but that’s because you’ve got a budget problem.
Look at it this way: Let’s say that you pay a developer $100,000 a year — or around $50 an hour. Let’s say they spend an hour a day waiting for the compiler to do its work. However, you could add some RAM and a faster processor to that developer’s machine and cut that time down to 45 minutes a day. You save 15 minutes a day. At 200 days a year, that is 50 hours. At $50 an hour, that is $2,500 saved per developer per year. But what if the incremental cost of the faster machine is $500?
You get the point. If you have 20 developers, getting the faster machine saves you $40,000 for a $10,000 investment. That ought to be a no-brainer.
And that is only for the faster compile times. Everything else they do will be faster as well.
If your budget doesn’t allow for faster machines, then you need to adjust your budget.
8. If You Haven’t Read “PeopleWare”, Then You Aren’t Really a Software Development Manager
As far as I’m concerned, there is but one book that will teach you how to manage software developers: Peopleware by Tom DeMarco and Timothy Lister (be sure to get the third edition…).
This book is excellent, insightful, to the point, clear, and pulls no punches. It is full of wisdom about managing software projects and software developers. It is timeless.
9. Quality Is a Perception — Not a Bug Count
This one is really hard to accept.
Here’s the basic premise: You can have close to zero bugs in your bug tracker and people can still think your software is buggy. You can have a large number of bugs in your bug tracker and people can think your software is as solid as a rock. There’s no correlation between the number of bugs in your tracking system and the perception of the quality of your software.
Now I’m not arguing that you shouldn’t try to reduce your bug count — quite the contrary. But in the end, your software can only be said to be of high quality if your customers perceive it that way — and your bug count won’t necessarily dictate that. Weird, huh?
And while we are on the subject, what does it mean to have a “high” bug count? What is the definition of “high” when your codebase has 100,000 lines of code? 5 million lines of code? Who’s to say?
Embrace Flexibility
Bringing a software project in for a safe landing on a short runway is a challenging and difficult proposition under the best of circumstances. Add in the ambiguities and all the things that can go wrong along the way, and it’s a miracle anything gets done. Development managers need to be flexible and take things as they come
The trick is to accept and understand those ambiguities and to work with them — not against them. Accepting these nine truisms will help with that.
Sponsored by LinearB
Want to reduce a lot of that ambiguity? LinearB can closely track what is happening in your software pipeline, enabling more brain time, and automating things that require butt time. Book a demo today and find out how you can drastically reduce your code delivery times and continuously improve your development process.
If you haven't already heard, Dev Interrupted is hosting INTERACT: An interactive, community-driven, digital conference on September 30th - by engineering leaders, for engineering leaders. 1 day, 10 speakers, 100s of engineers and engineering leaders, all free.
Register Now
.
.
.
Originally published at https://devinterrupted.com on July 1, 2021.
Top comments (3)
Great one! Things that people generally recognize as thruths but would rarely behave accordingly.
The first I'd say is a no brainer yet the paradox is that though each and every person I know would say "duh, estimates are imprecise by definition otherwise you'd call them predictions" almost all of them would also expect delivery 9n estimate and complain about it.
The second might need more context. If you try to estimate upfront a big project, it's obvious. But for big projects once you break them down appropriately (it's an art, yes) and consistently revisit estimates given new information and changes, you can bring future work into some acceptable limits.
But the caveat I noticed is that in order for people to be comfortable and adjust estimates realistically when the situation demands it, people "on top" need to get past #1 and don't create an irrational pressure to "polish" estimates
Great article, Nick!
I have never heard about "Hofstadter’s Law" until now. An aphorism that you read/hear and instantly recognize the truth and simplicity of it.