Startup trap

• You have joined a new startup.
• You are a mega talent creation.
• You can work 60, 70, 80 hours a week to achieve results.
• You are an awesome developer and designer.
• You will not fall into the trap into which others fell.
• You will see that this time everything will be different.
• You are so good that you don't need any rules.
• You in the ass .

Startup trap.

We see this sad story time after time. A young programmer starts his way with good intentions, learns the right approaches, develops the right habits, and then becomes a victim of the Startup Trap . A start-up trap is the thought that your situation is different, that everything you know about how to make software does not need to be applied to this particular job for some reason. You think that you will apply all this later when you succeed. But not now. Not. At least while you're chasing success.

A startup trap is the idea that the startup phase is different ; and that in this phase success does not depend on compliance with the rules, but on their violation . This is stupid . The startup phase is no different. This is just the first of several phases, and it sets the tone for all other phases. Look at such a company five years later (if it exists at all), and you will see that it refers to the rules in the same way as during the startup phase. Perhaps, with the exception of recycling. (hee hee).
')
Here's a little hint: the disciplines that help create successful software always work, regardless of what phase the company is in. It is ridiculous to think that good practices are less important during the startup phase. The truth is that during the startup phase, these practices are just as critical as in any other period.

Of course, one of these practices I’m talking about is TDD. Anyone who says that he can move quickly due to the fact that he does not write tests, bears full garbage. Oh yes, I know you are a god. I know that you can write the perfect code every day. I know that the deadline is ahead, and you simply do not have time to write tests . And I regret your inevitable failures. I regret that you are moving slowly, and so far you just do not know about it. And I very much regret that when you at last with grief in half achieve at least some success that you attribute to your bad actions, you will recommend these actions to others. And may God help us.

Ask yourself the question: how does an accountant act in a startup? This person is responsible for investor money. Do you think he has deadlines? Is he under pressure when making forecasts, making cash flow reports and the like? Do you think his bosses suffer deadlines? So I'll tell you: the dude who manages the money of investors is under a lot more pressure than any software developer.

So how does an accountant behave? Does he check all amounts twice? Does he use double entry? Does he follow all the rules and practices? And do these rules differ only because the startup phase is now?

Imagine that this is your company and your money. What would you think about an accountant who doesn’t check amounts that doesn’t look at debits, but trusts the health and future of your company for untested loan amounts?

You would kick his ass! You would kick her out so fast that the rest of his body would stand outside the door and think about where his ass went!

So, is your code less important than accounting entries? Are errors in the code less important than errors in those records? Can mistakes in the code lead to the decline of the company, to destroy its reputation among customers and investors? You know the answers to these questions. And you know that if accountants can follow their disciplines in startups, then you can .

If you score on TDD, will that help move fast? I will quote Captain Sulu’s reply to the young Lieutenant, who asked if the fleet should be notified when the Klingon moon Praxis exploded: “Are you kidding?” Are you joking?

NO, you will not move fast. You will move slowly . The reasons are simple, and you know them. You will move slowly because you will not be able to refactor. Your code will start to rot - and very quickly. It will become harder and harder to change. And you will move slowly .

At first you will not notice this, because it will seem to you that you are moving fast. You work a lot and spend 60, 70, 80 hours a week by code. You make great efforts and the movement feels fast.

But effort and speed are unrelated. It is easy to make a lot of effort and not achieve a result. Damn , easy to spend to hell of an effort and achieve a negative result. Efforts cannot be equated to either speed or result.

Over time, your scores will increase. It will become harder and harder to add new features. More and more mistakes will accumulate. You will begin to divide them into critical and acceptable (as if there are acceptable mistakes!). You will create such fragile modules that you will not entrust changes in them to yourself or to others. So you start writing "crutches". You will build a rotting pile of code that will require more and more effort just to keep working. Your movement will slow down. Or maybe even go in the opposite direction, because each new version will contain more and more errors, and will be less and less stable. Disasters will become commonplace, as well as mistakes that should never have happened. And the elimination of the consequences will take a huge amount of time.

You know what I mean. You know that people are messing about this. If you are years old enough, you yourself may have snuggled this time or two. However, the startup trap still sings its siren songs and lures you into destructive, slow, catastrophic behavior.

If you want to move fast . If you want to cope with all deadlines. If you need the biggest chance of success. Then I can give you no better advice than this: Follow the disciplines! Write tests. Do refactoring. Keep the code simple and clean. Do not hurry! In your hands the essence of a startup. Do not be careless!

Remember: The only way to move fast is to move correctly.

From the translator : Uncle Bob has been calling developers for professional behavior for quite a long time, and the industry as a whole - for growing up. He writes books on this topic, for example, “Principles, Patterns and Agile Development Techniques in C #” and “Ideal Programmer” ; delivers reports, for example, The Reasonable Expectations of Your CTO and Demanding Professionalism (minutes from the 20th); writes articles like this one. Strongly recommend to get acquainted with his thoughts in more detail.