What is wrong with software development: management

Bad management as one of the biggest pain points for a software engineer.

I work with Internet and software for more than 9 years. One of the biggest problems I see in my profession is management. Unfortunately, quite often it is bad. Based on my experience, I will point out a few issues I see. I will try to identify the real problems and will propose solutions. My solutions always assume a strong and motivated technical team. How to build such a team is a topic for another post and will be discussed on this blog in the future.


1. Software is managed by people who have no idea about software development

Let’s face it, many people who are telling you what to do, have no education or experience in software development.

How many times did you receive a feature specification, which after further examination, didn’t make any sense? Managers like to spend time on long meetings and create their road-maps and specifications. The problem is that they almost never invite engineers. And later, when presenting their “next big thing” to us, they get stuck on the second question we ask. In other cases, problems start to happen later in the development process. Nobody is able to predict, plan and prepare for all possibilities when producing software, without actually writing it and testing.

How many times did you receive a short message from your PM, like: “hey, could you just change this [one little thing]?”. But after checking and understanding what it is really about you felt bad and sad. Because you knew that this “small” change doesn’t fit into your system “just like that” and it will be a pain to maintain it in the future. Managers think they are clever and they will save development time now. But why they never include time needed to maintain and clean it up later in the future?

A solution to all above is better communication between managers and engineers and true understanding of a manager role.

First of all, a technology team should be included early in the planning phase. If you are a manager who is reading this, believe me, a good team will answer all your questions and will solve your problems for you. So by not including them early, you are just wasting your own time, making decisions that will be questioned and altered later anyway.

From the other side, a team should not agree on tasks that are added later after a planning phase. Those tasks should just wait until the next iteration or sprint. As each task should be planned and analyzed on how to best integrate it with the system, a manager cannot just flip everything upside down and reorganize work already in progress.

As a team, never agree on time estimates forced on you. You know the system and its quirks, you know how complex the task is, so it’s your job to tell how long it will take. Management can only accept it. It might sound odd, but the most successful projects I’ve seen, where based on assumption that it’s done when it’s done with a just raw estimate. Successful project means that both sides, managers, and engineers, are happy with the result.

To sum up this paragraph true manager role is to give technology team directions and ideas but never influence any technical decision. It’s a cooperation toward a common goal, not top-down management in a “do as I said” style.

In one e-commerce company I worked for, management was very chaotic. My impression was that managers were like atomic particles. They seemed like running blindly in the room and bouncing off the walls. Sometimes, in some circumstances, they collided, and as in quantum physics, some energy was released. That meant they came up with another meaningless feature or product idea which, of course, had to be implemented ASAP.

2. Software product is managed by people who have no idea about product and its users

This one is very similar to above but from a different angle. Software and product management are two different skills but one cannot exist without the other.

Let’s introduce a funny abbreviation I’ve learned on one of the conferences I’ve attended last year:

  • HiPPO (Highest Paid Person’s Opinion) - it’s a very nice name for a person who impacts product and software decisions - but he should not! Think about it, how many HiPPOs have you met in your carrier so far?

How many times did you implement last minute change request just because your manager thought that it will be better that way? How many of your projects were closed or forgotten and never reached any users? Yes, that probably happened because someone there above in the company structure changed their mind.

The solution is again, to involve a technical team early in a product development process. Team members have to understand an idea behind a product, target user group, problems that they are trying to solve. Product decisions should be based on data. Data is collected by running A/B tests or direct sessions with users. The team should include people familiar with UX design. It’s very important to deliver an early version of a product to real users as soon as possible and later regularly with every change. Software product development is an agile and iterative process. No single person is able to decide on all of it.

Notice how all IT companies are nowadays in need of more and more engineers. They compete on attracting the best talent. But often they need more people just to cover a huge waste on a management level.

3. Treating software developers as production line workers

In many IT organizations, a technology department is responsible only for executive part of projects. Responsibilities are very clearly split. Product department plans and prepares a specification, then delivers it together with designs to engineers.

I would argue that’s very bad for their business. It leads to poor quality of final product and little-motivated workers.

Programmers in such hierarchical structures are labor force of XXI century. They will implement anything that you throw at them. If it makes sense or not, as no one ever expected any feedback from them.

Manager: Could you delete our production database? It takes too much space on our hard drives.
Demotivated engineer: Wait, what did you say? Oh, whatever… done!

The result is little to none agility of those teams, slow and buggy implementations, low morale and what is the worst - lack of space to grow for more ambitious individuals. And that means a company is not using the full potential of its employees. It really hurts me that everyone is trying to hire the best people and then has no challenges for them. What is the point?

The solution to above is: always approach your tech team with a problem, not with a solution. It’s our job to design and build software that will solve your problems. We are engineers, with many years of experience, we understand software and Internet, we know the best practices of its development. So let us just do our job!

4. Scrum and other Agile practices don’t care about quality of the source code

Agile methodologies of software development rule our workflows for a long time. That’s very good, they have many advantages over its predecessor. Problem is, very few managers understand the iterative process of keeping source code in a good quality. That’s not covered with Agile. A few people understand that technical debt has to be paid back. That libraries, frameworks, databases and other elements of the system have to be regularly updated. That performance of our apps is important. That refactoring and tests are part of everyday work of a software engineer.

Why there is believe that every few years you should rewrite your application? Why every change takes weeks and introduces even more bugs? Why is none of the time estimates true? Because management doesn’t understand how and even worse, why, to build code of good quality. They don’t realize that it’s an investment that will pay off with every new feature.

I could add a few more points to this list. For example, inefficient recruitment and on-boarding or hiring wrong people, wasted resources on meaningless tasks or meetings, lack of design or UX basics, that leads to terrible ideas. But I think I gave you enough to think about.

To sum up: great manager knows how to identify and hire right people, organizes them in a self-efficient team, introduces them to the product, then let them do their job, keeping them away from all the managerial distractions. Then feed them with new problems to solve, slightly directing with new goals and objectives. And never impacts technical decisions!

If you agree with me or not, let me know either way! You can find me on Twitter.

My goal is to show you how to be happy as a software engineer. It doesn’t matter if you are senior or junior. Follow me on Twitter and check this blog regularly to find out:

  • what to learn and how to develop your skills,
  • how to find a nice, meaningful job and professional fulfillment,
  • how to work less but efficient, avoid stress and over-hours,
  • how to be a part of a great team and what type of people to avoid,
  • how to find work-life balance,
  • and finally, how all of it can lead to happy and full life.

If you are not a software engineer but your job is anyhow related to software production, then you can also learn a lot along the way. Just read between the lines ;)