… no matter what the client says the problem is, it is always a people problem Kent Beck in Extreme Programming Explained
I have never been more in agreement with a quote. Ever. I would only change the words the client with anyone and in the context of Software it would still ring true.
People. Again.
Along the short years I’ve been doing Software Development for a living, I’ve encountered all sorts of problems. At some points I thought the team’s main problem were the unrealistic expectations from management. Or sales. At other points, I felt like it was a lack of skill that was keeping us back, or a particular technology or framework decision. Looking back on those moments, I realize every single one of those problems, was really a people problem.
- Management/sales/etc. has unrealistic expectations ➡ There’s a lack of transparency in the relationship between the engineering team and the rest of the world. Accepting something we believe is impossible without asserting that fact is equal to lying.
- Our team’s skill just isn’t high enough ➡ Skill is never the problem. If there’s not enough knowledge, a team can find someone who has that knowledge, and either hire them or bring them in for a workshop of sorts. Learning is always part of the job, so the real cause here is probably not skill related, but process / culture related. A place where people don't feel safe to accept they don't have X skill and ask for the time to learn it can't grow past these type of problems.
- That tech/framework is making us slow ➡ Ok, this can sometimes be true. If a technology is clunky, it can make a team slower. But teams don’t commit to a technology or framework for life and a good codebase should be able to change technologies without a world breaking effort. So why would that be a problem? The truth is, that team that's not aligned behind a common goal doesn't feel empowered to make or propose big changes. And empowerment happens to people. Not technologies or frameworks.
All in all, transparency and clear communication are the true key to finding out what our problems really are. Software doesn’t have problems. It doesn’t fall down from the sky with bugs or delivery issues. Software is made by people, who pour their time, knowledge and experience into the code they write. When a person has a problem, that will be translated to their code. And if every person in a team has a problem, well, you can see how that would escalate quite quickly.
Software is written by people. People with friends, families, pets and hobbies. But, perhaps more importantly, people with feelings. If you ignore the fact that your team members have feelings and emotions like any other human being, you will lose perspective on how Software is built. And that’s the point where people start calling other people resources.
P.S: don’t call people resources.