Code the shortest path first • Hacker News Board

Re: Code the shortest path first

#111

Post by herval11 » Fri, Jun 30, 2023, 1:49 AM UTC

jstimpfle wrote: post #110

herval11 wrote: post #96

Once you become super senior you actually realize what the author said here is not completely correct. This guy has experience, but he hasn't reached nirvana. There is a singular high level design pattern/abstraction that you can use in actuality to start off your projects. There is no name for this pattern but it is essentially this: Segregate io and mutations away from pure functions. Write your code in modular com…

IME, separating I/O in the code works because it literally is separate -- it usually happens at the boundaries of the application. It rarely makes any sense to connect two code components (running in the same process) with a disk-backed information path. And where it does make sense -- well, your I/O code moves deeper inside the application. The "boundary" argument works even better where it's about network I/O or vi…

[dead]

Re: Code the shortest path first

#112

Post by jeromino » Fri, Jun 30, 2023, 3:43 AM UTC

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.

By that time the POC shipper got promoted for releasing fast, and no longer does dev on that team, and the replacements get harangued for delivering late. Business doesn't care who created the problem in the first place.

Re: Code the shortest path first

#113

Post by i-use-nixos-btw » Fri, Jun 30, 2023, 9:30 AM UTC

oweiler wrote: post #100

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…

Just make sure that it ends in the bin and is not shipped. I often write the PoC as a Kotlin script, with dependencies declared inline with @file, no tests, Just the bare minimum. No one would ask to ship this.

Absolutely. A PoC is supposed to be badly thought out, that’s the point. Get from A to B quickly, in whatever way possible, and then get feedback while building the real deal properly.

There has been some pushback against that idea on here, but I’m firm on it.

My approach these days is actually to get the PoC done with a lot of assistance from ChatGPT and copilot. It generally works great and fulfils the basic criteria, but isn’t production grade in the slightest. That’s fine - it means I can provide PoCs in the space of an hour or two, and it gives me something to aim for and refer to.

Re: Code the shortest path first

#114

Post by joshdata » Sat, Jul 01, 2023, 4:47 PM UTC

joshdata wrote: post #86

This is a similar idea to how I understand the Elephant Carpaccio exercise by Henrik Kniberg & Alistair Cockburn (2013), from what I've been able to Google. The key idea is that work should be broken down into "vertical slices" where vertical means that the entire user story is captured, or as it's described at https://uploads-ssl.webflow.com/5e3bed81529ab12a517031ab/5ec... , "very thin slices, each one still elephan…

Self-replying...

I found the comments really helpful so I wrote up some thoughts on different approaches to tackling projects. Hope this might be helpful to others.

https://joshuatauberer.medium.com/bullet-time-and-elephant-h...

Re: Code the shortest path first

#115

Post by atlantic » Mon, Jul 03, 2023, 9:01 PM UTC

btbuildem wrote: post #72

atlantic wrote: post #58

Earlier quoted context omitted.

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"

Good point. I'm a dev, so by the time this kind of project reaches me, the business angle has (presumably) been sorted out, and it's the technical feasibility that is in question.