Live data from Hacker News

Code the shortest path first

evanlh.com

91–100 of 115 posts

Re: Code the shortest path first

#91

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 did that once, almost a decade ago, when I was working on some PHP backend code implementing some moderately complex data processing in context of reservations of venues (the complexity came from the fact that venues could sometimes be reserved fractionally, and reservations could sometimes overlap, based on a variety of factors). I had a huge mental block then, caused by overall burnout on the project I got stuck…

I can't remember seeing Greenspun's Tenth Rule invoked so literally.

Re: Code the shortest path first

#92
post #82

Earlier quoted context omitted.

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.

Do you have experience with that second approach actually working? I'm currently stuck maintaining and upgrading multiple microservices that are a total mess because nobody understood how they were built, and we just had to cope with their weird spaghetti.

The way I've seen it work is that the PoC defines the features, then the dev team breaks this down and implements it any way they see fit. It's up to the teams to maintain their best practices and interoperability of the different solutions. Whomever built the PoC doesn't face any of these constraints, their focus is to help finalize the functional spec.

Re: Code the shortest path first

#93

Earlier quoted context omitted.

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.

I think that depends on why you built the PoC in the first place. Looking through the comments here I get the impression most people are looking at it as "is this technically feasible", while in my experience a PoC / prototype is usually made for business / usability validation ("is this valuable / will people use it").

Re: Code the shortest path first

#94

Prototyping is a wonderful thing we should do more of. However, in my experience, when you take this approach the majority of organizations will make the prototype the product. You will never throw out that code. It will simply be added on to, papered over, and mixed up with everything else. What started off as a fine prototype becomes a error-ridden ball-of-mud that nobody understands anymore. Where working on that…

> The key thing with prototypes is that you have to mercilessly rip that code out before people start extending it and relying on it otherwise it's going to stick around.

A way to avoid this is to start with a clearly defined data model between components, and then _within the context of each of those_ hit the gas towards an MVP, flesh that out, refactor, etc etc etc.

Not always a possibility, I'll grant, but a ton of headache can be saved by being religious about API-ifying those services which can be made into APIs. Stable I/O, chaotic move-fast-break-stuff for internals.

Re: Code the shortest path first

#95
The problem for me is that the shortest path often has nothing to do with the "best" path. Committing to it means you're never actually going to get it working right. You're going to get a knot in your stomach a year later when edits come down to your crappy MVP feature that feels like shit to work on.

Re: Code the shortest path first

#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 components such that all your logic is in pure functions and all your io and mutations are in other modules.

Why does this style of organization work? Because delineation and organization of every form of application you can think of benefits from breaking out your program organization along this pattern.

Your pure functions will be the most modular, reusable, and testable. You will rarely need to rearchitect logic in pure functions... Instead typically you write new modules and rearrange core functions and recompose them in different ways with newly added pure functions to get from A to B.

The errors and organizational mistakes will happen at the io layer. Those functions likely need to be replaced/overhauled. It's inevitable. Exactly like the author says this section of your program is the most experimental because you are exploring a new technological space.

But the thing is you segregated this away from all your pure logic. So then you're good. You can modify this section of your project and it remains entirely separate from your pure logic.

This pattern has several side effects. One side effect is it automatically makes your code highly unit testable. All pure functions are easily unit tested.

The second side effect is that it maximizes the modularity of your program. This sort of programming nirvana where you search for the right abstraction such that all your code reaches maximum reusability and refractors simply involve moving around and recomposing core logic modules is reached with pure functions as your core abstraction primitive.

You're not going to find this pattern listed in a blog post or anything like that. It's not well known. A software engineer gains this knowledge through experience and luck. You have to stumble on this pattern in order to know it. Senior engineers as a result can spend years following the hack first philosophy in the blog post without ever knowing about a heavy abstraction that can be reused in every single context.

If you don't believe me. Try it. Try some project that segregates logic away from IO. You will indeed find that most of your edits and reorganization of the logic happens with things that touch io. Your pure logic remains untouched and can even be reused in completely different projects as well!

Re: Code the shortest path first

#97
post #89

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…

Mind giving a concrete example? I read through the entire thing but couldn't make heads or tails of it. Is the point that your user stories should touch upon every aspect of your app, while still being incremental?

I think the idea is that for a slice of an elephant to be "elephant shaped," it has a bit of all of the key parts of an elephant - a bit of the trunk, a bit of a heart, stubs for four legs, whatever else makes an elephant an elephant. But what do the elephant's organs map to? I agree that the information on Elephant Carpaccio that I've been able to find doesn't really answer this.

My best guess is the idea is that it maps to aspects of a user story like "get input from the user," "do some business logic," "show output to user." So even the first slice is a working prototype in some superficial sense. The elephant organs might be app components (UI, database, etc.), but in the first slice you don't have a complete UI (maybe you have text input) and you don't have a production database (maybe you just have an in-memory dictionary) and you don't have robust business logic. You have the whole stack, but each part of the stack is incomplete. That's what I think makes it a vertical slice.

A horizontal slice (what not to do) would be one complete elephant organ. Maybe that's a production transactional database. So in the first slice you have a complete database or you've written the final business logic, but none of the other things that you would need in a mockup/prototype/MVP or an integration test.

Anyway, this is my best guess.

Re: Code the shortest path first

#98
Yeah the over optimize before getting the proof of concept/getting it working minimally should always be recognized as gambling, as the n you may lose all that optimization if the stuff doesn’t work with it down the line

Re: Code the shortest path first

#100

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.
Post reply on HN