https://blog.cleancoder.com/uncle-bob/2013/03/05/TheStartUpTrap.html [clean_code] The Clean Code Blog by Robert C. Martin (Uncle Bob) atom/rss feed --------------------------------------------------------------------- * Functional Classes in Clojure 01-19-2023 * Functional Classes 01-18-2023 * Space War 11-28-2021 * Functional Duplications 10-28-2021 * Roots 09-25-2021 * More On Types 06-29-2021 * On Types 06-25-2021 * if-else-switch 03-06-2021 * Pairing Guidelines 01-17-2021 * Solid Relevance 10-18-2020 * Loopy 09-30-2020 * Conference Conduct 09-23-2020 * The Disinvitation 09-12-2020 * REPL Driven Design 05-27-2020 * A Little More Clojure 04-09-2020 * A Little Clojure 04-06-2020 * A New Hope 04-05-2020 * Open Letter to the Linux Foundation 11-08-2019 * What They Thought of Programmers. 11-03-2019 * Circulatory 10-31-2019 * Why Clojure? 08-22-2019 * Why won't it... 07-22-2019 * Classes vs. Data Structures 06-16-2019 * Types and Tests 06-08-2019 * 737 Max 8 05-18-2019 * FP vs. OO List Processing 12-17-2018 * We, The Unoffended 12-16-2018 * SJWJS 12-14-2018 * The Tragedy of Craftsmanship. 08-28-2018 * Too Clean? 08-13-2018 * Integers and Estimates 06-21-2018 * Pickled State 06-06-2018 * Craftsman, Craftswoman, Craftsperson 05-02-2018 * FP vs. OO 04-13-2018 * In The Large 04-02-2018 * We Programmers 03-29-2018 * Uncle Bob Fly-In. Have I got a deal for you! 02-25-2018 * The Citizenship Argument 01-18-2018 * Operating Behind the Power Curve 01-15-2018 * Excuses 12-18-2017 * Dbtails 12-09-2017 * Bobby Tables 12-03-2017 * Living on the Plateau 11-18-2017 * Women In Demand 10-04-2017 * Tools are not the Answer 10-04-2017 * Test Contra-variance 10-03-2017 * The Unscrupulous Meme 09-29-2017 * Sierra Juliet Foxtrot 09-26-2017 * Just Following Orders 08-28-2017 * Women in Tech 08-14-2017 * On the Diminished Capacity to Discuss Things Rationally 08-10-2017 * Thought Police 08-09-2017 * The Brain Problem 07-28-2017 * Drive me to Toronto, Hal. 07-24-2017 * Pragmatic Functional Programming 07-11-2017 * First-Class Tests. 05-05-2017 * Is Dr. Calvin in the Room? 03-16-2017 * Symmetry Breaking 03-07-2017 * Testing Like the TSA 03-06-2017 * TDD Harms Architecture 03-03-2017 * Necessary Comments 02-23-2017 * Types and Tests 01-13-2017 * The Dark Path 01-11-2017 * TDD Lesson - Terrain Generation 01-09-2017 * TDD Doesn't Work 11-10-2016 * Dijkstra's Algorithm 10-26-2016 * The Lurn 09-01-2016 * The Churn 07-27-2016 * Mutation Testing 06-10-2016 * Blue. No! Yellow! 05-21-2016 * Type Wars 05-01-2016 * Giving Up on TDD 03-19-2016 * Manhandled 01-15-2016 * Stabilization Phases 01-14-2016 * A Little Architecture 01-04-2016 * Prelude to a Profession 11-27-2015 * The Programmer's Oath 11-18-2015 * The Force of Pliers 11-01-2015 * Future Proof 10-30-2015 * Agile is not now, nor was it ever, Waterfall. 10-16-2015 * VW 10-14-2015 * WATS Line 54 10-05-2015 * A Little Structure 09-23-2015 * Make the Magic go away. 08-06-2015 * Pattern Pushers 07-05-2015 * The Little Singleton 07-01-2015 * The First Micro-service Architecture 05-28-2015 * Language Layers 04-27-2015 * Does Organization Matter? 04-15-2015 * The MODE-B Imperative 02-21-2015 * They Called them Computers. 02-19-2015 * 'Interface' Considered Harmful 01-08-2015 * The Cycles of TDD 12-17-2014 * OO vs FP 11-24-2014 * Thorns around the Gold 11-19-2014 * The Obligation of the Programmer. 11-15-2014 * One Hacker Way! 11-12-2014 * Laughter in the male dominated room. 10-26-2014 * GOML-1, Responsive Design 10-08-2014 * Clean Micro-service Architecture 10-01-2014 * Microservices and Jars 09-19-2014 * The More Things Change... 09-18-2014 * Test Time 09-03-2014 * A Little About Patterns. 06-30-2014 * My Lawn 06-20-2014 * Is TDD Dead? Final Thoughts about Teams. 06-17-2014 * First 05-19-2014 * The Little Mocker 05-14-2014 * The Open Closed Principle 05-12-2014 * Framework Bound[2] 05-11-2014 * When to Mock 05-10-2014 * The Single Responsibility Principle 05-08-2014 * Professionalism and TDD (Reprise) 05-02-2014 * Test Induced Design Damage? 05-01-2014 * When TDD doesn't work. 04-30-2014 * Monogamous TDD 04-25-2014 * Code Hoarders 04-03-2014 * The True Corruption of Agile 03-28-2014 * When Should You Think? 03-11-2014 * A Spectrum of Trust 02-27-2014 * Oh Foreman, Where art Thou? 02-23-2014 * Where is the Foreman? 02-21-2014 * The Domain Discontinuity 01-27-2014 * Coding in the Clink (9) 01-20-2014 * Extreme Programming, a Reflection 12-10-2013 * Novices. A Coda 11-25-2013 * Hordes Of Novices 11-19-2013 * Healthcare.gov 11-12-2013 * The Careless Ones 10-24-2013 * Dance you Imps! 10-01-2013 * A.T. FAIL! 09-26-2013 * Test First 09-23-2013 * Transformation Priority and Sorting 05-27-2013 * The Transformation Priority Premise 05-27-2013 * Flash - TPP 05-27-2013 * Fib. The T-P Premise. 05-27-2013 * There are Ladies Present 03-22-2013 * The Frenzied Panic of Rushing 03-11-2013 * An Open and Closed Case 03-08-2013 * The Pragmatics of TDD 03-06-2013 * The Start-Up Trap 03-05-2013 * The Principles of Craftsmanship 02-10-2013 * The Humble Craftsman 02-01-2013 * The Laborer and the Craftsman 01-30-2013 * FP Basics E4 01-29-2013 * FP Basics E3 01-07-2013 * FP Basics E2 01-02-2013 * Brave New Year 12-29-2012 * FP Basics E1 12-22-2012 * Three Paradigms 12-19-2012 * The New CTO 09-06-2012 * Functional Programming for the Object Oriented Programmer 08-24-2012 * The Clean Architecture 08-13-2012 * NO DB 05-15-2012 * Why is Estimating so Hard? 04-20-2012 * After the Disaster 04-18-2012 * Service Oriented Agony 02-01-2012 * The Ruby Colored Box 01-31-2012 * Fecophiles 01-20-2012 * The Letter 01-12-2012 * Flipping the Bit 01-11-2012 * The Barbarians are at the Gates 12-11-2011 * Clean Architecture 11-22-2011 * Double Entry Bookkeeping Dilemma. Should I Invest or Not? 11-06-2011 * Simple Hickey 10-20-2011 * Screaming Architecture 09-30-2011 * Bringing Balance to the Force 01-19-2011 * What Software Craftsmanship is about 01-17-2011 The Start-Up Trap 05 March 2013 * You have joined a new startup. * You are a multi-talented mega-being. * You can work 60, 70, 80 hours per week to get the job done. * You are a top-notch coder and designer. * You won't fall into the traps that others have fallen into. * You will make sure that this time will be different. * You are so good that the rules don't apply to you. * You are fucked. ###The Start-Up Trap. It's a sad story that we've seen over and over again. A young programmer begins with all the best intensions, learns all the right disciplines, develops all the right skills, and then falls prey to The Start-Up Trap. The Start-Up Trap is the idea that your situation is different - that everything you've learned about how to do software well somehow doesn't apply to this particular job. You think it will apply later, once you've succeeded. But not now. Not yet. Not while you are in a race to succeed. The Start-Up trap is the thought that the start-up phase is different ; and that while you are in that phase success depends upon breaking the rules. This is stupid. The start-up phase is not different. The start-up phase is simply the first of many phases, and it sets the tone for all those other phases. Come back to that company in five years and (if they've managed to survive) they'll still have the same attitude towards the rules that they had in the first phase - except, perhaps, for the overtime. (giggle). Here's a little tip: The disciplines that lead to successful software are always valid, no matter what phase the company is in. It is laughable to think that good disciplines are less important during the start-up phase. The truth is that, during the start-up phase, those disciplines are just as critical as they are at any other time. Of course one of the disciplines I'm talking about is TDD. Anybody who thinks they can go faster by not writing tests is smoking some pretty serious shit. Oh, I know you are a warrior-god. I know you can write the code perfectly every time. I know that the deadline looms and you just don't have time to write tests. - I'm sorry for your impending failures. I'm sorry that you're going slow and just don't know it yet. And I'm very sorry that when you finally brute-force your way to some modicum of success that you will credit your bad behavior, and recommend it to others. God help us all, because you won't. Ask yourself this: How does the accounting officer of a start-up behave? This person is responsible for managing the money of the investors. Do you think that accountant has deadlines? Do you think he's under pressure to deliver projections, forecasts, cash-flow reports, etc? Do you think his bosses tolerate schedule slips in his duties? I'll tell you now that the guy managing the investors' money is under a hell of a lot more pressure than any software developer is. So how does this accountant behave? Does he double check his work? Does he practice double-entry bookkeeping? Does he follow all his rules and disciplines? Or are the rules different because he's in the start-up phase? What if it was your company, and your money. What would you think of a start-up accountant who didn't check his sums; who neglected the debit side of the books and trusted the health and future of your company to the single unchecked sums of the credit side? You'd fire his ass! You'd fire it so fast that the rest of his worthless carcass would be left outside the door wondering where his ass went! Is your code somehow less important than that account's spreadsheets? Are errors in the code somehow more tolerable than errors in those spreadsheets? Can errors in the code take the company down and ruin it's reputation with it's customers, and investors? You know the answer to these questions. And you know this: If accountants can find a way to practice their disciplines in a start-up; so can you. Is neglecting TDD going to help you go fast? To quote Captain Sulu when the Klingon power moon of Praxis exploded and a young Lieutenant asked whether they should notify Star-Fleet: "Are you kidding?" ARE YOU KIDDING? NO, you aren't going to go fast. You're going to go slow. And the reasons are simple, and you already know them. You're going to go slow because you won't be able to refactor. The code will rot - quickly. It will get harder and harder to manage. And you will slow down. You won't notice it at first because it still feels fast. You are working hard and spending 60, 70, 80 hours per week on the code. The sheer effort you are applying is enormous; and that feels fast. But effort and speed are not related. It is easy to expend a tremendous amount of effort and make no progress at all. Hell, it's easy to expend gargantuan effort and make negative progress. Effort equates neither to speed nor direction. As time passes your estimates will grow. You'll find it harder and harder to add new features. You will find more and more bugs accumulating. You'll start to parse the bugs into critical and acceptable (as if any bug is acceptable!) You'll create modules that are so fragile you won't trust yourself, or anyone else, to modify them; so you'll work around them. You'll build a festering pile of code that, with every passing week, requires more and more effort just to keep running. Forward progress will slow and falter. It may even reverse as each release becomes buggier and buggier, and less and less stable. Catastrophes will become more and more common as errors, that should never have happened, create corruptions and damage that take huge traunches of time to repair. You know the story. You know this is where others have wound up. If you are old enough, you have probably wound up there once or twice yourself. And yet that Start-Up Trap still sings it's siren song and lures you into destructive, slow, catastrophic behaviors. If you want to go fast. If you want the best chance of making all your deadlines. If you want the best chance of success. Then I can give you no better advice than this: Follow your disciplines! Write your tests. Refactor your code. Keep things simple and clean. Do Not Rush! You hold the life-blood of your start-up in your hands. Don't be careless with it! Remember: The only way to go fast, is to go well.