Goals against restrictions

The classic source of stress and dysfunctions in development teams — indeed, in any teams — is a confusion between goals and constraints.

Teams often mistakenly take restrictions for goals. A typical example: a team accepts product requirements for its goal, losing sight of the real needs that originally engendered these requirements.

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

I saw a lot of technical startups who lost sight of what, how and why they were doing, and were falling into a 100 percent focus on getting the money needed solely to maintain the current state of affairs. This happens very often. Think of all these charitable foundations that began with a clear goal (relatively speaking, “save the cat”), but after a few years, it turns out that most of their efforts - if not all - are aimed only at finding money to pay everyone a salary and continue to "charity".

Of course, you can argue to me that making money is the task of a business, and this money is a payment for the fact that a business solves the problems of users. The purpose of the restaurant is to make money. The purpose of dinner is to be eaten. I give you money. You will satisfy my hunger.

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

This idea of ​​business comes from the XIX century. But even then there were progressive industrialists who set goals greater than just making a profit. At its best, the company can create meaning and purpose for its employees, enrich their lives and the life of the community, and add attractiveness to the surrounding landscape.

But I got distracted. Where did I stay? Oh yes. Goals against restrictions.

Imagine you are planning a trip from your Los Angeles home 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 gasoline for the entire trip.

You decide to make money on gas. To do this, you start to make lemonade and sell it in a kiosk near your home. Things are going well. People like your lemonade, and, thanks to the convenient location of your house, there are always a lot of passersby around him who have to quench their thirst. Soon, money for gasoline is more than enough. But the sale of lemonade goes so briskly that you are just busy thinking about it, and not about San Francisco. You are planning to add fresh 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 buy a new house on the same street, larger and with a more spacious courtyard. Then you start delivering your drinks to local restaurants when they lack their own. After 10 years, you run your own network of lemonade kiosks throughout the city.

In the meantime, you have not been to San Francisco. And now you are too busy, so you will hardly find time to go there sometime.

Now, if you are a hardened capitalist, you can say: "so what?" Is your lemonade business a worthy compensation for lost travel?

Maybe yes and maybe not. As I get older and older, I 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 received this experience, never created a home recording studio, never could learn a foreign language ... and do everything else that was in their plans .

For most of us, equally people and organizations, the need to make money is a reality that you can never get rid of. This is a constraint that can help or hinder us in achieving our goals.

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

Therefore, I believe that there is a need to find a 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.

Too much binding to restrictions limits our chances of achieving goals.

Restrictions limit. This is their essence. For example, if we limited ourselves to one particular route from Los Angeles to San Francisco, and halfway through found that the road was blocked, then we would have to look for other ways to reach the destination.

I have repeatedly seen how teams smashed their heads against the walls, trying to realize the requirements that for some reason could not be met. It was too difficult to just take a step back and remind myself what goal they wanted to achieve, ask themselves "is there another way?". I have seen many millions of dollars of projects fail because no other path has been seen. This should be Oracle. This should be Java. This should be a web service.

Not. Should not. Most of the constraints we face are in fact someone’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 choice with purpose.

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 should be implemented literally, 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 laying of my arguments.

But in the process of translation, it became clear that the author addresses a more complex problem. Often the inertia of thinking leads to the fact that we 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 power, but it can also cause pain and discomfort for a long time.

One can always argue with the author's arguments, but I consider one piece of advice to be extremely valuable: do not forget to raise your head and ask yourself "why am I doing this? Why am I doing it that way?"