Not true. Kent Back’s 3X is a much better take, test and good practices for what is high risk and hard to change, move fast for most of it on the rest to try to find that black swan as soon as possible.<p>Yes, I do feel this time is different and that I am a top-notch coder (I feel more comfortable sounding like a jerk when on hackernews), 1 year later into my startup, codebase is big, but I’m actually coding faster than ever, as foundation code is more and more complete.<p>One of the huge reasons for it beyond the right architecture is type safety. Someone that was well seasoned in strongly-typed FP but is now pragmatic can move incredibly fast with enormous safety by just adding the most cost-benefit type strictness, and being flexible on where it doesn’t pay off.
Oh man. You can write tests after the fact. I have done it sucessfully many times. I write something to see if its viable, if it is I find the repetitive parts and break them up to functions or components in which you can unit test. Later you can also write end to end tests for all the important flows.<p>TDD is just a way of doing things but it's not faster. It's testing for testings sake. Why should I write a test if I don't have a single paying customer yet? Unless its something massively important, like money or health data there is just little incentives.
There are thousands of successful technical startup founders and early employees that would disagree with the content of this article.<p>The truth is that, it's actually totally fine to accumulate some amount of technical debt and to ship some buggy code if you're still early. Speed matters. Of course this will change if you're later stage or if you're in an industry where you must be very careful (security, healthcare, gov, etc).
> <i>Is your code somehow less important than that account’s spreadsheets?</i><p>Shout-it-from-the-mountain-top "yes!"<p>The code should just get you through a demo, or securing the next round of financing.<p>The accountant can't cut corners, because they and other people could go to jail.<p>But the idea that prototyping in software is not a valid practice is laughably wrong.<p>Where you do go wrong is if the people <i>only</i> know how to prototype and nothing else; they can't get rid of the prototypey bits and evolve it into solid production in which all traces of prototyping are gone. Multi-talented mega-begins which know numerous methodologies wouldn't be in this boat, right?<p>> <i>as if any bug is acceptable</i><p>Windows still crashes in 2024, yet we can't get rid of it.
This article buries the lede with a bunch of horrendous strawmen. The actual thesis is that software craftsmanship should be applied in the same way at all stages of a company. This is a very dangerous line of thinking that has killed many a startup staffed by experienced who engineers who are working in large scale systems and teams. I've seen it many times, and TBH it's not just an engineering problem, it's that people who have only worked in large companies don't have a real sense of what is truly essential, and so a huge percentage of their practices are effectively cargo culted over without any real reflection.<p>In the case of engineering, you need to apply a lot of judgement based on the situation that the company is in—how much runway, how much traction, actual product goals, etc. You must keep things as simple as possible at all times to optimize for future optionality as you search for product-market fit. All code is a liability, and you must fight tooth and nail against any individual who is getting ahead of their skis in terms of losing focus on the next thing needed to prevent the company from dying. The absolute worst thing you can do is bring some journeyman engineer and don't give them enough scope and ownership to satisfy their brain capacity or you'll end up with ridiculously over-engineered systems that impose a huge velocity tax for what needs to be a very lean and agile phase. I say this disclaimer first because 99% of people in tech trying to do a startup will fail by trying to do too much too soon, and have no intuitive sense of how narrow the tightrope from 0 to 1 success really is.<p>Of course that doesn't mean you shouldn't focus on code and system quality. Absolutely you should have tests, but you should apply serious judgement onto the nature of the tests in light of your best predictions about the future. You should think about what code is foundational, and what decisions may be one way doors, but not obsess over leaf nodes and experiments that are just as likely to be abandoned or scrapped as they are to be built upon. Making these calls is tough—no one can predict the future—but long tenures in fast growing code bases helps. Seeing the impact of ones decisions 2, 5, 10 years down the line is eye opening, experience is useful here as long as one still thinks from first principles and doesn't just rely on rote practices because they are comfortable.
For a startup achieving product market fit should be the primary objective, clean code is secondary. And honestly, a lot of the things that Robert Martin proposes are quite controversial and I’m not sure if I would recommend them for a more developed company.
Actually, people will use buggy software if it solves a real problem. If you need to polish your software to the nth degree to get and retain customers, you are in a crowded space and should go do something else with your life.<p>If chatgpt failed 50% of its requests from the UI, people would still use it. If it logged you out after every other chat request, people would still use it
Zero evidence, just stating the same unproven argument as fact over and over. Also directly countered by how much commercially successful/widely adopted software has fucking awful dogshit code.<p>Worse than useless.
Startups <i>aren't</i> magically different.<p>But they are the same as anywhere else in a very different way than described here.<p>At almost any place (other than a company that only writes moon lander code, or similar) you will probably encounter many different situations over your career.<p>Sometimes quality is crucial and it's better to be late than buggy or wrong.<p>Sometimes timeline in crucial and your users are willing to be more in the "beta tester" role as long as they get that first version quickly.<p>Sometimes the product shape isn't quite clear yet so timeline (to iterate with real users) and future extensiblity/adaptability are both super important.<p>Sometimes you can only afford the 6 month effort, financially. Having less tech debt won't help you if you ship nothing and make no money.<p>Sometimes you won't need to add many more features in the future, so certain kinds of "tech debt" are fine.<p>But there's no one-size-fits-all approach to software engineering across all these situations. Heck, it's often hard to tell with full certainty which situation you're in - predicting the future is hard.<p>However, any approach that doesn't start with "what do we need, and what do we think the right set of tradeoffs are" is likely to let you down. Since there's no freebies here - "discipline" in the "follow the checklist 100% every time every where" sense is not free.<p>Funny thing about the harping on TDD is that one of the real tricks is that if you don't know the situation, you <i>can't even write the right tests</i>. If the features/functionality is gonna churn, you need to be careful how you write your tests so you aren't constantly rewriting them by testing volatile boundaries of functionality. But that's very different from "TDD good, slow good, fast bad."
Article's premise:
- software development practices are invariable to company size and stage<p>Reality:
- team size dominates methodology and user base size dominates architectural decisions
Tests are less useful on features that may be canceled soon.<p>Tests are more valuable on more complex codebases.<p>Local tests (shifting left) is more valuable when deploying is hard/infrequent and screwing up prod has higher stakes.<p>These factors explain why most startups should code differently than big corps.
This post sears and burns with the heat of a thousand suns. How I wish I could have read this every day, ten times a day, as I was starting out on my startup journey three years ago.<p>So many corners were cut in the name of speed. So much pressure from my cofounder/investor to get things out way too fast. So many months of endless suffering and never-ending bugs due to poor architecture that doesn’t scale on the BE.<p>I know how to push back. I do it for a living at my day job and I’m really good at it. For some reason I decided that I couldn’t ever push back against the guy who put in some money. How horribly wrong I was.
Note: There is apparently a large group of people who hate everything he does and also, seemingly, him personally. Everywhere he (or any of his books) is mentioned, the haters come out, with their vague “it’s all bad” and the old standard “I don’t know where to begin”. Serious criticism can be found (if you look for it), and he himself welcomes it, but the constant vague hate is scary to see.
It's probably time to stop recommending Clean Code: <a href="https://qntm.org/clean" rel="nofollow">https://qntm.org/clean</a><p>I don’t want to be a hater but a lot of “Uncle Bob’s” advice just doesn’t seem very good, this article included. Robert has had a long and successful career writing books on code style and architecture diagrams, but he hasn’t built anything notable in industry during that period. And the opinion presented here seems to clash with nearly everybody who has ever actually built a successful startup. Some things you have to learn by doing.
Has Robert C. Martin ever started a successful product company?<p>Nope<p>So you shouldn't take this advice<p><a href="https://en.wikipedia.org/wiki/Robert_C._Martin" rel="nofollow">https://en.wikipedia.org/wiki/Robert_C._Martin</a>
If you have a zero revenue business you generally shouldn't write tests. Just add some health checks for backend services and use strongly typed code for everything.