6 things your boss doesn’t know about software development

Article originally published in VentureBeat.

“My boss doesn’t understand what I do.”

We’ve all said that at some point, and it’s usually just regular workplace griping. But software developers are in a tough spot because when your boss doesn’t know anything about software development, it can make your job way more difficult.

Bosses might think they know what they’re doing — after all, how hard is it to just set a deadline and expect people to meet it? But software development has a particular way of working that just doesn’t make sense to non-technical managers.

For instance:

1. Throwing more people at a project doesn’t help

Managers who are inexperienced or don’t have a software background often think a team will work faster if they introduce more warm bodies into the project. It’s a rookie move that always elicits groans from the dev team.

Rather than speeding things up, adding people actually slows things down. A senior team member will have to put aside whatever they are doing to get the new person up to speed on the team’s progress.

The problem gets even worse if that person is a new hire or a rookie because anything this newbie does will have to be double-checked by one of the veterans — which, again, is valuable time spent away from the actual task.

2. You can’t just “add something in”

The most dangerous words a stakeholder can utter are, “can they just add in [insert feature]?” Stakeholders and users aren’t programmers and don’t know whether their seemingly minor request is even possible, much less how difficult it would be to introduce in a way that doesn’t break everything else in the project.

The problem is that managers are susceptible to stakeholder pressure and tend to blindly accept requests, committing the team to something that takes far more time than the manager originally quoted, which increases the pressure on the team and may lead to more mistakes.

In the end, nobody is happy.

3. QA can’t catch every bug

Managers (especially non-technical ones) seem to think any code that goes through QA should be sparkling clean and completely sanitized.

Zero bug policy!

That’s the goal, for sure. QA spends hours and hours of time each day combing the code and testing various functions and use cases for bugs to squash.

But it’s hard to test complex software programs because there are so many variables to work with. Even the simple act of attaching a file can become a QA challenge. How many file types have you tested? How big are they? How long are the file names?

Each one of those factors could potentially trigger a bug, and the possibilities multiply as one part of the software interacts with other parts (e.g. emailing an attachment after uploading it). It’s difficult for QA to test all variables.

Another thing about bugs is they don’t behave logically. Some bugs can only be triggered under the most specific and outlandish conditions (e.g. a program crashes if you hit the “Like” button 52 times). QA can’t predict every possible behavior and condition.

4. Working with other people’s code is always a nightmare

Working on code isn’t the same thing as working on a car engine. Code varies widely between individual businesses, departments, teams, and even — especially — individual programmers.

So working with someone else’s code is like walking in a minefield. You don’t know how the code is built, how one section interacts with another, or whether a change will blow up in your face — and take the rest of the program down with it.

5. Effort and productivity aren’t the same things

Many managers seem to think that if you are spending a lot of time on something, then the project must be moving forward. While that’s true most of the time, there are situations when it’s the complete opposite.

If you need an example, just go back to our previous point about working in other people’s code. Most of your hours will be spent just reading it and trying to figure out what it does. It won’t be until much (much) later that you’ll be confident enough to change it without breaking anything.

6. Technical debt is real, and it will catch up to you

When most bosses are faced with a choice between doing something right and doing something fast, they will choose the latter. The product still works, and the boss looks good for exercising “management skills” to get the product out the door.

Except this quick-and-dirty solution will most likely lead to bigger problems down the road. Slapdash code will almost always cause complications that damage future efforts.