Jakob Wolman
Many years ago, when working as a consultant, wringing out lines of code, I came to this simple, but powerful realization. It changed the way I look at software and my whole career path.
I was on an assignment at The Big Company, working on their Big Enterprise Backend. We were dealing with multiple maintenance issues, handovers in the project and integration with other Big Systems. Most of the maintenance was done by consultants from, and sometimes located in, India. They were detached from what we were trying to create and had little understanding for the problems we were trying to solve. Even though we used state of the art technology, worked hard with TDD to ensure quality and worked according to agile principles, the problems persisted. Users were complaining about missing features or simple tasks being too complicated to perform in the system. Then it hit me: our software is made by people and is to be used by people.
Made by people
Software is designed and written by humans. Real people will have to read, understand and extend your code. People have thought hard about features you are implementing, architects have made decisions on what technology to use and you are making deliberate decisions in every technical solution you build. Real people will have to maintain your software, put it in production, fix bugs and make sure it works as expected. A large collection of deliberate decisions, knowledge and technology have gone into creating the software, to solve a specific problem. All these decisions have been affected by how the problem is understood, how communication has been handled, personal feelings and beliefs.
Used by people
It is also real people that will be using your software. Probably not the person that made the specification, and perhaps not even the person that buys your software. There will be humans, users, that employ your software to solve a specific problem. They will be happy when it makes life easy for them and frustrated when they can not understand how to use the system. Your software can put a smile on a users face or cause sleepless nights. If done well your software solves real world problems. Done poorly, your software is irrelevant and is never used making all your efforts a complete waste.
It is about people
I realized that as much as I love technology, working with the people aspect of software attracts me more (and to be honest, I believe I am better at it than I ever was as a developer). Bridging the gap between the people that create software and the people that use it has become one of my missions. Technology is a tool that helps us achieve value for our fellow humans. As long as we have those colleagues, community members and users in mind, our efforts make more sense.
The people factor also explains why software development is so complex. Technology in itself is usually complicated (the output of the system is hard to predict, but same input always generates the same output). Building software for users is complex (output is impossible to predict, and results will be different for the same input, here is a more complete explanation). Developing software, or any kind of work that involves humans, always contains a level of uncertainty. Methodologies like agile, lean and design thinking are ways for us to deal with this uncertainty.
When working with the Big Enterprise Backend we ended up going on a tour, interviewing end users of the product and asking them what they would like to see in a remake of the system. They were happily surprised that we wanted their input. We got invaluable feedback that helped us build a better system that solved real world problems more effectively. We also invited some of the maintenance engineers to sit with our team. When spending time together we got a much better understanding of each others work, and communication got a lot easier.
Time and time again I have had great results in software projects when pointing out that “the others” (the team we depend on, the users, the managers) are human beings with their own set of values and beliefs. By talking to them and finding out what is going on we have been able to solve many conflicts and technical problems that seemed incomprehensible at first. One of my most applied tools is asking the question: “Have you TALKED to them?” (I do not count writing back and forth in a Jira ticket as talking).
Next time you are facing a problem that you believe is created by others (customers included), try visiting that person or team and listen to them to find out what is really going on. What made them design the API that way? What was the reason for their decision? Work hard to understand them, and then work out a solution together.