[HN Gopher] Code-First vs. Product-First
___________________________________________________________________
Code-First vs. Product-First
Author : luigi23
Score : 37 points
Date : 2021-08-29 10:47 UTC (12 hours ago)
(HTM) web link (thezbook.com)
(TXT) w3m dump (thezbook.com)
| rchaves wrote:
| Related: https://josephg.com/blog/3-tribes/
| larzang wrote:
| Context is incredibly important. The author is writing from the
| standpoint of a startup trying to fine tune an MVP. Of course it
| doesn't matter if it lasts if you don't know what you're building
| and rewriting everything isn't hard.
|
| Code-first matters a lot when you're trying to make a 15 year old
| cobbled-together system last another 15 when you don't have the
| resources to stop everything for the many engineer-years it would
| take to do a full rewrite. Anything you touch is going to have to
| last too and people have to care about adding more technical debt
| because it's already the 500lb sled they have to drag behind them
| every single day.
| shureluck wrote:
| Some useful insights for sure.
|
| Although some programmers care about both product and code and
| know how to balance it: based on the budget.
|
| Code-first programmers might have not had to face a deadline and
| a company running out of money. Not all of them are like this,
| but if you find yourself in this camp, I encourage joining a
| startup with some eyeballs into the finances as a way to balance
| that tendency to infinitely nitpick over small code details.
| Andys wrote:
| In response to budget constraints, I have seen some programmers
| respond with "maybe the company just shouldn't exist"
| noway421 wrote:
| Overgeneralising as usual, but I tend to group engineers into 2
| camps: builders and optimisers.
|
| Builders build product, they can ship something from scratch,
| doing whatever it takes to take the product over the finish line
| and in the hands of customers.
|
| Optimisers are the people who like to come to already built
| products and iteratively solve one bottleneck after the other
| that builders made while getting from 0 to 1.
|
| Both camps are valuable and both are needed, albeit at different
| stages of a company life. I tend to think I belong to the first
| camp.
|
| I think being purely code-first is a temporary phase and you tend
| to get into the first or the second camp at some point.
| Madeindjs wrote:
| I not totally agree with this. Architecture is really important
| because it can make new feature less expensive in term of
| development. If you judge a work only in terms of final product
| UX, you miss this point.
| darkhorse13 wrote:
| I don't disagree with you, but I've also seen working products
| get thrown away because of "bad architecture", only to waste
| tons of money and time. The worst part: the users literally
| never cared either way, they just wanted the product to solve
| their problem.
| ipaddr wrote:
| They care later when new features cannot be added, changes
| are delayed. A bad architecture is sometimes what you need
| but it will only take you so far.
|
| Architecture is important but not as important as getting the
| data-model right. We can refactor out bad architecture but a
| bad datamodel will have missing or inaccessible data since it
| was created and you cannot get that back.
| darkhorse13 wrote:
| Not if your company goes bankrupt trying to prematurely
| upgrade the architecture, which is usually a huge
| undertaking. I think that's the entire point of the
| article, the guy who wrote it is clearly using a startup
| POV.
| xupybd wrote:
| It makes sense to build a cheap and dirty system to
| start. Especially if you want to build it then inject
| loads of cash when it takes off. But it is still a cheap
| and dirty system.
|
| Too many people do build like this initially but are not
| willing to pay to fix the mess when it starts to get hard
| to add new features.
| arcbyte wrote:
| The data model serves the architecture. The architecture
| serves the use cases.
|
| Data models are a dime a dozen and are throwaway.
| noway421 wrote:
| Product-first engineers don't avoid architecture. They tend to
| know when you can skim on building it, or when the common
| development tools already provide enough of it.
|
| Sometimes, it's as simple as "frontend, backend, and a way to
| deploy it".
|
| Not to mention so many developer tooling products out there
| already decide on the architecture for you. Use anything
| firebase for example, and you'll be pretty railed in around the
| way your system is architected.
| sfvisser wrote:
| Language, syntax, test coverage, performance, coding style,
| linters, none of it really matters. No code is more beautiful
| than code that perfectly matches your problem domain. Being able
| to build a product in terms of high level building blocks that
| are sensible for the problem you're trying to solve is what makes
| great code.
|
| A few nice abstractions that allow you to pivot quickly without
| too much thought. Everything underneath is irrelevant and
| replaceable.
| noway421 wrote:
| I agree in spirit. Setting up a linter takes an hour though and
| is a worthwhile investment even if you are a cash-strapped
| startup with no customers. Given how many static analysis
| errors it reports these days, it will pay off dividends with
| less debugging.
| haolez wrote:
| There is also the time dimension. Some tools (languages et al)
| are misfit for some problem domains and might compromise your
| time to market and the viability of your product idea.
| [deleted]
| xupybd wrote:
| I get what he is saying but you can't say build it fast without
| tests, don't worry we will have to rebuild anyway and say you
| care about quality.
|
| Good quality code is code that has a low bug count and can be
| changed quickly. Over engineered code doesn't fit as it can't be
| changed quickly. But the same is true for a hacked together mess.
|
| He has a good point the best programmers will create a simple
| easy to maintain system quickly. These are generally the
| experienced and expensive veterans. They won't be pushed into
| taking silly short cuts, nor will they play with new toys at the
| cost of the product.
| noway421 wrote:
| Good programmers know when to cut corners. Not having tests is
| always a contentious topic, but it's also hard to justify when
| you don't have a product market fit yet.
|
| But then again, you might be building reusable components that
| you will reuse when rebuilding or relaunching. So it's better
| to get test coverage on at least those.
| rchaves wrote:
| Sometimes people claim to value "quality" of the product over
| engineering, but by quality they actually mean short-term
| profits increase, which is very valid for a startup if you ask
| me
| xupybd wrote:
| Yeah I agree, I just like people to be straight up about it.
| In that sense you are building a medium to low quality proof
| of concept to get revenue. This is the only way many products
| can ever get off the ground. If everyone knows the costs go
| way up when you attempt to scale this up that is fine.
|
| I come from a consulting background. Many companies are never
| willing to pay for that jump in quality. You end up stuck,
| with a customer that doesn't want to pay for improvements but
| is always complaining about the cost of new features. You
| have short deadlines and no scope to fix the mess. It becomes
| death by a thousand paper cuts. You pass by the same mess
| over and over never given the time to fix it. Knowing it
| would have paid for it's self if you had been able to do it a
| year ago. Sometimes this was something as simple as a
| database script to replace a manual task you are doing over
| and over. Once I created such a script but was told I had do
| it manually for the customer until they paid us for the
| script. It is truly soul crushing.
| breckenedge wrote:
| Takes about 2/3 of the article to say that the best programmers
| do both, but lean slightly toward shipping product faster with an
| eye on quality. I hope I saved you some reading.
| tdstein wrote:
| Don't worry. It's an art. Not a science.
| avaldes wrote:
| Is it when you're writing for example mission critical embedded
| software?
| bluewalt wrote:
| I think this mindset can lead to missing opportunities to build
| products actually faster. Having both code-first and product-
| first in your company is truly complementary IMO.
|
| CEOs that only wonder "can it be built fast" have a very short
| term vision. I keep hearing things like: "anyway, we are a
| startup so we will pivot hence code quality is not important
| right now, we need to push features!". The thing is, you don't
| need to reach many years so that "average to bad" code makes a
| new feature 10x longer to be delivered. Any experienced developer
| understand how a good code is truly valuable to a company for
| delivering. And even if it's very true in long term, this is true
| as well at the very first stages.
|
| But I'd say a very good developer is not product-first or code-
| first, he's both, you don't need to oppose both profiles. This
| very good developer is mature enough to know when a code
| refactoring will lead to a better productivity. And he's mature
| enough to know that this imperfect function is OK to keep as is
| because it has no real implication.
| [deleted]
___________________________________________________________________
(page generated 2021-08-29 23:00 UTC)