Software is written for People
Every software product we develop begins with some idea of its use by some human user directly or indirectly. Long ago, when I was developing a device driver for a Communication protocol called ATM (Asynchronous Transfer Mode), I had no clue how it is going to be used, until I learnt that it was going to be used by the Bibliotheque Nationale De France or the French National Library in Paris. But that did not impact me in any way. I was busy with the interrupt handlers and the kernel panics.
For a long time, working with the OS code, protocol stacks, I had no interest in what the user wanted. Of course I was aware of what my customer wanted who was paying for it. The more closer you get to the hardware, the problem to be solved is often straightforward, and the focus shifts to the technical details.
As you move up towards an end user App, the wants are a lot more nebulous. It becomes easy to write the code, but you end up writing and rewriting because the more you write, the better you find the gaps between what the user wants and what you ended up with. So you do this in an iterative fashion until you find what you wanted and what you developed converging to a good extent.
The reason I say this is, most developers do not care to understand what the ultimate end user might be looking for. In a large project, what one may get to solve is a part of a large puzzle. So they just bother about their surrounding modules that interacts with theirs and end up at the most knowing what the fellow developers want from them. And software is so immersive, you can easily get lost in the details.
Typically the Architect or the Product Manager are the ones who may bridge the gap between the end user and the Engineers. But many a time, it is possible they have misunderstood the user needs because they were too much invested in the solution than the problem. And in many cases, the end user themselves do not have the clarity on what they want.
Thus a lot of misunderstanding happens when the end user needs are translated through a chain of human thinking. It is similar to the six blind men trying to decipher an elephant groping over it and coming out with different answers.
The only way a better understanding of what you code for emerges when you care to know about the real problem being solved. Once you know who you are solving it for, the real human user who will be using your software and the problem they want it solved, you will find that the code you are writing becomes a lot more focused, less buggy and sometimes even a lot simpler.
It is the job of the leads and Architects to get the user story discussed thoroughly with the entire team and repeatedly question it to bring the needed clarity.
Ultimately all software is written for humans and this is where a large amount of time should be spent by the team that develops the product.
