Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code the shortest path first

evanlh.com

Post reply on HN
Print view View original

71–80 of 115 posts

Re: Code the shortest path first

#71

Post by btbuildem »

pyrale wrote: post #17
JonChesterfield wrote: post #16

Earlier quoted context omitted.

> because you don’t build on the PoC Ah yes, I remember that idea. Naturally we shipped the proof of concept. Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced. Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.

> I think this is a relatively popular development strategy. ...And this is why PoCs should be small-scale but technically sound things, rather than a shortcut competition. People are rarely going to complain about a PoC delivered a week late, but they are definitely going to complain later on, after they ship the PoC against your opinion and development slows down.

I strongly disagree, I think you misunderstood the purpose of a PoC

We build these things to flesh out ideas, to put something in front of PMs and ideally customers, to get feedback, and to make sure that we have a good bead on what the Most Important Problem is.

PoCs are disposable, sticks-and-ductape contraptions to demo features, and maybe have a small subset of users to play with for a limited time. They are by no means starting points for actual development.

Re: Code the shortest path first

#72

Post by btbuildem »

atlantic wrote: post #58
kristiandupont wrote: post #31

Earlier quoted context omitted.

How do you differentiate? To me, building a PoC is exactly that: create the shortest path, in order to (in)validate the concept.

Exactly. The proof-of-concept app should address the core technical obstacles in the new project, and prove they are surmountable in the simplest possible way.

That's a dev-centric perspective.

Alternately, a PoC should address the core business and usability questions. Everything else, including technical feasibility, is secondary and trivially solved with enough resources.

In the order of importance, the first question is "is this worth doing", only then you ask "how can we do this"

Re: Code the shortest path first

#73

Post by sumtechguy »

pyrale wrote: post #17
JonChesterfield wrote: post #16

Earlier quoted context omitted.

> because you don’t build on the PoC Ah yes, I remember that idea. Naturally we shipped the proof of concept. Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced. Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.

> I think this is a relatively popular development strategy. ...And this is why PoCs should be small-scale but technically sound things, rather than a shortcut competition. People are rarely going to complain about a PoC delivered a week late, but they are definitely going to complain later on, after they ship the PoC against your opinion and development slows down.

Even if you make it clear they will continue to use it.

I have one bit of code 'i do not claim any knowledge of' that I bashed out in under 1 day with promises that it will be re-written soon. 5 years on I still get questions about it. I get questions because it is a PoC that does one thing very well and everything else badly.

Re: Code the shortest path first

#74

Post by maverwa »

hkon wrote: post #67

For sideprojects, definitely, there is simply not enough time otherwise.

For me, its not just time, but also motivation. I cannot count how many site projects died in the early days, just because I came up with this impossible perfect thing it should be, having all the things. Then implementing it becoumes a chore. The amount of code/time I'd have to invest to make this imagination a reality becomes a mountain I cannot climb. Either because a lack of skill/knowledge, time, motivation, dedication, or just all of them. Usually this ends in me giving up the whole thing for good, ending most of these hobby project before they even began.

Starting with a "MVP", something that can be implemented quickly (relative to "the perfect thing") and provides some immediate benefit or feedback, pretty much always works better for me.

Its something I still stuggle a lot with. Its hard for me to get things done, because whatever I build never holds up to what I want it to be. But I think, I am getting better of accepting that, and just getting _something_ done.

Re: Code the shortest path first

#75

Post by cosmiccatnap »

There are so many articles that float through here that can be summed up as "do this, unless you should do that" with a title equivalent to "why you should always do this"

Does this article present findings from other projects? Does it have a personal code story? Does it use any data or even antidotal evidence to support it's claims.

The answer to all of these is NO it does not...it's just a half hearted article talking about a fundamental problem in modern programming with no real solutions other that an axe to grind that they can't even really elaborate on the origins of.

Re: Code the shortest path first

#77

Post by mejutoco »

pyrale wrote: post #60
mejutoco wrote: post #26

Earlier quoted context omitted.

People can complain about anything. That does not mean they are right. If a PoC is later extended, it will of course have limitations. We do not need to change the meaning of PoC to full product to preemptively solve that. Instead, when a PoC is done everybody involved needs to understand the implications. If people insist on misinterpreting them, that is on them. Those are political problems, not technical ones. The…

> Those are political problems, not technical ones. [...] TLDR. A PoC is a PoC, not a full product. Politics eat technnological semantics for breakfast though. It's up to you to decide whether this is a hill you want to die on. > They can be solved by aligning incentives. Often enough, that means shipping the poc.

> Instead, when a PoC is done everybody involved needs to understand the implications.

> Politics eat technnological semantics for breakfast though.

I see where you are coming from, but I have to disagree. I am not debating semantics, but reality. A prototype will always have limitations. That is the definition of a prototype.

I understand in reality sometimes it is worth to push through (startup), and sometime it is not needed but it is demanded. I am not starry-eyed, but it is useful to know what the reality is before one tries to bend it or adapt to it.

If you want, Nature/laws of physics eats politics for breakfast :)

Aligning incentives in this case could mean making the developer have a stake in the outcome (bonus), have competent people and clear deliverables, and bonuses for products that work well/convert. Not just for speed or busyness.

Basically you are assuming a sort of feudal relationship between someone handing arbitrary deadlines and (whatever you must do) and someone in charge of implementing it having no say in anything, and obeying blindly. That is not how the best engineering is done. Places exist (I have worked in some of them) where people can be professional, and a lot still gets done at the end of the day, even more than with the stick and harsh words approach.

A certain amount of back and forth is healthy and can produce much better outcomes for the company.

Re: Code the shortest path first

#78

Post by Kalanos »

tuukkah wrote: post #55
evanlh wrote: post #37

Earlier quoted context omitted.

Yes, totally agree with this-- I perhaps should have emphasized that my point is to code the shortest path thru the hardest problem . If somehow you just code around the hard part & keep deferring that til later you haven't learned anything.

I think the shortest/fastest path can have value even if you didn't learn much yet, because it can provide an end-to-end platform for learning: something to show and discuss with stakeholders and potential users. After you have that platform, the next target can be the biggest uncertainty / hardest problem that you need to solve to achieve an MVP. "We have X, can we get to an MVP?" (After you have an MVP, the hardest…

right, you might get an "actually, how about X?"

Re: Code the shortest path first

#79

Post by corry »

t43562 wrote: post #11

Usually one understands a project poorly at the start and much better at the end. So to agree with the article I think it's unwise to make all your decisions at the point where you know the least. By getting something working you improve your understanding and then you can choose optimisations and abstractions in a judicious manner - no point in optimising things that end up having no impact and no point in introduci…

"Usually one understands a project poorly at the start and much better at the end" It also happens at the product level - building features too early or too deeply for a poorly understood workflow; abstracting things that don't need to be abstracted for probably YEARS; over-engineering for major scale despite having no users; knowing that ONE DAY you'll need, say, multi-language support, so on Day 1 you over-complicate everything by insisting on a language framework etc.

Beginners lack the foresight of 'what this will look like at scale' or maybe better said 'why this won't work at scale', but that's ironically why they are better early on - speed matters a lot more than anticipating potential scale issues years later.

Re: Code the shortest path first

#80

Post by auggierose »

btbuildem wrote: post #68
Etheryte wrote: post #22

Earlier quoted context omitted.

There is a somewhat malicious compliance way of avoiding this, and that's to write the proof of concept in an obscure language or using some other set of tools that makes it impossible to pick up as-is by the rest of the team. The downside is that it also adds an additional cost to you when building it.

I've done this a number of times, it seems to work quite well, and I don't think of it as malicious. A "softer" way of handling this is to assign the prototyping / PoC development to a different team. The tribality / process worship / power dynamics between teams virtually guarantee that no code will be reused between the PoC and prod.

You also lose knowledge gained through building the PoC.
Post reply on HN