- You have joined a new startup.
- You are a megatalented creature.
- 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 traps that others fall into.
- You will see that this time everything will be different.
- You are so good that you don't need the rules.
- You are in the ass .
We are witnessing this sad story over and over again. A young programmer begins his journey with good intentions, studies the right approaches, develops the right habits, and then becomes a victim of the Startup Trap . A start-up trap is the idea that your situation is different, that everything that you know about how to make software for some reason does not need to be applied to this particular job. 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 . itstupid . 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 they treat the rules in the same way as during the startup phase. Perhaps, with the exception of processing. (hee hee).
Here's a little hint: the disciplines that help you create successful software always work, no matter 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 the practices that I'm talking about is TDD. Everyone who says that he can move fast due to the fact that he does not write tests carries complete garbage. Oh yes, I know that you are a god. I know that you can write perfect code every day. I know that the deadline looms ahead, and you just don't have time to write tests . And I regret your imminent failures. I regret that you are moving slowly, and so far you simply don’t know about it. And I am very sorry that when you finally, with grief in half, achieve at least some success that you attribute to your bad actions, you will recommend these actions to others. And God help us.
Ask yourself: how does an accountant work in a startup? This person is responsible for the money of investors. Do you think he has deadlines? Is he under pressure when making forecasts, making cash flow statements and the like? Do you think his bosses are failing to meet deadlines? So I’ll tell you: the dude who manages the money of investors is experiencing much more pressure than any software developer.
So how does an accountant behave? Does he check all amounts twice? Does it use double entry? Does it 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 youHave you thought of an accountant who does not check the amount, who does not look at the debit, but trusts the health and future of your company with unverified loan amounts?
You would kick his ass! You would have kicked it so fast that the rest of his body would have stood outside the door and wondered where his ass had gone!
So, is your code less important than accounting records? Are code errors less important than errors in those entries? Can errors in the code lead to the decline of the company, 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 it help you move fast? I will quote Captain Sulu’s response to the young Lieutenant who asked if the fleet should be notified when the Klingon moon Praxis exploded: “Are you kidding?” Are you kidding?
NO, you will not move fast. You will move slowly . The reasons are simple, and you know them. You will move slowly because you cannot refactor. Your code will begin to rot - and very quickly. It will become harder and harder to change. And you will begin to 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 for the code. You are making great efforts, and the movement feels fast.
But effort and speed are in no way connected. It’s easy to make a lot of efforts and not achieve the result. Damn , it’s easy to hell up and get a negative result. Efforts cannot be equated to either speed or result.
Over time, your grades will grow. It will become harder and harder to add new features. More and more errors will accumulate. You will begin to divide them into critical and acceptable (as if acceptable errors exist!). You will create modules so fragile that you will not entrust changes to them to yourself or to others. So you will begin to write “crutches”. You will build a rotting bunch of code that will require more and more effort just to keep working. Your movement will slow down. Or it may 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 eliminating the consequences will take a huge amount of time.
You know what I mean. You know that people run into this. If you are old enough, you yourself may have run into this once or twice. 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 handle all the deadlines. If you need the biggest chance of success. Then I can not give you better advice than this: Follow the disciplines! Write tests. Refactor. Keep your code simple and clean. Do not hurry! The essence of a startup is in your hands. Do not be careless!
Remember:The only way to move fast is to move correctly.
From a translator : Uncle Bob has been encouraging developers for professional behavior for quite some time now, and the industry as a whole for growing up. He writes books on this subject, for example, “Principles, Patterns and Techniques of Agile Development in C #” and “Ideal Programmer” ; makes presentations, for example, The Reasonable Expectations of Your CTO and Demanding Professionalism (minutes from the 20th); writes articles like this one. I strongly recommend that you familiarize yourself with his thoughts in more detail.