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 first, because the early milestones are the hard part. But do it right and you end up seeing everything fall into place in quick succession, according to plan - and that’s a much greater sense of achievement IMO. It is often also a quicker way of seeing large projects to completion, though it doesn’t always feel like it at the time.

Building a Proof of Concept allows you to get the best of both worlds. It allows you to be naive, it allows you to write the bare minimum, and it gets something working that others can try out and give feedback on. As a bonus, it doesn’t generate technical debt, because you don’t build on the PoC - you use it as a reference while building the actual thing.

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.

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.

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 with one or two.

SPA frontend? Start with server-rendered. The tech is there to smoothly transition from one to the other, but it's possible that this will never be required.

That colour picker shaped like a peacock, following the mouse with its gaze? Just use a regular colour picker, but make it easily swappable. Where's that in the requirements anyway?

What's interesting is that more often than not enhancements lose priority in favour of new features.

Meanwhile some universal techniques like preferring pure functions where reasonable, using immutable data structures and actually having an architecture take as much time as doing sloppy work and go a long way into ensuring maintainability.

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?

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.

Maybe I'm not senior enough, but I think this misses the point. If I'm not prototyping, I don't try to "code the shortest path first", I try to code using the most popular libraries, and the most concrete, broad-strokes, fundamental abstractions, towards a goal of improving understandability.

At the end of the day, most code is deleted anyway. But even then people still need to understand it. I am attempting to write in the "lingua franca" and to make it clear to myself and others what I understand about the problem.

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

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.

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.

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

I 100% agree with this. Whenever I force myself to really, really do the simplest and dumbest thing first it leads to a better outcome.

I get to a working version of the feature quicker. From that, I get more insights. Sometimes I even realize that the simple and dumb version is good enough already.

I would say that this is the single most efficient rule/heuristic I have for making sure my productivity stays high.

I fell deep into this trap just yesterday, solving a Project Euler problem in Python. It involved a 2-million+ digit number. I'm just starting with Python, and while I know it transparently handles large integers, out of an abundance of caution I spent an hour optimizing to avoid dealing with greater-than-64-bit values, since the result needed is modulo a <64 bit value.

My code ran in about 4 seconds.

Then I thought I'd try a slightly larger optimization that involved ~128 bit values. That ran in a second, so obviously the switch to large integers either doesn't happen at 64 bits, or Python just handles it really well.

Then I thought to just do the math and let Python sort the results. One line of Python. Took ~20 seconds to write. Calculated the 2-million digit number and then did the modulo. Ran in a small fraction of a second. <sigh>

Want to add that the shortest path is only obvious from hindsight. And someone's shortest path maybe shorter than yours. Incremental iteration seems all the rage nowadays, but it didn't take one's taste and experience into account. If one's shortest path is long and winded, no amount of iteration will bring you to any sorts of local optima. The ultimate judgement is whether the things you built is getting use. If a tree falls in a forest and no one heard it, it didn't make a sound. It doesn't matter your code is good or bad. Build a mental map that leads you to building things useful

Based on the context provided through the article, I think what the author actually wanted was a Minimum Viable Product, that is, instead of coding the shortest path first, you remove the need for unnecessary paths (and without cutting corners). This should create a reasonably correct product that is safe to use and easy to build on top of.

But I do agree about the CI/CD part. In my case however, it's because many of these CI/CD services uses their own propriety config formats which are unfriendly for local testing. I can't remember how much time I've spent on hot-trying Travis CI just to get the build process right. I imagine things could feel a lot different if the services supports NixOS or just Dockerfile based script, because I can at least try the script locally before invoking the online service.

There are so many articles that float through here that can be summed up as "do this, unless you should do that" with a title equivalent to "why you should always do this"

Does this article present findings from other projects? Does it have a personal code story? Does it use any data or even antidotal evidence to support it's claims.

The answer to all of these is NO it does not...it's just a half hearted article talking about a fundamental problem in modern programming with no real solutions other that an axe to grind that they can't even really elaborate on the origins of.

I built FlingUp following the quickest path and compared to what we build at work.. FlingUp is lightyears ahead. Not held down by mindless patterns, very easy and quick to extend and build upon. Adding 1 new db field at work requires half a day of work until it is available for use on the frontend. The applications at work are so ridiculously overengineered that I sometimes feel we had too much money and time to throw at the codebase, engineers were experimenting and playing with pattern of the month. Maintainability is pretty much gone.

Make it work, make it right, make it fast.

https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

I get what he’s saying, but definitely several gotchas. The main project I work on these days has code that definitely isn’t the shortest path already checked in to main and running in prod. I’m that guy- set up ci/cd, apm, upgraded frameworks, and am working on major refactor. I tell management we can move faster on features and bugfixes if we can reduce the complexity of existing code.

But I do struggle with how far to take that. I worry I’m getting too deep and need to focus on features.

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.

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.

This is great, one modification that I would make is to add CI/CD and testing when there's a regression that was not expected, or when it makes development simpler. That way I don't have to think about the ,,right time'' to introduce these.

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 development. Don't code your "tracer bullet" on Win32 API calls when you're going to be using libuv. And like CI/CD, integrating libraries into the build should be painless

> if it’s software that’s going to ship, it needs tests

Oftentimes the tests are the only way you know if the code is even minimum viable, even manages to be the "tracer bullet". Ok you implemented a new feature, what says the code even runs and doesn't segfault immediately if there's not a test to build the new code into and run? Not comprehensive tests, but something

This is excellent advice. I would only modify it to say that one should first focus on getting something working, not necessarily the shortest path Then you can refactor and improve the code before you actually deploy it to production.

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

It reminds me of Go (not the language). Beginners play straight lines, then one learns fancy moves and complicates everything while high ranked players patterns again exhibit straighter simpler forms.

I like "throw away your first solution" or "be prepared to throw away your first solution."

And the difference between a senior dev and a junior dev is knowing when to stop.

Recently I ask ChatGPT to do that. I become the one to improve it.

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.

This is a balancing act. Spending the time later to undo all of the technical debt accumulated can take even longer.

For sideprojects, definitely, there is simply not enough time otherwise.

be agile? haha. I refer to this as punching a hole all the way through and then pull the rest through. punch + pull.

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!

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