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

11–20 of 115 posts

Re: Code the shortest path first

#11

Post by t43562 »

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 introducing abstractions that in practice never will be used.

There are those who imagine that you can completely plan work before lifting a finger and it's a problem to struggle with them sometimes. Another one is when some aspect of the outcome is big in people's minds.

I was once on a project where we thought we'd be charging people based on their usage of the product. This made the reporting system very critical because if we messed anything up we'd be cheating our customers or giving them freebies. In the end we realised nobody wanted to pay that way so this huge design consideration which made everything much more complicated was gone. This sort of pattern happens often and it was a mistake to start that way. But that was a requirements mistake rather than a programming one and this is why your requirements are so critical. A single sentence in a document can double the cost of a project and your customers often don't realise that.

Re: Code the shortest path first

#12

Post by Cthulhu_ »

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 stupid (e.g. n+1 if you use an ORM), but don't fret too much whether it's fast enough either.

If your code is working and pretty, nine times out of ten it's fast enough. For the last 10%, measure before you make assumptions.

Re: Code the shortest path first

#13

Post by defrost »

mschuster91 wrote: post #10
jruz wrote: post #8

You’re mixing product decisions with code decisions. Product should make sure to create an MVP aka the fastest solution for A-B. Code should be done right no matter what, you’re being paid as an expert to do that, if they would want whatever crappy code gets it done they would do it themselves with some nocode solution and test the hypothesis.

> Code should be done right no matter what, you’re being paid as an expert to do that As I've written in a recent thread... that may be the case in the academic world, but certainly not in the business world, where time-to-market and profitability always trump code quality if not explicitly required / audited by client contracts.

Somewhere twixt the two is another domain; the hard equation engineering world.

Computations along novel curved beam configurations have to be correct, 400 m deep billion dollar / annum mine stope angles need to be both aggressive and safe, et al.

Often there's not as much competition as might be in other domains, and while profitability pays the bills the real onus is on the production of provably correct software (to the greatest degree practical).

Re: Code the shortest path first

#14

Post by kqr »

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 while focusing on the most uncertain first, but it is another concern that needs to be prioritised.

Re: Code the shortest path first

#15

Post by Pannoniae »

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…

This approach of "things being fast enough" leads to everything being slightly slow - we literally had better usability and latency on our devices in the 90s than we have now. It all adds up.

Re: Code the shortest path first

#16

Post by JonChesterfield »

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…

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

Re: Code the shortest path first

#17

Post by pyrale »

JonChesterfield wrote: post #16
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…

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

Re: Code the shortest path first

#18

Post by tuukkah »

I notice they link to The Pragmatic Programmer here:

> If it’s a true greenfield project you are “prototyping”, if it’s part of an existing project you are making a “tracer bullet”.

In the C2 wiki, someone paraphrases it like this:

> In PragmaticProgrammer, they talk about TracerBullets in the context of building an ArchitecturalPrototype - a bare-bones skeleton of your system that is complete enough to hang future pieces of functionality on. It's exploratory, but it's not really a prototype because you are not planning to throw it away - it will become the foundation of your real system. https://wiki.c2.com/?TracerBullets

Wikipedia has a description in the context of Scrum here: https://en.wikipedia.org/wiki/Scrum_(software_development)#T...

Does anyone remember more about what Pragmatic Programmer says about this topic?

Re: Code the shortest path first

#19

Post by sktrdie »

Like with everything in life, I'll answer this article with a strikingly "it depends".

What are your business requirements? How much budget do you have? Deadlines? Do you already have a clearly defined audience?

If you're a company like Figma then dedicating resources to crafting the hell out of the product & pushing the envelope in terms of maintainability, tests, performance & software craftmanship is a must. Probably going directly from A -> B is not scalable.

If you're a company with 200 costumers and 3 developers then I feel it's the opposite. Dedicating time & resources into all those premature optimizations might kill your company.

I remember seeing something along the lines of "Over-engineering cited as major cause of product failure. Because it never ships."

Re: Code the shortest path first

#20

Post by friendzis »

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;

I always have conflicting thoughts when faced with such statements. On one hand, you are right - in many cases any single code unit you write is not going to be the performance bottleneck anyway, and if it is you can optimize it later.

On the other hand, there are scaling characteristics, both algorithmic and architectural. Once you chose architecture that is just bad at the scale you target, it is going to be increasingly difficult to change that.

I guess the takeaway here is that we often forget the distinction between code performance and product performance.

Post reply on HN