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

51–60 of 115 posts

Re: Code the shortest path first

#51

Post by nickelpro »

heisenbit wrote: post #44
nickelpro wrote: post #34

I agree with the sentiment but not the examples: > spend days setting up a CI/CD pipeline This should/does take minutes. It's like 15 lines of YAML for most CI providers. Ideally it's a part of the template you use for new code. > use a cool new library they just found Integrating a useful lib that makes the code simpler should be done from day 1. Don't code your own platform lib and switch to SDL halfway through dev…

>> spend days setting up a CI/CD pipeline > This should/does take minutes Should if you discount tool selection, learning tools, managing access control, deal with technical and organization imposed constraints, documentation and alignment across the team.

All of those things are easy. If they're not easy you have organizational problems that are slowing down development unnecessarily.

Your team has a CI system of choice, plugging a new thing into that CI system should be trivial, if it's not you're doing CI very poorly.

Hard-to-use is a bug.

Re: Code the shortest path first

#52

Post by nickelpro »

lhnz wrote: post #42
nickelpro wrote: post #38

Earlier quoted context omitted.

It's contextual, and the author is presenting it as universal. If you don't know how to build the thing, the author's advice is on the right track. If you're unfamiliar with the problem space, just bang away at it. Write that god object, that 500 line function, hardcode all the things. You wouldn't be able to come up with useful abstractions so don't bother trying. Get your stupid terrible code to work, the tiny demo…

> If you're unfamiliar with the problem space, just bang away at it. > Write that god object, that 500 line function, hardcode all the things. > You wouldn't be able to come up with useful abstractions so don't > bother trying. I take your point about this applying to the context of prototyping. But speaking universally, I'm trying to explain a third way in which you don't try to pick abstractions or apply hyped patt…

Then I disagree with you. If you don't know how to build a static asset server or a Vulkan renderer or an arena allocator at all, then you don't know how to build those things conservatively either.

The first pass in situations you have never been in before is always going to be completely worthless. You do not have any tacit knowledge of the problem space. Your prototype is strictly to gain that tacit knowledge, zero mental stamina should be spent on anyone that isn't between the chair and the keyboard understanding that code.

Once you've built that prototype, you use it as a reference for the ground up "conservative" or whatever other implementation strategy you want to take for the real thing.

Re: Code the shortest path first

#53

Post by ankaAr »

While reading I was thinking of Dan Harmon's about writing.

It is the same.

Just write/code then, when the thing is done, start the reviewing stage.

Anyway, you never know everything about your project when you start it.

Re: Code the shortest path first

#54

Post by sanitycheck »

Cthulhu_ wrote: post #12
000ooo000 wrote: post #5

tl;dr: long form version of "make it work, then make it pretty"

Which in itself is a short form of "make it work, make it pretty, make it fast, in that order", which tackles both over-engineering on an architectural and a performance level. For the vast majority of any task that requires writing code, performance is the least of your concerns; your code is fast enough, your compiler and runtime is fast enough, the hardware is fast enough. Use decent algorithms / don't do anything…

> For the vast majority of any task that requires writing code, performance is the least of your concerns;

Maybe, but it's perhaps not as rare as you think.

My main current project exists because development of the previous version was aborted after a year due to fundamental technology/architecture choices which it turned out would never achieve sufficient performance on the target devices.

Yesterday I was handed someone elses Android app to debug, it turns out to take 8 minutes for each (incremental!) compile for some reason. That's a performance problem which hugely slows down development.

A couple of years ago I wrote a moderately complicated one-way sync script to take data from one system and feed it into another. I had to artificially limit number of requests per minute to about 200 because apparently otherwise I was putting "massive load" on the target system causing it to auto-scale up several times. This was mostly GETs which the occasional small POST/PUT. Something very wrong there!

Re: Code the shortest path first

#55

Post by tuukkah »

evanlh wrote: post #37
kqr wrote: post #14

There's a fine line between shortest path first and most certain path first. It's tempting to jump in and do the things you know for sure how they will work – these are the things with the lowest need for exploration. Early-stage, you should focus on the things that are most uncertain, the things that have a chance of dooming the entire project if you don't understand them better. You can still take the shortest path…

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 problems may still await you but you can prioritize based on what increases value.)

Re: Code the shortest path first

#56

Post by remon »

Tade0 wrote: post #45

I think this advice is a little vague and therefore easy to get wrong. My approach converged to something that can be understood as a form of progressive enhancement, so basically providing the simplest usable version of a given feature, bearing in mind that eventually you'll have to expand it to what was originally requested - but that's all in separate tickets. Some examples: Six different payment processors? Start…

Your examples are very reasonable, and somewhat at odds if what the author is advising I think. As you say the advice is vague but I suspect it's also just fundamentally flawed.

There are very few real world scenarios where "just make it work" is a good approach to tackle engineering problems that require senior developers (read; developers with extensive experience in the related problem domain) in the first place.

My approach, which is I suspect it similar to what you're describing, is to define functional contracts first. Making them work is actually pretty low on the priority list, since that's consistently also the easiest thing to get right.

The hard part is correctly defining expected behaviour, interfaces and so on. In your example the hard part is constructing an interface/API for a payment processor that satisfies your business needs on the consuming side and is reasonably implementable for the relevant major payment providers. Actually implementing one, the making it work bit, is just not where the senior expertise adds value.

Unless, of course, you enjoy shipping glorified POCs to your customers because your stakeholders "saw it work" and blissfully ignored the metric tons of tech debts you just introduced, not to mention a skewed perception of the amount of effort needed for a that deliverable.

Re: Code the shortest path first

#57

Post by gjvc »

A by-product of coding up a working solution is one of better understanding the problem. Unfortunately, this valuable result is invisible to many, and its existence seldom acknowledged. Documentation can serve as a proxy for it, to make it somewhat tangible.

Re: Code the shortest path first

#58

Post by atlantic »

kristiandupont wrote: post #31
i-use-nixos-btw wrote: post #9

An alternative: Build a PoC first. The reason coding the shortest path first feels better is that you hit milestones early. However, it is a major generator of technical debt, and fleshing out the project is the hard part that takes longer and introduces breaking changes. Taking time to plan, getting the API planned in advance, generalising the code (obviously not TOO much), and so on might feel less rewarding at fir…

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.

Re: Code the shortest path first

#59

Post by pyrale »

mejutoco wrote: post #28
pyrale wrote: post #23

Earlier quoted context omitted.

> where time-to-market and profitability always trump code quality What actually happens is more like : "deliver as fast a possible, no matter what" ... "The poc was delivered in a week, why are new features so slow? And can you explain what this refactoring item adds to the bottom line?"

That seems like a failure of management.

Well, if one's management consistently fails in a predictable way that one can adapt to, one should probably adapt to it regardless of whether they believe it's a failure.

Re: Code the shortest path first

#60

Post by pyrale »

mejutoco wrote: post #26
pyrale wrote: post #17

Earlier quoted context omitted.

> 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.

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.

Post reply on HN