This write-up is too light to provide any real insight. In particular, how do you assess simplicity?<p>From an example I'm currently working through on a hobby project... do I use a RS-485 transceiver with a custom line code, or do I use a 10base-T1 PHY? Ethernet, especially one pair ethernet, is undoubtedly more /complex/, with echo cancellation, a complicated line code, etc; but if I use the PHY, then /I own/ that complexity.<p>(For pure software folks, the equivalent question is internal implementation vs external dependencies. Do you implement a 1D barcode yourself, or do you import a third-party dependency for QR code reading?)<p>The problem is that answering this depends not on some objective notion of simplicity, but on a realistic assessment of /where time will go/ during the development process. If development time dominates, then exporting complexity is a win. But if testing time dominates, and since exported complexity still needs to be fully understood during testing, then in-house simplicity wins.<p>And which of these cases dominates is very much a project-by-project and team-by-team decision.
Rich Hickey's Simple Made Easy presentation is a fantastic introduction to this philosophy: <a href="https://www.infoq.com/presentations/Simple-Made-Easy/" rel="nofollow">https://www.infoq.com/presentations/Simple-Made-Easy/</a><p>Simple isn't the same as easy, and it isn't always obvious where the complexity is. One should beware of "simple" solutions that either hide the complexity, or shove it someplace else. The skill is to identify and minimize <i>unnecessary</i> complexity, which is another way of phrasing "Do The Simplest Thing That Can Possibly Work".
I wish I could convince product teams that the MVP is often just a single feature. Like a search bar + results page.<p>Something we can ship very fast, then we can add the banners, tracking for marketing, account creation, user ratings, community forums, results commenting and sharing, image carousels and a mobile app with push notifications that the results changed. You know, the regular MVP stuff.<p>So many people think agile means waterfall using sprints.
MVP: Minimal Viable Product.<p>The greatest example of this is Unix.<p>Multics was a huge produce that failed (initially). Bell Labs washed their hands of it, and didn't want anything to do with Operating Systems again.<p>Ken Thompson wrote an initial scrappy version of Unix in 3 weeks. Re-writing to C was a tremendous move because it meant that Unix could be ported easily to many other systems.<p>I heard someone say that the genius of Dennis Ritchie was that he knew how to get 90% of the solution using only 10% of the work.<p>I'm working my way through Unix Haters Handbook [1], and it's a good read, even for someone like myself who really likes Unix.<p>Unix and C are the ultimate computer viruses
-- Lawrence Krubner<p>[1] <a href="https://web.mit.edu/~simsong/www/ugh.pdf" rel="nofollow">https://web.mit.edu/~simsong/www/ugh.pdf</a>
As a relatively newbie software developer, I'm going to ignore this advice and just try to cobble together something that works and I'm deliberately not going to worry about whether or not there is a simpler, cleaner solution to the problem. The rationale is, if I keep searching for the simpler cleaner solution I'll keep falling down rabbit holes and never get to the point of having a solution to the problem at hand. After the fact, if someone comes along and says, 'hey, here's a simpler solution' that's great, but if I don't at least have a working project, nobody will even bother to deliver that helpful input.
Then launch that MVP into production, and never be given an ounce of time by your PM to fix any of the shortcomings that you thought were not part of "Do the Simplest Thing". Iterate on that principle for new features, too: what's the simplest way to get this new feature out? And this one?<p>And then find yourself surrounded by tech debt an a system that was cobbled together, not designed.
I agree, but I'd add in the caveat of "... in the context of a fleshed out bigger picture for what you're trying to solve".<p>A lot of software lacks a clear plan. A big patchwork of local maxima commits that won't get you where you need to go.<p>So I say go ahead and draw some pretty pictures. What's the overall vision here?
If this is applied to programming, then just be aware that "doing the simplest thing that can possibly work" integrated over time typically won't result in anything good. For any given task, the simplest thing that can possibly work will often have other effects that are hard to quantify on the spot (like increased tech debt).<p>If you're working on things that are <i>intended</i> to be short lived, then just do whatever is needed to get the job done and move on. If you're working with something where you know there's a good chance it'll be around for some time, then every once in a while, someone will have to take on the role of saying "no, we're not gonna do the simplest possible thing right now".
Don’t draw diagrams? Seems like not using a very valuable tool. Diagrams help you think and thinking can save you time in building the wrong thing or the wrong way. The diagram shouldn’t take ages and pencil/paper is fine.
The sentiment is nice but ceases to be useful when people have trouble distinguishing what could possibly work from what appears to work for a bit and then breaks down horribly.<p>And it's not really about the fallibility of people. Often in engineering you can be designing in a space with a lot of unknowns, that simply can't be resolved without building out a bit to explore the space more. In such case some level of future proofing is warranted.<p>I'm kind of suspicious of adages like these that assume perfect information.
This is effectively meaningless (and the article even recognises that) because it delegates all meaning to the definition of "works".<p>Even "passes all the tests" isn't a great definition. What are you testing?<p>For example think about build systems. "Works" could be "builds everything correctly" in which case the simplest thing is just a shell script with all the commands written out.<p>That's obviously terrible, so then "works" becomes "doesn't unnecessarily repeat work" and you end up with Make.<p>But then Make doesn't scale to large monorepos with CI so then "works" becomes "and doesn't allow undeclared dependencies" and you come up with Bazel.<p>So the same meaningless advice can justify wildly different solutions.<p>I think better advice is just "try to keep things simple where possible". It's vague because it requires experience and design skill.
I far prefer the original question "What is the simplest thing that could possibly work?"<p>It is far more active than the imperative version.<p>One might say the interrogative is the simplest thing that could possibly work...
I feel like this advice works really well in some places and really poorly in others.<p>I think those using safe languages and broad frameworks have a much greater ability to execute on "keep it simple" than those who use something like C and build 100% of their code in-house.
Yes, the old days<p><a href="https://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html" rel="nofollow">https://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.ht...</a><p>"XP" almost, but not quite, became a real cult.
I think we can't avoid all difficulty, and the difficulty then becomes determining exactly which bits we do need.<p>But it is a nice counter to some people's decisions to go for overly complex or risky (unproven?) technologies or designs.