[HN Gopher] The Startup Trap (2013)
___________________________________________________________________
The Startup Trap (2013)
Author : sandwichsphinx
Score : 38 points
Date : 2024-12-07 19:00 UTC (3 hours ago)
(HTM) web link (blog.cleancoder.com)
(TXT) w3m dump (blog.cleancoder.com)
| sagolikasoppor wrote:
| 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.
|
| 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.
| rchaves wrote:
| I've seen people spending 10 minutes to test things by hand,
| would have taken them less to write and run a test, specially
| with AI now
|
| When writing test actually makes it faster to code, THEN it's
| worth it. You can even throw the tests away later, doesn't
| matter
| hitchstory wrote:
| If you do test-after you have to keep a mental tally of new
| scenarios to test when making code changes. This makes it more
| unreliable since it's easy to forget one of those scenarios or
| mix it up with an already tested scenario.
|
| TDD lets you safely forget by tying the test pass/failure
| directly to the code.
|
| So, yes, you can do test-after but why?
|
| The only reason Ive ever heard for doing it after anyway is "I
| just prefer it that way".
|
| Not writing tests at all makes sense (e.g. for a spike), but if
| I were going to start writing tests at any point I cant see any
| reason not to do it with TDD.
| ChrisMarshallNY wrote:
| I write tests _alongside_ the code. I also write tests before
| the code, _and_ after the code.
|
| Usually, I use test harnesses[0]. These generally start
| before the code, and grow, alongside.
|
| I'll frequently write unit tests, after the code is done.
| Sort of like putting solder over a tightened bolt.
|
| But I tend to spend a _lot_ of time and effort on testing.
| It's my experience, that I _always_ find issues. I've never
| once, written "perfect" code, out of the starting gate.
|
| Eh. WFM. YMMV.
|
| IRT the post topic, I believe that _every_ job I do -even
| "farting around" code- needs to be done as well as possible.
| If I always do a good job, then it becomes habit.
|
| [0] https://littlegreenviper.com/testing-harness-vs-unit/
| rchaves wrote:
| 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.
|
| 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.
|
| 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.
| rockemsockem wrote:
| Is this what you're talking about?
|
| https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-ex...
| meow_mix wrote:
| Has Robert C. Martin ever started a successful product company?
|
| Nope
|
| So you shouldn't take this advice
|
| https://en.wikipedia.org/wiki/Robert_C._Martin
| dasil003 wrote:
| 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.
|
| 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.
|
| 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.
| rockemsockem wrote:
| I think you are actually agreeing with the main thesis of the
| article, which I agree buries the lede and obfuscates it with
| overly focusing on TDD in particular. You're just adding the,
| accurate, caveat that most people's opinions on how to build
| good software are wrong.
|
| I think that it's true that at large companies there can be an
| obsession with over-design and over-engineering "for scale",
| but I actually think that's wrong to do at large companies too,
| you're just less likely to pay the ultimate price for wasting
| time on it.
| dasil003 wrote:
| The overall article is ambiguous enough that yes, it can be
| interpreted to be in alignment with my values. But also based
| on my quarter century experience in both startups and Fortune
| 500s and the transition from the former to the latter, I
| would say for every engineer shooting from the hip and
| creating an unmaintainable mess there is an equal number who
| will read it as a justification for over-engineering. Also,
| though of course most startups fail, I would say the latter
| archetype fails at a higher rate because they are focused on
| the wrong things.
|
| The crux is really is the nuance of this statement: "The
| disciplines that lead to successful software are always
| valid". This is tautological, everyone reads and sees what
| they want to see. But if we take the examples he gives,
| that's where judgement comes in. Double-entry bookkeeping,
| yes, that's pretty universal. TDD? That really depends on
| what you are doing and what value you get out of it. Not only
| do specific disciplines and practices vary based on company
| stage, they also vary based on the product and the goals of
| the business. Anyone who doesn't understand this is _fucked_
| if they try to do a startup.
| rockemsockem wrote:
| Agreed, but I would say it isn't necessarily tautological.
| I think there are lots of people out there who think that
| if you want to develop software faster you cut corners on
| things like testing (to be clear I'm not endorsing TDD,
| just saying having a reasonable number of tests beats the
| hell out of none), choosing a dynamically typed language vs
| a statically typed one, and just generally throwing code
| over the fence for the sake of moving fast. I think it's
| true that you will in fact move faster over time (not even
| a very long time, just like a few months) if you stick to
| whatever good principles you would have stuck to if you
| didn't have the time pressure of shipping while at a
| startup.
|
| My read was that this was intentionally vague since it's
| basically trying to say to the reader that whatever you
| think is a good idea too do while developing software at a
| non-startup is also a good idea to do at a startup. If the
| reader has bad ideas about developing software then clearly
| there's no helping them :P
| xyzzy4747 wrote:
| 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.
| joshdavham wrote:
| > If you have a zero revenue business you generally shouldn't
| write tests.
|
| Can you think of an industry where this might not be true?
| xyzzy4747 wrote:
| Sure there may be some exceptions. That's why I said
| "generally".
| commondream wrote:
| Naw.
|
| Hopefully, regardless of revenue you test your code. It's just
| a question of if your tests are manual commands and clicks or
| if they're automated.
| joshdavham wrote:
| There are thousands of successful technical startup founders and
| early employees that would disagree with the content of this
| article.
|
| 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).
| impure wrote:
| 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.
| omcnoe wrote:
| It's probably time to stop recommending Clean Code:
| https://qntm.org/clean
|
| 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.
| Etheryte wrote:
| Yeah, the old adage applies that the people making money and
| the people writing books on how to make money are different
| people.
| kristiandupont wrote:
| Also known as "those who can't do, teach".
| peterkelly wrote:
| Why not debate the points in the article on their own merits?
| Which parts do you agree or disagree with, and why?
| dustingetz wrote:
| What notable thing have you done? Don't answer, the question is
| rhetorical. The real lesson is that good contributions can come
| from anywhere, and beauty is in the eye of the beholder. And
| Bob didn't open a time portal from 2013 to post this in 2024,
| so let's leave him out of this.
| trentnix wrote:
| While "Uncle Bob" certainly hasn't uncovered any silver
| bullets, I find the criticism of him to be generally unfair.
| It's the same type of criticism that commonly targets anyone
| that actually sticks their neck out far enough to make concrete
| recommendations.
|
| So many teachers, careful not to invite the ire of the armchair
| critic and ACKCHYUALLY know-it-all, will hem and haw, leading
| you into analysis paralysis regarding "best practices". That
| then leads to exhortations to "find what works best for you",
| acknowledging there are many "right" ways among all the wrong
| ways.
|
| As I've gotten older, I appreciate teachers like Uncle Bob who
| provide a specific prescription and says "try it this way".
| I've discovered I learn faster starting somewhere concrete.
| ldjkfkdsjnv wrote:
| 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.
|
| 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
| henning wrote:
| 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.
|
| Worse than useless.
| abc-1 wrote:
| Has Uncle Bob even written a single line of code in 20 years? And
| the stuff he did produce 20 years ago wasn't particularly
| impressive.
| zug_zug wrote:
| Tests are less useful on features that may be canceled soon.
|
| Tests are more valuable on more complex codebases.
|
| Local tests (shifting left) is more valuable when deploying is
| hard/infrequent and screwing up prod has higher stakes.
|
| These factors explain why most startups should code differently
| than big corps.
| willswire wrote:
| Slow is smooth, smooth is fast.
| TZubiri wrote:
| "To quote Captain Sulu when the Klingon..."
|
| Easy skip of a read
___________________________________________________________________
(page generated 2024-12-07 23:00 UTC)