subbu.org

During my years of software development experience, I have come across a number of developers and teams that feel unhappy that they don’t get to build a grand (and right) architecture to solve a given problem. At one point I used to agree with that camp, but over the last couple of years, I began to see this differently, and I now disagree with this attitude. During this time, I have come to accept one fact - that most software developers operate in bubbles and that their understanding of reality is imprecise, and that makes the developer unhappy and miserable.

Here I am not referring to small software initiatives that are run end-to-end by a small team. I am talking about larger initiatives that cost money and time to build, and you need real customers paying real money lined up to buy the software. I am also not talking about software that must live for decades after it is built without changes.

Let me take a simple scenario. Let’s say, a developer Joe walks up to to a program/product manager Bob and asks him this question - “Hi Bob, do you think this feature would be cool for product.” Bob may respond “yes” without realizing that that “cool feature” would add up x-amount of complexity or cost to the product without returning y-amount of benefit or revenue. An affirmative answer from Bob would make the Joe happy. In his view, it is the right thing to do, and Bob has just agreed. He would then go and build it happily for the next several months.

Instead, let us assume that Bob starts asking some probing questions - like the nature of the implementation, how would a user use it, how many users would love to see such a feature in the product, impact on schedules, market realities, what it means to the product road map and so on. In Joe’s mind, these questions are not so important because “implementing his idea is the right thing to do” for the product. At the end of a long and frustrating debate (frustrating for Joe, that is), let us imagine that Bob vetoes the proposal to build that cool feature. Depending on your team structure, Joe may be a product/program manager or someone who is a stakeholder that can veto product changes. A negative answer from Bob would make the developer Joe very unhappy. He would be thinking “these guys don’t understand why this is so important to do” and so on. Unfortunately, Joe is most likely wrong in drawing such a conclusion and here is why.

One important point to notice here is that the developer’s reality is different from the reality of whoever vetoed the developer’s proposal. The developer wanted to do some really important changes to product, that in his view would help the product in the long term. From a purely technical point of view, he may very well be right. The trouble here is that his view of the reality is partial and skewed. As a developer, he is very likely isolated from end users, their use cases, and their real problems. He is also most likely isolated from the cost of development and the operating realities. As a result, he may not have enough data to make a case for his proposals other than saying that he is technically right. The net result is misery.

My take on this avoiding this misery is to focus on funding and support.

As a developer, you have to get your users and other stakeholders fund your ideas. If you are unable to make this happen, and consequently if you are not allowed to implement your ideas, it is nobody’s fault other than yours. Your idea may be great on paper, but it may not be worthy of implementation if you are unable to convince other stakeholders and get funding. But how would you get funding?

That seems like a hard question - but there is very simple solution. Take one step at a time. Instead of trying to build the entire solution correctly and completely the first time, do it in iterations. Try to get the first iteration done as quickly and as cheaply as possible. Then wait for funding and support. They will happen if users and other stakeholders perceive your idea as being useful. Let users speak, and tell you what works and what does not. This has two advantages - firstly as a developer, it will let you test the waters and get a better insight into use cases. This improves your sense of reality. Secondly, it will make it easy to make the case for your ideas. In fact, your users may themselves make the case for your ideas. This approach is more realistic, pragmatic and avoids the developer’s misery.

This is also one reason I’m usually against building grand architectures to solve grand problems in big chunks. Grand architectures don’t matter if users are not with you. Get the users your way first, and then improve solutions bit by bit. At the end, you may not have the most elegant and clean architecture, but you will have something that works for the users who use it.