Goals vs. Constraints

The classic source of stress and dysfunction in development teams - yes, in fact, in any teams - is a confusion between goals and limitations.

Teams often mistakenly limit goals. A typical example: a team takes product requirements for its purpose, losing sight of the real needs that originally generated these requirements.

Requirements, architecture, application design is a limitation. As a rule, one problem can be solved in countless ways, but we just chose one specific one. This, by definition, is a limitation.

I saw a lot of technical startups that lost sight of how, why, and why they were doing, and slipped into a 100 percent focus on extracting money, necessary exclusively to maintain the current state of affairs. This is very common. Think about all these charitable foundations that started with a clear goal (relatively speaking, “save the cat”), but several years later it turns out that most of their efforts - if not all - are aimed only at finding money to pay everyone a salary and continue “charity”.

Of course, you can object to me that making money is the business’s task, and this money is the price that the business solves the tasks of users. The goal of the restaurant is to make money. The purpose of dinner is to be eaten. I give you money. You satisfy my hunger.

Therefore, if the whole essence of the existence of your organization is to make money, then it is vital for you to have a good, deep understanding of the goals and needs of your client.

This idea of ​​business goes back to the 19th century. But even then there were progressive industrialists who set goals more than just making a profit. At its best, a company can create meaning and purpose for its employees, enrich their lives and the lives of the community, and add appeal to the surrounding landscape.

But I was distracted. Where did i stay? Oh yes. Goals versus limitations.

Imagine you are planning a trip from your home in Los Angeles to San Francisco. Your goal is to visit Frisco. The limitation may be the fact that you want to drive your car, and you do not have enough gas for the whole trip.

You decide to raise money for gas. To do this, you start making lemonade and selling it at a kiosk near your home. Things are going well. People like your lemonade, and, thanks to the good location of your house, there are always many passersby who need to quench their thirst. Soon, money for gas is more than enough. But the sale of lemonade is so brisk that you are only preoccupied with thoughts about it, and not about San Francisco. You plan to add freshly squeezed orange juice and smoothies to the assortment. You buy a bigger table. You hire an assistant, simply because you do not have time to do everything yourself. You are buying a new house on the same street, larger and with a more spacious yard. Then you start delivering your drinks to local restaurants when they are short of their own.

Meanwhile, you never went to San Francisco. And now you are too busy, so you are unlikely to find time to ever go there.

Now, if you are a scorched capitalist, you can object: "so what?" Is your lemonade business a worthy compensation for a missed trip?

Maybe yes, and maybe not. As I get older and older, I increasingly start asking myself the question "why am I doing this?" I know too many people who are too distracted by “success” and have never traveled, never gained this experience, never created a home recording studio, never learned a foreign language ... and did everything else that was still in their plans .

For most of us, equal to people and organizations, the need to raise money is a given that we can never get rid of. This is a limitation that may help or prevent us from achieving our goals.

In the same way, in teamwork, it is extremely easy to go down to the details and stop paying attention to why we create programs and systems in the same way as we did initially.

Therefore, I believe that there is a need to seek balance. Trying to achieve the goal, you need to pay attention to the existing restrictions, but if you think only about them and forget about the goals, then all our efforts can be in vain.

Binding too tightly to restrictions reduces our chances of achieving goals.

Limitations restrict. That is their essence. For example, if we limited ourselves to one specific route from Los Angeles to San Francisco, and halfway found that the road was blocked, then we would have to look for other ways to reach our destination.

I have often seen teams smash their heads against walls, trying to realize requirements that for some reason could not be met. It was too difficult to just take a step back and remind yourself what goal they wanted to achieve, to ask themselves "is there any other way?". I saw how projects for many millions of dollars fail because no one else saw the other way. It must be Oracle. It must be Java. It must be a web service.

Not. Should not. Most of the constraints that we face are actually someone else's choice — maybe even a choice we made ourselves — we just forgot that it was a choice.

Of course, try to make it work. But do not confuse the choice with the goal.

Translator's note: I was hooked by this text because it reminded me of an old argument with a colleague about how a programmer should relate to product requirements. A colleague argued that the requirement must be implemented verbatim, even if it is incomplete or not optimal. I tried to prove the fallacy of such a formal approach. Perhaps, I thought, this article will add another brick to the clutch of my arguments.

But in the translation process, it became clear that the author was touching on a more complex problem. Often the inertia of thinking leads us to repeat our old decisions over and over again without even thinking about alternatives. What technology to use. How to build a process. Who is responsible for what. We continue to do everything as we used to, without changing anything. Sometimes inertia helps to save strength, but it can also cause pain and discomfort for a long time.

One can always argue with the author’s argumentation, but I think one piece of advice is extremely valuable: do not forget to look up and ask yourself “why am I doing this? Why am I doing it this way?”