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

81–90 of 115 posts

Re: Code the shortest path first

#81

Post by tuukkah »

Kalanos wrote: post #78
tuukkah wrote: post #55

Earlier quoted context omitted.

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?"

Yes, or even more likely Y ;-)

Re: Code the shortest path first

#82

Post by delecti »

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.

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.

Re: Code the shortest path first

#83

Post by agentultra »

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 code takes longer and longer and carries a higher risk of introducing even more errors.

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.

Re: Code the shortest path first

#84

Post by moffkalast »

agentultra wrote: post #83

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…

Recently left a company that mostly just wanted random stuff to be glued onto an early prototype for years now. It just gets progressively more and more infuriating as it almost becomes obvious that a full rewrite would take less time than adding the stupid that the management wants. Doubly so with AI acceleration for new projects.

After a while it becomes impossible to convince anyone to ditch the prototype because of all the testing hours that have been poured into it, making for a very strong sunk cost fallacy.

Re: Code the shortest path first

#85

Post by sodapopcan »

agentultra wrote: post #83

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…

I worked at an org that did prototyping and it was fantastic. It was especially great for validating if a customer actually wanted the feature they were asking for (they often didn't). We _always_ threw away the work and started fresh if they did want it. What really helped keep us honest here was that we TDD and pair programmed. We also prioritized getting the prototype finished as quickly as possible. This meant writing really horrible code, calling variables and functions things like `foo`, and breaking other features if necessary.

Re: Code the shortest path first

#86

Post by joshdata »

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 elephant-shaped." The first vertical slice might be a mockup or very-low-fidelity prototype of the complete project and subsequent slices are enhancements following user stories. Horizontal slices might be, say, system components or other subtasks that leave you without something prototype-looking until all of the slices are complete. At least, this is how I've interpreted what I've read about it.

Re: Code the shortest path first

#87

Post by smugglerFlynn »

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.

The problem sounds more like "how do I deliver quality code when 95% of companies out there do not see quality as an objective, oversell poorly made PoCs, do not give space and resources for design and engineering, and pushback on any refactoring?"

The answer is very simple: you don't.

Re: Code the shortest path first

#88

Post by TeMPOraL »

Etheryte wrote: post #22
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.

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

Back then, I've had my first crush on Lisp, which made me think a lot in terms of higher-order functions. When I noticed that thinking "in lispy ways" lets me avoid mental blocks, I used this to finally figure out the solution for my work problem; I then implemented a quick and dirty prototype in Common Lisp, tested it, and proceeded to rewrite it in PHP.

Obviously, it was a slog, but half-way through crying and thinking things like "if only PHP had #'mapcan...", I finally figured that, with a little abuse of some more obscure (back then) PHP features, I could implement in PHP all the high-level constructs I used in my Lisp solution. So I did, and then I was able to trivially translate the whole solution to PHP.

End result: it worked, but it's good that the CEO didn't manage to hire those promised additional developers for that project, because I do not envy anyone who would have to read through my hacky solution implemented on top of a non-idiomatic Common Lisp emulation layer...

So sure, write the PoC in whatever obscure language you like, but be aware that past certain size/burnout level, someone (or you) may figure it's easier to port the language you used than just the PoC.

Re: Code the shortest path first

#89

Post by zrkrlc »

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…

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?

Re: Code the shortest path first

#90

Post by fho »

TeMPOraL wrote: post #88
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 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…

That story sounds very familiar to me ... I was working in Java but used Haskell for toy projects ... the amount of "if only Java had" thoughts were insane and I tried to do things with Generics that just weren't possible.

In the end I actually were able to use Haskell "in anger" for a work project ... that quickly cured me and actually getting things done in Haskell became the same slog.

Post reply on HN