I was talking to a fellow software developer recently, and he was complaining about how imperfect the development process is. His main point of complaint was that he’s constantly reimplementing things because the analysts and managers can’t provide him with a complete set of requirements upfront. As a result, he has to go through iteration after iteration, redoing things, wasting his time, and ending up exhausted and frustrated.
I could certainly empathize with his exhaustion. The repeated process of rebuilding the same application parts can wear you down. It’s demoralizing to redo work because of factors outside your control.
The Incorrect Assumption About the Job
What can I say — software engineering is hard for this very reason. Many engineers don’t understand or forget that we operate in high uncertainty. Nobody knows anything for sure. Stakeholders often don’t know what they want for sure. Managers and analysts don’t intentionally provide poor requirements — they work with the information available at a given point and don’t know what new piece of knowledge the team will uncover the next day, next week, or next month. And that new information can dramatically alter the development course for a feature or the whole product.
Interestingly, engineers sometimes assume their role is to code a clearly defined algorithm for a task. Stakeholders also occasionally hold this incorrect view if they’ve never been involved in building products. But that’s simply not the reality. An engineer’s job is to figure out both the technical and business aspects of the task. The whole team’s responsibility, including stakeholders, is to do this.
Our Brains Crave Simplicity in a Complex World
The world we live in is highly complicated. Our human brain can’t handle an almost infinite number of ever-changing variables. So, it tries simplifying everything with stereotypes, biases, habits and more. These help our brain stay sane.
We want predictability and clarity in life. We want lots of documentation if we’re using a piece of software. We want a detailed description and complete check-in instructions if we rent an Airbnb. When we buy food, we want a perfect description telling us if we’ll like the meal.
But life is always more complex. We’ve all been disappointed by software not working as expected, an Airbnb much smaller than pictured, or a meal with ingredients we hate.
We engineers see ourselves as special. We blame others when work deadlines slip. We say the analyst missed requirements, the manager didn’t ask the right questions, or some open-source maintainer messed things up.
But you know what? Government workers, construction crews, and pilots also deal with unexpected problems. That’s why paperwork gets delayed, houses take longer to build, and flights get postponed. We’re not special. Complexity happens to everyone.
So we should accept our work is hard, just like everyone else’s. Instead of blaming each other, we should collaborate towards shared goals. Even if we can’t do everything perfectly, working together is better than complaining it’s someone else’s fault. Utopian, maybe, but still a worthwhile dream.
Software Is About People, Not Just Code
Software development is that it is about way more than code or algorithms. It is about people, and we, the people, are hard to deal with. We all have different opinions that change over time. This makes for a shaky foundation when building things.
When working with a team of stakeholders, you may expect them to provide precise requirements that you can go and code. However, this rarely happens in the real world. The probability of stakeholders presenting consistent requirements is like the probability of an engineer giving a correct estimate — highly unlikely.
We, humans remember one thing, think of another, say a third thing, hear something completely different, and our brains record a fifth version. Then, we often do something only loosely related to the original thought. The complexity of software mirrors the imperfect nature of human communication. While this imperfection is frustrating, complaining about it won’t lead to change.
Engineering challenges like these come with the territory. No one promised this would be easy or that life would be all butterflies and rainbows — that would get boring quickly! But this is the hand we are dealt. The best professionals accept the circumstances, unexpected events, and uncertainty they can’t control. They figure out how to make things happen nonetheless. That’s what makes engineering an exciting craft.
Transitioning between the challenges of collaborating and the rewards of solving problems, engineering is not for the faint of heart. When stakeholders inevitably present moving targets, professionals must anchor on their principles. By embracing flexibility, we can steer chaotic requirements toward practical solutions. We can transform obstacles into opportunities with a deep breath and an open mind.
Originally published on Medium.com
