7 Things Your Boss Doesn't Know About Software Development

Does your boss not understand your job? This article will help you better understand why your boss doesn't understand software development.

Your boss might be really great. I've had a few really great bosses in my own programming career, but even the best bosses often seem to not understand software development.

In fact, I'd say most software development managers are a bit shortsighted when it comes to more than just a few elements of programming.

So, I compiled a short list of some of the most common misconceptions about programming that your boss, development manager, tech guru, etc. may have.

1. Technical debt is the biggest drag on projects

Working on a code base full of technical debt is like running in a pile of mud. At first, when the mud is not very thick, you can barely walk through it, but when it is one meter deep, you can't move forward.

[[145379]]

One of my favorite authors, Steven Covey, author of 7 Habits of Highly Effective People, calls this the “P/PC balance” or “output vs. capacity.”

Often, managers and other non-technical people sacrifice quality in their drive for productivity—killing the goose that lays the golden eggs—thus incurring technical debt.

Of course, by twisting the goose's neck and threatening it, you might get more eggs temporarily, but it won't be long before the dead goose will never lay eggs again.

If your boss is suffering from not understanding technical debt and how it is dragging you down, I suggest you talk to him about the terms of technical debt in the P/PC balance in "7 Habits of Highly Effective People".

Most managers have probably read this classic book, so it’s easier for them to understand your ideas from the book than to say that writing new features is hard because the code base is terrible.

2. Estimates are mostly bullshit

Estimation in software development is mostly bullshit.

You know this, I know this, and even the poor project manager on the team knows it - of course, it is also possible that he doesn't know it, but he should know it.

It is very, very difficult to anticipate anything in software development because there are so many unexpected things that can happen.

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

But that's the way it is. No one is to blame for this. It's not your fault, it's not my fault, it's not anybody's fault. It just happened.

Yet, we still can’t help but play the estimation game.

“Joe, how long does it take you to build a customer login page?”

"Oh... uh..." I thought of a random time, "2 days... oh wait -" I forgot to double the CYA. " - it takes 4 days."

"Okay, then I'll give you 5 days."

"Okay, then 5 days."

Another good solution is to break down the tasks into small enough pieces so that all estimates fall under 4 hours.

Experience has taught me that an estimate of half a day usually allows you to get a decent job done. Any more than that and you're just bullshitting.

3. Can be completed immediately or quickly

Rushing a professional is usually a bad idea.

I've learned this from writing code for over 15 years now, so I know that when I hire someone to do something, if I rush them, maybe they will get it done on time, but the result will be useless work.

[[145380]]

Unfortunately, I've found that many software development managers seem unaware of this universal truth. Somehow, they think code can be written quickly and well.

Don't get me wrong, I admit there are exceptions, and sometimes you can write good code quickly, but generally speaking, slow and careful work always pays off.

It is also unfortunate that most programmers, when told to complete a task quickly, tend to take shortcuts and sacrifice quality to speed up the process.

Even more unfortunate is that such “fast coders” are often hailed as heroes because they are able to complete tasks faster because they never procrastinate or ask for more time.

However, these "fast coders" often write messy code, leaving a trail of technical debt for others.

If you're dealing with a development manager who doesn't understand the relationship between fast and good, then you better come up with some statistics to show that it costs more to fix bugs than to prevent them.

The larger the organization, and the more bureaucracy involved, the higher the ultimate cost of getting things done quickly rather than getting them done right.

(The classic book on this question is The Mythical Man-Month.)

4. Some developers are actually doing more harm than good

The fact is, we've all come across that programmer who does more harm than good to the team.

Different programmers have huge differences in their abilities and skill levels in the field of software development.

In fact, some software developers are so bad that every line of code they write at work is a waste of the company's time and resources.

This type of developer should probably pay the company, rather than the company paying him.

This may be obvious to you, but not necessarily to your boss. For example, in your opinion, Joe may be a complete loser who needs to be fired because he only does stupid things like "turning gold into stone". Everything he touches turns to useless "stone".

But if your boss doesn’t understand that having these people on your team is worse than not having them, what can you do?

Well, most software developers are afraid of being known as a snitch — and I totally get it.

But… you have to do it. It’s the right thing to do. If someone is truly a pest on the team, it’s your job to let management know that.

I know this will put you in an uncomfortable situation, but if you don't report it, you are not a good programmer. You will be helping to kill the project.

As for the so-called report, just be careful with the wording and give some hints.

For example, you could say:

"Hey, I don't like to do this kind of thing, but I feel like if I were you, I'd want to know if anyone is directly hindering the team. So, I feel like it's my duty to tell you something I've been observing.

…

Of course, these are just my observations, so please consult with other team members and use your own experience to make your own judgement.”

Or, if you prefer, this less tactful approach:

"Hey! Joe sucks. He writes code really slowly. In fact, his only saving grace is his slowness, because since he came here, the project has basically been moving at a snail's pace. If you don't get to know him correctly, it will be too late."

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

I hate it when programmers tell me that their cheapo boss won't give them a second monitor, or makes them use a 5-year-old computer.

Honestly, I really don't understand why some software development managers would not agree to spend $2k to improve the hardware for those $8k+ programmers - it's a very cost-effective investment.

[[145381]]

Old hardware equipment really makes programmers very frustrated and irritated!

Whenever a programmer complains about this work situation, I usually advise them to find another job, because there is probably no cure for the stupidity of this boss.

Don't say anything, I'll tell you:

Good equipment can give a software developer an extra hour a day, making them more productive. Even if it's only half the amount I mentioned, it still adds up to a lot of time.

If there are 250 working days a year, then it is 250 × $35 = $8750. Even if you cut it in half or a quarter, it is still a good investment.

If your boss doesn't understand this, then I honestly don't think there's anything you can do. If you really like your current job, then you can only invest in yourself.

6. New technologies are not as risky as you think

Nothing strikes fear into the hearts of software development managers more than the mention of the latest and greatest JavaScript framework release for .NET.

This has become an unspoken minefield.

There was a time when software vendors only released new versions of their frameworks or patches every year or so, so the cost of mistakes could be quite high.

Once upon a time, most source code was sealed in a "tomb" and no one else was allowed to access it, so once the company stopped supporting it, you were in a dilemma.

But now, things are different.

Today's frameworks release patches on a sometimes daily basis, and most popular frameworks are open source, so the risk is not that high.

Of course, you can also throw the jar into chaos, but this situation is rare and only requires minor modifications, rather than a drastic move to cut off all the good and the bad.

So, if your programming manager is still living in 1980, you might need to point out to him how things have changed and why staying on an old version of a framework or library is more dangerous than upgrading it.

Security holes in fear tactics are a great opening.

7. Overkill Business Analysts and Project Managers

I know I'm going to offend a lot of people, but I don't care. I'm telling the truth here, I'm the kind of person who says what I see.

Of course, the first thing to be clear is that there are some good business analysts and project managers out there - but let's be honest, the majority of them are worthless.

[[145382]]

At one time these roles were necessary to develop a project.

But now, in most cases, we don't need them anymore.

Software developers should talk directly to customers so that they can figure out their needs themselves. So we don't need business analysts.

It's a disabled position because they do half of what a software developer is supposed to do, but do nothing to help with the other half.

And the project manager is even more amazing. His goal seems to be to hinder our development and make everything a mess.

I know they mean well, but in today's agile world, project managers don't have a role anymore, so what are they for? They walk around trying to make themselves important, trying to find something they can do, and ultimately just get in everyone's way.

Many software development managers are still thinking in the past, when the position was more meaningful, and they listen to the so-called "trend" of Fortune 500 consulting firms - according to these companies, many software companies need more high-paid consultants to fill these jobs.

If your manager still doesn't get it, then the only solution is to get Agile education.

I don’t recommend you tell your boss that “business analysts and project managers are a waste of oxygen” — that’s probably not going to go over well either — so instead, I’ll focus on explaining how an agile team should work and what roles are needed.

Then it became clear that in a true Agile environment there are no Business Analysts and Project Managers, who might be better suited as Scrum Masters or Product Owners.

Be proactive

Of course, I may say some of the things I said above in a joking tone. But in reality, there is often a disconnect between software development managers and software developers in their understanding of software development.

I’m sure software development managers will complain that software developers don’t understand the business side and the difficulties of scheduling meetings – but that’s another story.

Regardless, the point is this: this isn’t an adversarial situation, but rather a solvable problem of miscommunication that can — at least to some extent — be resolved through reasonable communication.

Taking a proactive rather than confrontational approach is often the best way to resolve these issues.

Do you have any insights? Feel free to share them.