7 Things Your Boss Doesn’t Understand About Software Development

Your boss may be awesome. I’ve certainly had a few awesome bosses in my programming career, but even the most awesome bosses don’t always seem to “get it.”

In fact, I’d say that most software development managers are a little short-sighted when it comes to more than a few elements of programming.

So, I’ve compiled a short list of what I think are some of the most misunderstood aspects of programming that your boss, dev manager, big kahuna, or whatever you call him or her just might not… understand.

1. Technical debt slows down a project more than anything else

Working in a code-base that is full of technical debt is like trying to run through mud. At first, when the mud isn’t very think, you can trounce right through it. But when it gets to be a few feet deep, you can hardly move.

One of my favorite authors, Steven Covey of 7 Habits of Highly Effective People, would call this “P/PC balance,” or “production versus production capability.”

Often it seems that managers and other non-technical folk don’t understand that when you push productivity, but are willing to sacrifice quality—thus incurring technical debt—it’s like killing the goose that lays the golden eggs.

Sure, you might get a few more eggs out of the goose by wringing its neck and threatening it, but after some amount of time that dead goose is just going to stop laying eggs.

If you boss is suffering from technical debt blindness and doesn’t understand how technical debt is slowing you down, take a page from his book and talk about technical debt in terms of P/PC balance as mentioned in 7 Habits of Highly Effective People.

Most managers have read this classic management and self-help book, so you’ll be more likely to get your point across rather than saying that it’s difficult to code new features because the code-base is so bad.

2. Estimates are mostly bullshit

Estimations in software development that span more than a 2-hour time window are mostly crap.

You know this, I know this, even the poor project manager on your team knows this—okay, well, maybe he doesn’t, but he darn well should by now.

It’s just notoriously difficult to estimate anything in software development, because you never build the same bridge twice.

Every software project, every task is new. Every time you sit down to write code, some new unexpected shit happens.

That’s just the way it is. There is no one to blame for this. It’s not your fault. It’s not my fault. It’s not anybody’s fault. It just happens.

Yet, we still play this game like estimates matter.

“How long do you think it will take you to build the customer login page, Joe?”

“Oh… hmm…” Pulls random number out of ass. “Two days… Oh wait—” Forgot to double it to CYA. “—Make that four days.”

“Ok, I’ll put down five days then.”

“Yep, five days.”

If you boss is still clinging to estimates like they actually matter and are based on anything besides randomly rolling a d20, you might want to direct him to one of these articles I’ve written about estimates in software development.

• The 4 Biggest Reasons Why Software Developers Suck at Estimation
• 5 Ways Software Developers Can Become Better at Estimation

Another good solution is to insist that tasks be broken down small enough so that all estimates are under four hours.

Experience has taught me that we can do a fairly decent job at estimating things that take less than half a day. Beyond that point, we start to drift into the bullshit territory.

3. It can be done right or fast

Rushing professionals is generally a bad idea.

I’ve learned this from writing code for over 15 years, so I know when I hire someone to do something, if I rush them, chances are they’ll finish on time, but the result will be crap.

Unfortunately, I’ve found that many software development managers still don’t seem to understand this universal truth. Somehow they think code can be written fast and good.

Now, don’t get me wrong, there are some exceptions. Sometimes you can write good code fast, but more often than not doing things right requires extra time.

Also unfortunate is that most programmers, when told to get things done quickly, tend to take the shortcuts that sacrifice quality to expedite the process.

Even more unfortunate is these “cowboy coders” are often lauded as heroes because of how much quicker they can get work done and because they never push back or ask for more time.

Of course, these “cowboy coders” often create a big mess for everyone else to clean up as they leave behind a trail of technical debt.

If you are dealing with the kind of developer manager who doesn’t seem to understand that fast usually has a pretty big trade-off with good, you might want to pull together some statistics that show how much more costly it is to fix bugs than it is to prevent them.

The bigger the organization is and the more red tape involved, the larger the cost ends up being for doing things fast instead of right.

(Let’s not forget the classical book on this subject, The Mythical Man Month.)

4. Some developers can actually produce less than 0 code

Let’s face it; we’ve all worked the programmers who actually ended up hurting the team more than helping them.

There is a huge variation in ability and skill level in the field of software development.

In fact, some software developers are so bad at their job that every line of code they write actually ends up costing the company more time and money.

These kinds of developers should probably be paying the company instead of the other way around.

It might be obvious to you, but if not you might be wondering why your boss doesn’t realize that Joe is actually a complete loser and needs to be fired, because he seems to have the opposite of the Midas touch. Everything he touches turns to crap.

If you have a boss that doesn’t seem to understand that some of your team is actually worse than dead weight, what can you do?

Well, most software developers are afraid of coming off like a tattle-tail and don’t want to report of coworker for being a lazy, incompetent ass—I totally get it.

But… you have to do it anyway. That’s right. If someone is actually hurting the team, it absolutely is your job to let your manager know.

I know it’s an uncomfortable situation to be in, but if you don’t report blatant incompetence, you are incompetent as well. You are an incompetence accomplice and I’ll make you wear a red letter.

Just be sure to phrase things nicely and drop some hints that will lead to more investigation.

You might say something along the lines of:

“Hey, I don’t like to do this kind of thing, but I feel that if I were in your shoes, I would want to know if someone was directly handicapping the team. So I feel that it is my duty to inform you of something that I’ve been observing.

Now, these are just my observations, so definitely check them with other team members and your own experience, but…”

Or, if you prefer a less subtle approach:

“Hey! Joe is a jackass. He sucks at writing code and he’s slow. In fact, his only redeeming quality is that he is slow, because since he can only eff things up at a snail’s pace. You should definitely shit-can him.”

5. Better equipment is one of the cheapest productivity investments you can make

I’m so sick of programmers telling me that their cheapskate boss won’t let them have a second monitor or that they are using a five-year-old computer.

I honestly don’t understand why there are software development managers out there who don’t realize spending $2k on good hardware for a programmer you are paying $80k+ a year to have on staff is actually a good—nay, great—investment.

Seriously. This is the kind of shit that actually pisses me off!

Whenever a programmer tells me about this kind of situation at work, I usually tell them to find another job, because this is just plain stupidity and I’m afraid there isn’t much of a cure for it. (Next, I’ll tell you how I really feel about the subject.)

There isn’t a whole lot to say here, except this:

Good equipment might save a software developer just an hour a day or make the developer an hour more productive each day. And even if it is just half that amount, it’s most likely going to add up to quite a bit.

(I personally think every software developer should at least have one of these.)

With about 250 working days in a year, we are talking perhaps 250 x $35 an hour = $8,750. Even if you cut that in half or a quarter, it’s still going to be a clearly good investment.

If your boss doesn’t get this, I honestly don’t think there is much you can do. If you really like your job, spring for your own equipment (I’ve done that several times) if you don’t quit first.

(Also, don’t forget 3rd party software, tools and APIs can be an extremely wise investment. Often you can save a ridiculous amount of money and time by buying off the shelf instead of trying to create your own version or do without.)

6. New technologies are usually not as risky as you think

Nothing has the power to put fear into the heart of a software development manager like mentioning the latest, greatest JavaScript framework of version of .NET.

Now, back in the day, this use to be a valid fear.

It used to be that software vendors only released new versions of a framework or patches every year or so, and therefore a mistake could be rather costly.

It also used to be true that most source code was locked up in a vault where no one could get access to it, so if that company stopped supporting it, you were up the creek without a paddle.

But today, things are a bit different.

Today, frameworks are sometimes patched on a daily bases and most popular frameworks are open-source, so the risk is just not as potent.

Sure, you can “bleed on the bleeding edge,” but it just doesn’t happen all that much anymore and the cuts seem to be more along the lines of the paper-cut scale rather than getting slashed with a broadsword.

If you programming manager is still living in 1980, you might want to point out how things have changed, and how it may actually be more dangerous today to stay on an older version of a framework or library than it is to upgrade.

Fear tactics mentioning security vulnerabilities are always a nice touch as well.

7. Business analysts and project managers don’t do shit

I know I’m going to catch some flak for this one, but I don’t care. I speak the truth here and I call it as I see it.

Obviously there are some good business analysts and projects managers—I might be stretching it with project managers—but let’s be honest, most of them are worthless.

There was a time and place where these roles were necessary. (I don’t know when that was, though. Perhaps when everyone was doing waterfall development and developers didn’t talk to customers directly and we needed someone to create a huge Gantt chart.)

But, for the most part, they aren’t necessary anymore.

Software developers should be directly talking with customers and figuring out the requirements themselves. We really shouldn’t need business analysts anymore.

It’s sort of a handicapped role, because they do exactly half of what software developers should be able to do and can’t do the other half.

And project managers just seem to get in the way and screw everything up.

I know they mean well, but there just isn’t a place for a project manager in an Agile world, so what do they do? They go around trying to seem important; trying to figure what they can do and they end up getting in everyone’s way.

A lot of software development managers are still stuck in the past, where these roles were more relevant or they have been listening to the pied piper of huge fortune 500 consulting firms telling them that they need all this extra staff of super-high paid consultants filling these roles.

If your manager doesn’t quite “get it,” the only real solution is to proceed with some Agile education.

I wouldn’t recommend directly telling your boss that business analysts and project managers are a waste of oxygen—that might not go down so well—but, instead I’d focus on clearly defining how an Agile team should operate and what roles are needed.

It’s pretty clear that there is no place for business analysts and project managers in a real Agile environment, and that they might be better suited as Scrum masters or product owners.

Be proactive

Of course, some of what I am saying here is presented in a joking manner, but in reality there tends to be a disconnect between what software development managers and software developers understand about software development.

I’m sure software development managers would complain that software developers don’t understand the business aspects and challenges of meeting schedules required to make sure everyone gets a paycheck—but that’s another story.

Anyway, the point is: it isn’t an “us versus them” situation, but rather just a miscommunication problem that can often be solved—at least to some degree—with proper communication.

Taking a proactive approach rather than a confrontational one is often the best way to solve these problems.

I’ve outlined a few tips for dealing with each of these misunderstandings, but what have you found to be most effective, and what misunderstandings have I left out?