>>webarc+W5
"Parkinson's law is the adage that "work expands so as to fill the time available for its completion". It is sometimes applied to the growth of bureaucracy in an organization."

https://en.wikipedia.org/wiki/Parkinson%27s_law

>>vimes6+(OP)
The article is full with interesting nuggets of wisdom, but I found it all over the place, as it mixes several issues (all of them important) into one.

The article mentiones "high-value" projects (vs "low-value" projects), but the actual distinction made is between high-effort (new framework, new kind of product) and low-effort. Value and effort are not neccessarily correlated, indeed by the end of the article the team has had a high-effort project that resulted in a low-value product.

It also conflates product discovery (what will actually have value to the users) and technical discovery (how do we build the damn thing). It starts with the technical challenges (and I totally subscribe to the notion that estimating anything that you're not doing routinely is Dangerous, see https://blog.senko.net/bridges-vs-apps) but then veers off into describing mismatch between features built and value add (also a very important subject, but a different one).

I would love to see author expand each of the sections into an own article and explore these things in more depth!

The most underwhelming part for me are the recommendations at the conclusion. So (focusing here on tech aspects) if "Something by Date (tm)" methodology is bad (which I can agree with in principle), the solution to "let competent engineers prototype [the app] in 3 or 4 different frameworks", ie . "give your engineers unbounded time"? All developers (and I am one) wish they'd have more time to implement things properly, so that's not a new insight. But it's not actionable either - "give more time" then turns into "Something by Later Date (tm)", which is basically the same problem, just with more money (and thus stakes) involved.

I hoped to see an exploration into how to creatively solve for "can we deliver value" + "we have this budget and time" constraints.

>>stavro+DL
You are correct, and that's the classic rationale for "MVP."

But I also follow a development methodology that I call "paving the bare spots."[0] It adjusts the design, as the project progresses. Not for the faint of heart. It means that I may toss out a month's work, because it does not fit the user experience (which is under constant revision). We have also made a couple of major pivots, during the project, to fit new realities.

I have probably tossed out three months' worth of work, as the project has progressed. Happy to do so. The best code, is the code I don't write.

The nice thing is, is that the product is constantly at "ship" Quality. Makes demos, user testing, and begging for money, easier.

[0] https://littlegreenviper.com/miscellany/the-road-most-travel...

>>mprovo+3z
"In the eyes of those who anxiously seek perfection, a work is never truly completed—a word that for them has no sense—but abandoned; and this abandonment, of the book to the fire or to the public, whether due to weariness or to a need to deliver it for publication, is a sort of accident, comparable to the letting-go of an idea that has become so tiring or annoying that one has lost all interest in it."

–Rosalie Maggio

Source: https://quoteinvestigator.com/2019/03/01/abandon/

>>onion2+85
A classic screed on the same topic: https://web.stanford.edu/class/cs240/old/sp2014/readings/wor...

>>shalma+b21
I'm the poor schlub that usually needs to maintain the code that I write.

I also pretty much never get questions about the code that I pass on to others.

I write about my process here: https://littlegreenviper.com/miscellany/leaving-a-legacy/

(Long screed. Few read it).

>>liketo+Ni1
This is the "hiding hand" principle at play.

https://en.wikipedia.org/wiki/Hiding_hand_principle

I highly recommend anyone interested in "megaprojects" to listen to this EconTalk podcast episode with Bent Flyvbjerg:

https://www.econtalk.org/bent-flyvbjerg-on-megaprojects/

Very insightful conversation.

>>ChrisM+FO
It’s a paraphrase, but the origin is indeed Aristotle.

http://www.universalethics.org/Ideas/Virtue_as_a_habit.htm