[HN Gopher] A development process startup founders should use to...
___________________________________________________________________
A development process startup founders should use to ship features
weirdly fast
Author : gmays
Score : 26 points
Date : 2022-09-12 21:08 UTC (1 hours ago)
(HTM) web link (growing-products.paralect.com)
(TXT) w3m dump (growing-products.paralect.com)
| tomasreimers wrote:
| > Break features into small, incremental changes
|
| Stacking is a wonderful workflow to accomplish this:
| https://graphite.dev/blog/post/N8SOs49y4bYdV1Vjf5qE
| andrewstuart wrote:
| Startup founders should be explicitly telling their developers to
| not write tests, not use CI/CD, not use feature branches.
|
| All that stuff can come after you have proven your software makes
| money / users want to use it.
|
| Just get the damn thing written in the quickest, most crappy way
| necessary for speed.
|
| The code doesn't need to be organised well. It doesn't need to be
| documented.
|
| The only thing that matters is to do your best to avoid security
| holes.
|
| No tests. Stop testing, apart from manual runthroughs that the
| CEO can do in between trying to raise funding.
|
| My eyes roll when I hear of startups creating "good processes"
| for development at any level, let alone CI/CD and tests.
| pier25 wrote:
| I totally agree. Stop thinking like a developer, think like a
| business owner.
|
| Build the MVP so that it's good enough to start solving
| whatever it is you're solving and get your first customers.
|
| If you can't get customers, what's the point of having a
| sophisticated codebase with tests, etc?
| agrippanux wrote:
| I hear ya; you're not off on most of this. However if you're
| building a web service, Vercel (and its kin) make CI/CD
| ridiculously easy. Easy as in like 5 minutes easy, and it's
| worth the 5 minutes for the all the benefits.
| alasdair_ wrote:
| Feature branches are fine. Just merge master into your branch on
| a daily basis and the concerns about merging go away.
| x3n0ph3n3 wrote:
| I couldn't disagree more with what they say about feature
| branches.
|
| > merging the feature branch with the main branch takes a lot of
| time
|
| Why would that be the case? `git merge` is not a slow and
| expensive process. Is the problem the per-branch code review
| process that teams often engage in? They didn't even discuss how
| code is reviewed (feature demos are not code reviews).
|
| > when the feature is done, merging branches back might lead to
| new bugs and instability
|
| Feature branches should regularly be pulling in changes from the
| main branch. This seems like it would be a problem whenever your
| local main gets behind the upstream main, either way. Lots of
| teams will squash changes before merging feature branches, and
| run the test suite on it before it's merged.
|
| > it is more difficult to do incremental refactoring
|
| Smaller PRs and feature branches.
|
| There have been a few posts lately espousing the removal of
| workflows that have evolved over time to solve real problems in
| development practices. To me, it seems like a lot of cowboy
| coders not wanting to be constrained by sustainable development
| methodologies.
| P5fRxh5kUvp2th wrote:
| I've seen feature branches attacked a lot and the common
| refrain is always the same. They live for weeks and then are
| hard to merge back in.
|
| This is why you should be merging main back into your feature
| branch daily, so imo this is just a strawman.
|
| That's assuming it's not reasonable to have smaller features.
| Sometimes it's not. You should strive for feature branches that
| live for a day or two, but if you MUST have it longer, just
| merge back in.
| dr_dshiv wrote:
| " We created and use Growthflags to implement feature flags. "
| peter422 wrote:
| > tests are great in the long run, but can slow you down in the
| short run.
|
| This is just silly, especially given you mention freezing
| releases and having an entire QA team go over the product. It
| would be much faster to have no QA team, no freezing of releases
| and instead have a robust test infrastructure.
|
| It's fine that this set of rules works for your company, you like
| them and are familiar with them, but that's all this list is.
| threeseed wrote:
| The context is that of an early stage startup.
|
| At that point most products are basic enough for developers to
| test the product themselves.
|
| And if the codebase is undergoing lots of churn and heavy
| refactoring then tests unquestionably will slow you down.
|
| Maybe it is better to only begin automated tests when you reach
| product-market-fit.
| BurningFrog wrote:
| A good test suite is a _huge_ project asset!
|
| It also requires considerable skill to build and maintain, and
| not every team has that...
|
| ...in which case you might have a less good and useful test
| suite.
| solarmist wrote:
| I'll give you a case where this is true if you're prototyping
| something new and need to keep changing fundamental things like
| the data model.
|
| I have nearly 100% unit test coverage for a couple of the base
| libraries I've created, but yeah, writing tests was slowing me
| down significantly for the rest.
|
| Once I have something where chunks of the application aren't
| being scrapped every other week, I'll start adding unit tests
| to it too.
| spyspy wrote:
| I think the author is just saying not to have draconian testing
| requirements for every PR like some companies do.
|
| But really, I can see it. Firstly, a lot of engineers suck are
| writing tests. White box unit tests with interfaces and mocking
| everywhere tightly couple code blocks together. Integration
| tests are nice but take a lot of effort to get right while also
| keeping them performant. When (not if, remember we're talking
| about an early stage company) the codebase and/or the database
| schema changes dramatically it will often break the tests which
| is just another hangup.
| neeh0 wrote:
| > This is just silly,
|
| I think it is silly to use this one sentence without a context
| and start arguing. The whole paragraph in the article makes
| sense, gives context and advice is reasonable.
| thijser wrote:
| This sounds a lot like trunk based development: feature flags,
| incremental changes, no long-lived feature branches.
|
| I think better tooling around git will help a lot with speeding
| up development teams.
| ramesh31 wrote:
| > Avoid Feature Branches
|
| This is a big one. It seems the industry (at least to my
| awareness) has almost totally rejected Gitflow for trunk based
| development in the last few years. It's a beautiful idea in
| theory, but a complete headache in reality.
|
| > Use feature flags
|
| Be careful here. Adding feaure flags means you now effectively
| have N^N builds (where N is the number of flags) in production,
| each with their own possible quirks and integration issues. Keep
| them to an absolute minimum, and remove them as soon as possible.
| milosmns wrote:
| Wait why N2 and not 2.pow(n)?
| P5fRxh5kUvp2th wrote:
| gitflow is not feature flow, that seems to be a common
| misunderstanding.
| imaginarypedro wrote:
| There are a lot of good practices there and I commend the author
| for sharing. I disagree with code freezes + manual QA
| verification -- why just dip your toes into CICD? -- and the
| advice about writing tests. "We don't have time to test now"
| results in a vicious circle.
| haskellandchill wrote:
| > Request at least one demo per week
|
| Sigh, such a misguided quota.
| dchuk wrote:
| I've led a fairly large product org in recent years, and
| frequent demos of deployed software is the number one way to
| ensure you're shipping software frequently and consistently
| alasdair_ wrote:
| "no" is a reasonable response to such a request :)
| imaginarypedro wrote:
| I tend to agree with you that prescriptive notions like this
| are a little misguided, but I like the spirit of what he's
| after here.
| mchusma wrote:
| I think this depends on the stage, but I don't think for us
| deploying weekly instead of 4x per week (M-Th). Would help.
|
| We also found feature flags slowed us down a lot in the early
| stages. I feel these should only be done for some features (e.g.
| an explicit AB test, a large feature with a lot of technical
| risk). Feature flags create a ton of complexity, and are often
| not worth it.
___________________________________________________________________
(page generated 2022-09-12 23:00 UTC)