13 ms·

Minimalism – An undervalued development skill

506 points by tipiirai 7y ago

tipiirai 7y ago
Author here: over the years this has been my prime strategy on building new stuff. First jQuery Tools, then Head JS, later Riot JS. Happy to talk about minimalism on this weird announcement day. Happy holidays!
- fovc 7y ago
  How do you weigh minimalism in a build vs. buy decision?
  - tipiirai 7y ago
    It's a strategy. To use minimalism as a competitive advantage. In an attempt to build products that are compelling. People only buy products they want.
    - pknopf 7y ago
      See https://meta.sr.ht/ https://meta.sr.ht/
- cxr 7y ago
  The link for the Disqus bullet (to try your alternative commenting system at the bottom of the page) is broken. It points to: https://volument.com/blog/minimalism-the-most-undervalued-development-skill#comments https://volument.com/blog/minimalism-the-most-undervalued-de... ... but what you want is: https://volument.com/blog/minimalism-the-most-undervalued-development-skill#minimalist-commenting https://volument.com/blog/minimalism-the-most-undervalued-de... Two things suggest you've still got some work to do cutting out the crap: 1. The commenting widget manages to foil my ability to select text and keep it selected. 2. If I disable JS (see #1) and reload the page, I just see one big blob of gray-green-blue.
  - tipiirai 7y ago
    The link is now fixed. I'll look the other two issues after the Christmas chores. The JavaScript-disabled issue is probably non-trivial, but obviously doable. Thanks!
- buckminster 7y ago
  Without javascript this shows a blank page. And it's about minimalism?
  - tipiirai 7y ago
    It's a bug. Not related to minimalism :) Thanks.
    - anderspitman 7y ago
      Ok, but now you have to tell us whether the bug was in your code or a dependency, and tell the truth!
      - tipiirai 7y ago
        The bug is on our code.
        anderspitman 7y ago
        tsk tsk if you had used a dependency it would have been bug-free /s
        tipiirai 7y ago
        Yup. In case all the dependencies are bug-free.
        tipiirai 7y ago
        Another valid option is to fix bugs. Now the page renders nicely with JavaScript disabled.
hadiz 7y ago
At a recent job, people were advocating for ginkgo, a non-standard "reinvents the wheel" type of testing framework in golang. If you don't know golang, it has near perfect tooling out of the box, including a standard test framework. I joined on the brink of this decision i.e. moving to ginkgo. I was the first and only person to ask what does ginkgo do that "go test" does not for us? Nobody could really answer that. Turns out, much like myself, and most engineers who weren't Googlers at the time, didn't really know golang and its environment. They all kinda assumed that like any other popular language, esp. for system programming (like C++) golang in its infancy requires a test framework supplement. Well, no it doesn't. "go test" is standard which if we're lucky, means we never have to re-write tests 10-20 years down the line because it's the standard.
- meddlepal 7y ago
  I had to go look up Ginkgo... and I'm not sure it's an Apples to Apples comparison. The built-in Go framework for unit testing is great but I don't think I would want to try to write clean BDD tests with it. Part of the value-prop for Ginkgo is that it gives you a standard BDD DSL which if you're doing BDD is half the battle... describing and testing the behavior with a human-friendly programmatic interface. On the other hand if none of the team could articulate why they needed Ginkgo that probably means they don't actually know what BDD and your point still stands.
  - hadiz 7y ago
    oh yeah absolutely, ginkgo has its use. It was not suited to what we were after, though.
  - dillonmckay 7y ago
    Which, IMHO, would behoove the team to learn BDD conceptually, in order to assess its appropriateness as a tool in any situation.
    - quickthrower2 7y ago
      I’m yet to see BDD used even though I’ve seen BDD frameworks used a lot. BDD frameworks happen to be excellent for unit testing too! They force you to write the testing code to be better because you need to describe each action. I find in normal unit tests developers use shenanigans to shortcut testing something.
buremba 7y ago
I see the point but I don't agree with the author. If I'm not mistaken that it took more than two years just to build their product and they're still pivoting in a way that they can monetize their users. I'm not actually sure if this delay is caused by your minimalism approach but startups usually need to focus on their core business in order to be able to find the product-market fit. In an ideal world, we should be focusing only on our core business, not the tooling around the product. OK, you just set up a hook for your error events in your front-end code that lets you collect the errors as events but Sentry is doing much more than that. If it is the only feature that you need, that's OK but the reality is that as your application code grows, you will need many more features for your error tracking. Eventually, you will need the UIs that lets you understand the context of the user, aggregate multiple events as one exception, send the errors to the relevant people, etc. and you will spend much more time building out these features and the switching cost to a real error tracking tool will be much higher. The tools such as Sentry and Google Analytics provide an opinionated way to accomplish specific set of tasks for typical use-cases. The advantage is that they have seen many customers, use-cases and edge cases so adopted their product in order to cover them all. You don't need to the same unless it's your core business.
- cpfohl 7y ago
  Yeah, I came in here to call out the error tracking use case...a good error tracker needs to do a _lot_ more than that.
  - anderspitman 7y ago
    Good for all projects, but how much does the project at hand actually require? And adding dependencies later is a lot easier than removing them.
  - volument 7y ago
    I suppose your requirements are different. We want to deal with errors like we deal with inbox, fix issues until we have "inbox zero". On our case that is all the client we need. There's obviously more logic on the backend, but not much.
rado 7y ago
Great article. I wish more people would understand minimalism and accept it as company/product culture. Web bloat is ridiculous and worth fighting.
neilkakkar 7y ago
.. This would make sense if it worked. There's a fine line between "not-developed-here syndrome" and minimalism-as-you-mention-it. If you can account for all the problems with the basic functionality the original big library tried to solve, this might work. But, if you're rediscovering all the problems again, and trying to solve them again, it's probably not the best use of your time. Further, if something is big enough to become a norm (like Disqus for comments) - creating yet another sign-up form for comments has enough friction to discourage at least me from commenting. (And the one on this blog is broken). I'm not saying your approach is wrong, but there's pros and cons to both, which don't seem to be captured here.
- blowski 7y ago
  An example of your point is ORMs. I’d much rather work with the bloat of Hibernate than any of the in-house ORMs I’ve seen.
- anderspitman 7y ago
  I think the key is having someone on the team experienced enough to estimate how much time to spend experimenting up front, and to recognize when things are getting into the weeds.
- tipiirai 7y ago
  There is indeed a fine line between NIH and minimalism. They have a strong correlation. You have to compromise between unnecessary features/bloat/crap or simply do it yourself. It's often surprising how easy it is to make something from the scratch. Hence NIH.
  - hinkley 7y ago
    It's not that fine a line. There's tons of space in the middle and I find a steady supply of coworkers who love to write code and hate to use libraries who never bother to understand half of what the libraries they do use are capable of. I may be slightly unusual in my habit of trying to find new uses for the tools we already have, but I'm not abnormal. This is something mature people should be doing as a matter of course. This "everything sucks (from my myopic viewpont)" thing is like a bizarre form of learned helplessness. And I say that as someone who complains a lot about the quality of tools and libraries. Only about 10% of the time do I think that means we should write our own. 40% we should pick a different tool, and half the time we should try to convince the author to fix the worst aspects (when the problem is deeper than a PR can address). Code you wrote is easier to understand for you. Of course you're going to be more productive with your code but what about everybody else? Are you making any compromises for the comprehension of others? Do you remember nothing about middle- and high-school coaches complaining about 'ball hogs'? The optimists think all of their code is amazing and bug free and hence cheap. But it costs everyone else time, respect (either for you, or themselves), but perhaps most importantly, resume material and independent support options. You are hijacking the project to fluff your own ego. For me, the worst quartile of my jobs have been NIH that turned into codependent bullshit drama, and it causes a pretty intense histamine reaction (as is evidenced in my phrasing in this comment) for me with people who are not self-aware enough to allow at least the possibility that maybe 50 people who have been thinking hard about a problem for five years are better equipped to solve it than you can in a week of bravado, followed by months or years of dodging responsibility for the problems you created by substituting your judgement for the rest of the team and the entire Internet. Just get over yourself and be a team player for once in your miserable narcissistic life.
dr0verride 7y ago
I like using minimalism as an starting place, but I think it's idealistic in most cases. We use senrty and we rely on many of the features you miss out on by just posting minimal exception information.
- tipiirai 7y ago
  I see your point. Sentry is clearly the least bloated service from the three examples mentioned.
s_gourichon 7y ago
Web site does not call external domains. Good. Still in the 15th percentile on https://www.websitecarbon.com/website/volument-com-blog-minimalism-the-most-undervalued-development-skill/ https://www.websitecarbon.com/website/volument-com-blog-mini... . Can it be improved? Something in the html/CSS prevents displaying the page until it's complete (observed on Firefox on Android). You should investigate, this will provide better impact to visitors. Is the whole web page some kind of advertisement? Overall, I agree. Perhaps you should make clearer that you compare bytes client side, not server-side handling (e.g. for error collection). Keep up the good work!
- tipiirai 7y ago
  Wow. Thanks for pointing out Websitecarbon. We will definitely use it to opitimize our site further. Currently our bottleneck is actually fonts. We tend to emphasize the importance of typography and make it perfect for our own taste at least. I suppose we can tweak the woff2 files and perhaps use a little less of different font-weights.
hogFeast 7y ago
Perfection comes not when you have nothing more to add but when you have nothing left to take away.
dominotw 7y ago
YAGNI ?
huffmsa 7y ago
> Minimalism Ah, but what's really discussed in the article is speed How fast a page loads. How quickly a tool can be understood. How quickly a tool can be used. How quickly the user can understand the product. How quickly they can figure out what they're doing wrong. Speed is the one true killer app. It's one of the few things that, when it's better than user expectations, will illicit stunned vocalizations of "bullshit, do it again. Oh shit, it's really that fast" from nearly everyone.
- yup1 7y ago
  Here's new blog post about a powerful way to make your website faster. https://volument.com/blog/spa-the-biggest-website-performance-booster https://volument.com/blog/spa-the-biggest-website-performanc...
- huffmsa 7y ago
  Minimalism certainly makes speed easier. But you can also have a minimal, one call API that takes forever and a day to resolve because it joins 20 tables
  - yup1 7y ago
    Here's new blog post about a powerful way to make your website faster. https://volument.com/blog/spa-the-biggest-website-performance-booster https://volument.com/blog/spa-the-biggest-website-performanc...
drewg123 7y ago
This applies at all levels of the stack, even hardware. I realize the author is talking about javascript, but I can think of several hardware projects where minimalism is clearly superior. At a previous employer (whom I cannot talk about), we were working on an ASIC. The ASIC team was new, brought in for the job, and was eager to include every possible feature that stakeholders wanted. The stakeholders seem to view this as a "its my birthday" kind of scenario, and so asked for lots of features (it wasn't going to cost them anything, after all). We had one senior hardware engineer, who was not on this ASIC team that was asked to sit in on meetings, and he was the "no" man. Somebody would request a feature, and he'd sketch out on the whiteboard what it would cost in chip area, power, and verification time. The ASIC was delivered more or less on time, and was wildly successful (I think, I'd left the company by this time). If it wasn't for this "no" man, I think they'd still be trying to verify all the features other teams had asked for. I never worked at Intel, and I don't know the inside story, but I'm guessing the same thing happened with their server NICs. The original 10G and its respin (82598, 82599) were simply brilliant in their simplicity, and they were one of the first full speed 10G NICs in terms of packet rate. Flash forward to the 40g / 10g xl7xxx series, where you have a kitchen sink worth of features, and the host has to do crazy things to deal with limitations in a basic core feature of an ethernet NIC (no more than 8 DMA s/g segs per emitted TSO packet). Flash forward again to the 100g columbiaville, which seems to be more of the same -- with the same TSO bug!
- GhettoMaestro 7y ago
  I deal a lot with white box networking hardware and software and have never encountered this bug. Can you point me to some more info? Thank you.
  - drewg123 7y ago
    See "ixl_detect_sparse()" in the FreeBSD ixl driver: https://svnweb.freebsd.org/base/head/sys/dev/ixl/ixl_txrx.c?view=markup#l155 https://svnweb.freebsd.org/base/head/sys/dev/ixl/ixl_txrx.c?... Or __i40e_chk_linearize in the Linux i40e driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/i40e/i40e_txrx.c#n3257 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... And their 100g NIC has the same bug (at least according to the FreeBSD driver that's in review now). ARGH!
edem 7y ago
Kinda anecdotal, but I've been working on OSS libraries for the last few years and what I've learned is very similar: 80% of the features aren't used by anyone, and if someone really wants something they just open an issue.
- ratww 7y ago
  Yeah, same experience here. I tend to be very stubborn about adding features to libraries, though. A handful of times I got pull requests that almost duplicated the size of small libraries just to cover some weird corner cases. One was support for an ORM discontinued since 2012. Another was someone who wanted a build tool to inline their assets during development phase. After asking, most people admitted that they don't really need the feature, but were simply trying to make the app complete.
_wldu 7y ago
I agree with the article. There is too much crap today in software. Much of it external crap. When I was young, I used to scoff when old programmers told me not to include external/3rd-party libraries. What did they know, these libs are so convenient! Today, I clearly see the downside of doing that and the slippery slope that it introduces. Rather than do the hard work myself upfront and pay that cost, I let someone else do it for me and simply included their work. Great, right? Not really. Now, I'm at their mercy. They break things all the time, don't address security issues, abandon the code I rely on, don't support OpenBSD armv7 (or whatever you run on), etc. Now, I'm much older and only include when there is absolutely no other way (very rarely).
- criddell 7y ago
  > old programmers told me not to include external/3rd-party libraries That's me. I also avoid plug ins in things like our bug tracker and build system. I'm the person that maintains our Redmine and Jenkins machines and over the years I've gotten lots of requests for plug-ins that do pretty neat things. I almost always refuse just because it makes updating such a pain in the ass. Generally, I do as little custom configuration as I possibly can these days. Twenty-five years ago customizing Enlightenment was how I spent about 30% of my time at the computer.
- tasogare 7y ago
  I shudder everytime I run npm install on my lab main software project, which downloads hundreds if not thousands of external dependencies and lists more than 400 vulnerabilities. On the reverse when I own a project, dependencies are kept to the minimum, often code I own too.
  - collyw 7y ago
    We have a new React front-end for our application. It's fairly simple but the amount of crap installed by npm is incredible. Then trying to fix bugs is a nightmare depending on what needs done. This stuff was supposed to make our lives easier...
- bob1029 7y ago
bertr4nd 7y ago
I have super mixed feelings on this. Minimalism makes for a clean, easy to understand codebase, that avoids some of the performance pitfalls associated with bigness. But sometimes it’s easy to build 80% of what you need, and then massively difficult to get to 100%, and the ease of getting to 80% can lead you astray. For instance, I can write a pretty fast matrix multiplication algorithm in maybe a few dozen lines of code. But then you look at OpenBLAS, Eigen, MKL, FBGEMM, etc. and you see thousands of lines of code. And it’s not because I’m 100x better at programming than the developers of these libraries, it’s that they’ve really put in effort to getting the best performance, in all corner cases, on all platforms. You could argue that matrix multiplication is an extreme case, and it is, but I think it’s still valuable to critically think about what you give up by opting for minimalism before you write off other people’s software as aimless bloatware.
- user_50123890 7y ago
  AKA "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." —Tom Cargill, Bell Labs
  - jzelinskie 7y ago
    Is this the original version of this quote? I’ve both repeated and heard it many different ways. Most often “the first and last 80%s”.
- hliyan 7y ago
  The message I took from this article was minimalism in features and not necessarily code. And certainly not about library usage. If you're building a product, focus on building a few key features extremely well. I suspect that part of the reason for feature bloat is that a when product is assigned dedicated, long-running teams, it tends not to reach an 'end state'. The team would rarely say "okay, now the product is mature, let's place it on maintenance and go on to build something else". Instead, they may (unconsciously) continue to justify their existence by continuing to 'improve' the product.
dtwest 7y ago
This reminded me of the Twain quote: "I didn't have time to write a short letter, so I wrote a long one instead." Sometimes I don't know how to solve my problems with tiny amounts of code. It often takes skill and effort to come up with an elegant solution. But I agree it is something we should try to do when we can.
- dctoedt 7y ago
  > the Twain quote: "I didn't have time to write a short letter, so I wrote a long one instead." Friendly amendment: This has been attributed as being originally from Blaise Pascal in 1656 [0] [0] https://en.wikiquote.org/wiki/Blaise_Pascal https://en.wikiquote.org/wiki/Blaise_Pascal
  - dtwest 7y ago
    Or maybe even earlier by Cicero. Seems like a common sentiment through history. Thanks for the link!
- efxhoy 7y ago
  My rewrites always end up much smaller than my original rushed implementations. I think it comes down to a few reasons * I get better at writing code. * Better understanding of the problem, the feedback from the first iteration usually tells me what the code actually had to do, not what my boss thought it needed to do. * A working but messy and bloated first iteration shows me that I can solve the problem at all, the rewrite let's me do it with some grace. The hard part is minimizing the time spent on the first messy implementation so more work can go into the good final iteration.
- downerending 7y ago
  The nice thing about writing a long letter is that it doesn't have to be maintained at significant cost over time. :-)
mouzogu 7y ago
It's very hard to write perfect minimal code from scratch. It takes a lot of foresight and consideration that mortals like myself simply don't possess. I think finding the optimal solution to any problem usually requires delving through a lot of crap, trial and error etc. Maybe this is why I find the trend towards minimalism a little bit condescending, if that's the right word.
- clarry 7y ago
  Or time to re-evaluate, refactor and rewrite. Once you've done that, you might gain that foresight. It's also known as experience. Too bad there are so many places where you're just constantly rushing to add new features on top of old stuff without ever having time to take another look at the design, fix it, and learn from it.
LaGrange 7y ago
"Be minimalist and don't use third party libraries and services. Except for ours. Use ours, because we don't have two decades of cruft under our belt excuse me, we're /minimal/. The article kinda uses a language of a sentiment I share to an extent (I think most devs are far too eager to pull dependencies — avoiding NIH doesn't mean you have to pull the entire 3rd party dependency, not if you can read a paper and implement it in a dozen lines), but while a completely in-house analytics package could be smaller, there's a reason why commercial packages are big.
- anderspitman 7y ago
  > while a completely in-house analytics package could be smaller, there's a reason why commercial packages are big But are those reasons your reasons, and do some of them warrant questioning in the first place?
- tipiirai 7y ago
  Yes. There is a reason commercial packages are big/bloated/complex etc. This is an opportunity for all of us.
swlkr 7y ago
Basecamp has a saying "underdo the competition"
justplay 7y ago
Minimalist design looks good but in practise when software were designed it was good at early stage but when complexity grows because of growing and expanding customer needs to meet different type of customer taste, software tend to get heavier and we end up writing lot of crap. Unfortunately.
mikewhy 7y ago
I'm all for minimalism, but the very first code example is a bad example. It's saying "look at how small your error handling can be" without mentioning that now you have to build something to inspect said errors. There is minimalism and there is punting the issue down the line, and this is an example of the latter.
- tipiirai 7y ago
  The core purpose of an error reporting client is to send the errors to the server. Anything more is some extra features (that we haven't had the need so far). Most of the logic resides on the backend, and it is not much to get the job done.
anderspitman 7y ago
Love it. I've been thinking [0] about this a lot lately. My rule of thumb these days when tempted to introduce a new dependency is try to build it from scratch first. I might spend 1 hour or 1 day, depending on my estimates of the costs/savings in the long term. I often find I just don't need the dependency. Sometimes I do, but after trying to build it myself I can fully justify why (to myself and others), and also understand how to use the dependency better. A few months ago I wanted to add an issue reporter to the help page of our open source genetics data visualization tool https://bam.iobio.io https://bam.iobio.io. I threw something together in less than 100 lines of code [1]. It doesn't even include any rate limiting or security measures. A couple weeks back I ran into a slight wrinkle that brought into question whether to keep using the tracker. I quickly analyzed the number of issues that had been submitted (including a recent influx of layman users), and simply removed it. Email support works fine for us based on our usage data. The decision was made easier because I didn't invest a bunch of time up front integrating with some external service, or building a 100% solution the first time around. > It certainly didn't help, that our former A/B testing tool emphasized short-term wins. When we added a huge sales overlay, it appeared to bring more conversions — since the return visitors were ready to take action. The new visitors probably hit the back button as soon as they arrived. This is great. All of your analytics insights are completely dependent on a) measuring the right thing and b) interpreting it correctly over the long term. EDIT: I do want to mention that these articles always point out downloaded code size as a primary factor in the decision, but I rarely see any data showing how the reduction in code size translates into an improved user experience, based on the principles of human perception. In my experience, the really big gains come from techniques like background fetching. Not that code size isn't important, but I think the main point should be the reduction in complexity that comes with it. That pays dividends in developer time and avoiding bugs, which translates directly to an improved user experience. [0] https://anderspitman.net/11/dependencies/ https://anderspitman.net/11/dependencies/ [1] https://github.com/anderspitman/issued https://github.com/anderspitman/issued
- ratww 7y ago
  > I do want to mention that these articles always point out downloaded code size as a primary factor in the decision, but I rarely see any data showing how the reduction in code size translates into an improved user experience, based on the principles of human perception. In my experience, the really big gains come from techniques like background fetching. Size is a huge factor when you're on a limited data plan. Maybe one website won't make a difference, but it adds up.
gumby 7y ago
I want to agree, but the story is incomplete. A lot of those products also started as MVPs, but accreted functionality in response either to customer demand or opportunities to monetize. The classic example of this is Word which started out as a small clone of Bravo but kept adding features that some subset of customers found indispensable until the whole codebase and UI became a mudball. I don’t really like MS software but a big part of the reason is a consequence of something I admire: their strong attempts at backward compatibility and preserving features that are actually used even if by a small minority. In other words: you can’t win.
- anderspitman 7y ago
  But as a user of a SaaS, how many of those customers are your customers?
  - gumby 7y ago
    Well, take disqus: starts as a simple blog comment tool, saving you writing one. Then they add a nice feature where logged-in users can follow responses on other pages, which is nice for the blog owner as it increases engagement. But the payload got bigger and then starts to spy on you or your users. Then, as the product is free perhaps they add an ad or start to sell the spy data. And.... Or there's an address widget you used, but it kept being updated because even though you only serve the USA, other sites need support for various foreign countries... I don't want to write everything, but sometimes indeed these 3P packages are a moment of convenience leading to a lifetime of regret.
volument 7y ago
The title now matches the HN staff edit.
deleted 7y ago
[deleted]
mnm1 7y ago
Reductionist garbage. Their "minimalist" sentry clone literally does nothing as presented on the page. There must be a back end that stores errors and an interface to view them, etc. There's a reason most apps are complex: because the world is complex. Making software that does nothing and pretending it's as useful as real software in the name of fashion, "minimalism" is frankly unimpressive and uninteresting. There are no shortcuts in real life. No matter how good their sentry backend is, I guarantee it's not nearly as useful because they almost certainly left out the ui that makes sentry the useful tool it is. So tired of articles about fashion.
- tipiirai 7y ago
  Yes. There is a backend that stores errors and an interface to view them. This article simply compares the size/complexity/feature-richness of the frontend code. Sentry UI is good and we are familiar with it. So is ours. It's just more minimalistic.
- hinkley 7y ago
  Alton Brown complains about single-use kitchen tools. I find his theories on implements to be very sympathetic to my own. Invest materially and mentally into a few good tools and learn to wield them properly. Don't half-ass two things. Whole-ass one thing. For one of my hobbies I have a little speech about how you could get started with only 5 specific tools. And the punchline of that story is that it's actually 4 tools + 1 duplicate. Because the 4 are that useful on their own, and one of them wears out much faster than the rest.
carapace 7y ago
"Make it as simple as possible, but no simpler." ~Einstein
- tipiirai 7y ago
  Absolutely. This is highly correlated. Seems many minimalist geniuses are from Germany.
  - carapace 7y ago
    And the Italians and the Renaissance, all those geniuses in one relatively tiny area. What's up with that?
layoutIfNeeded 7y ago
This page is completely empty on iOS. I guess the author should have made a minimalist static HTML page instead.
- omk 7y ago
  Is it HN's hug of death? I see the same on my PC.
  - volument 7y ago
    It was a JavaScript error on the commenting component due to a comment from a user that removed their account. Now fixed. Thanks!
    - hinkley 7y ago
      Do you appreciate the irony that your article that brags about writing your own comment system was taken down by a bad comment?
      - tipiirai 7y ago
        Haha. I little — have to say. I'm actually quite happy how well it works. This is only the second time the commenting widget is in active production use.
xwowsersx 7y ago
I just see a blank grayish blue page.
- volument 7y ago
  This was due to a comment from a removed user. Now fixed. Thanks!
  - useragent86 7y ago
    I still see a blank greenish-gray page. It appears to be because the BODY element has a CSS rule setting "opacity: 0", which appears to be for the purpose of enabling a CSS transition to fade in the page on load. Not exactly minimalism in terms of complexity, but it does appear minimalist in terms of content when the page is blank. :P Presumably the transition is triggered by some JavaScript. However, that JavaScript fails to execute because cookies are disabled, which causes an error: Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document. at new u (https://volument.com/v1/volument.js:17:858) at window.volument (https://volument.com/v1/volument.js:17:133) at https://volument.com/global/index.js?b:1:14673 at https://volument.com/global/index.js?b:1:60085 As a result, when cookies are disabled and JavaScript is enabled, the page appears blank. If I had a dollar for every time nowadays that I see a blank Web page because of invisible-by-default content that's made visible by JavaScript that fails to execute because it can't handle blocked cookies...
    - volument 7y ago
      This is now fixed and you can see the content when JavaScript is disabled. It's not as pretty yet but does the job for the Christmas day. Will check the localStorage thing next. Thanks!
    - volument 7y ago
      Now the cookie issue is also fixed.
NotATroll 7y ago
Feature minimalism is a good thing to strive for usually. Wrote my own dirt simple lazy loader & slider libraries, because I didn't need many of the features other libs had. On the flip side, if I need a reasonably complex component that would take quite a while for me to implement, like say. A date picker. I just grab the lightest weight, good looking one that I can find. (That also doesn't appear to be abandoned) Minimalism in everything, even minimalism.
cvaidya1986 7y ago
True.
baron816 7y ago
We embraced minimalism on my team a long time ago—no tests, no docs or comments, variable names are usually 1 or 2 characters, no indentation, no code reviews or QA, no meetings, etc.
- imhoguy 7y ago
  ...even no code. /s
- tgv 7y ago
  That’s so minimal i’d call it basic.
mtm7 7y ago
This also applies to features. Easy example: if you’re implementing commenting on a social media app, you could use a textarea instead of embedding a rich text editor. The simpler option usually decreases your overhead and helps keep your product easier to use, easier to explain to potential customers, easier to develop... It’s easy to keep adding stuff (especially if your customers are requesting it) but you should evaluate if it’s truly necessary.
codr7 7y ago
The most important kind of minimalism in my mind is YAGNI. Every single time I coded something I didn't need yet; I never did, at least not the solution I came up with. And once the complexity is in there, it's very difficult to scale back. This applies to everything I've worked on, from personal projects up to 10KLOC to 3MLOC commercial systems. It's just never a good idea from my experience. The code [0] I write these days tends to be pretty raw, but every single line fills a fundamental purpose. [0] https://github.com/codr7/libceque https://github.com/codr7/libceque
- meowface 7y ago
  YAGNI conspires against me. When I spend a lot of time building potential future features or creating a bunch of abstractions, I pretty much always never end up using any of them and it ends up as a (potentially huge) waste of time. When I'm building something and thinking about whether or not to make it more abstract / support potential future features, and decide "nah, ain't gonna need it", inevitably within a week or month I get some feature requests for those exact things, often requiring me to do a lot of rewriting from the ground up which I wouldn't have otherwise needed to do if I had started off with a more abstract model or added those features when I was initially considering them. (Obviously this isn't literally always true, and I'm getting better at it over time, but those are the ones that stick out.)
  - quickthrower2 7y ago
    This is the pain with “agile”. The problem with building the skateboard first and morphing that into a car (as per the cartoon strip meme/trope) is that a car is nothing like a skateboard. It’s a rewrite. If you can know you need a car upfront then you save a YAGNI/OFINI cycle. I’ll let you guess what OFINI means :)
    - codr7 7y ago
      It's certainly no Silver Bullet, and can be taken too far; but it was born as a reaction to the industry going way down the opposite drain. At least at that point, you know what kind of car you need. I still find it easier to refactor a simple solution into a more elaborate one than going the other way, easier to motivate as well as ripping out features is pretty much impossible in a corporate setting. Truth is always somewhere in between the extremes.
echlebek 7y ago
If you value minimalism, then why doesn't the page load any text when Javascript is disabled?
- volument 7y ago
  Because JS-disabled clients are an edge case and a minimalist approach attempts to solve most cases with the least amount of code. Nevertheless, we will make our site work with JS disabled. Thanks!
- oftenwrong 7y ago
  "chickenshit minimalism" https://idlewords.com/talks/website_obesity.htm#minimalism https://idlewords.com/talks/website_obesity.htm#minimalism
  - tipiirai 7y ago
    That's a good reference article indeed. I remember that. Seems Chickenshit Minimalism is defined as "the illusion of simplicity backed by megabytes of cruft" — which is not in play on the article. But yeah... need to make that page work on non-JS browsers. Thanks!
benblack86 7y ago
There seems to be a bug in the comment form on their site. It gives me the option to edit/delete the last comment and when it asks me to create an account, it shows me someone else's email address. I feel like this is the major reason for not rolling your own.
- deleted 7y ago
  [deleted]
- volument 7y ago
  The email address issue is now fixed. We'll fix the edit option visibility issue a little later (Christmas time happened) Bugs should not be a reason to give up rolling your own stuff, but I'm sure you didn't mean it that way. Thank you for reporting this issue!
dsalzman 7y ago
KISS - Keep It Simple Stupid is my mantra
xwowsersx 7y ago
What do those pie charts show (e.g. Disqus vs Custom)? No idea how to read those.
- xwowsersx 7y ago
  Oh it's the size of the code in thousands of kilobytes?
- tipiirai 7y ago
  It's comparing the size of the code.
  - xwowsersx 7y ago
    Weird though, no? Am I wrong to expect a pie chart to represent the "total" or "100%" and the slices a portion of the whole? I could be wrong, but this seems like the wrong usage of the pie chart.
    - volument 7y ago
      On those pies, the example SAAS product is the whole 100% and the tiny white slice is the custom alternative.
Mr_Shiba 7y ago
Usually product owners and business are the biggest enemies of engineering minimalism - [PO] A/B testing says button must be outside table - [DEV] But that makes the code unreliable and overcomplicates things the framework is not designed to do that, maybe if we include a regular link... - [PO] BUT AB TESTING, ACQUISITIONS, CRITICAL MISSION, bla bla bla
ggregoire 7y ago
> If you want a cheap trick to make a difference — here's one: minimalism. Focus on the bare essentials and get rid of the rest. It's an easy way to differentiate, because most others are doing the opposite: tons of crap. For a moment I thought this was about real life minimalism.
dana321 7y ago
A minimal core with just enough functionality to be useful, then a plugin framework with hooks for all the other features that everyone else needs to build in. A minimal phone with just enough functionality to be useful, then an app store to get all of other functionality you need via downloadable apps. Its a model that works well, providing an ecosystem to anyone who wishes to extend. Code is kind of the same now.. Get the basic thing going, then people fork it, improve it, submit patches, sometimes over decades. The worst software imho, is a closed architecture that has the kitchen sink included that nobody can extend. Modularism and a pluggable architecture is much better than just minimalism on its own.
jarofgreen 7y ago
This touches on the topic of doing something yourself vs getting someone else to do it for you, and I would recommend anyone interested check out Wardley Mapping. https://en.wikipedia.org/wiki/Wardley_map https://en.wikipedia.org/wiki/Wardley_map It's a way to generate discussion in your company/project/whatever about when it's appropriate to custom-roll, and when you should use commodity.
kevindong 7y ago
First and foremost: beautiful and performant website. I don't understand how exactly the Volument product actually performs A/B testing (or distinguishes between different variants). The only code docs [0] I've found are very, very light on details and doesn't mention how the active variant is detected. To be fair, the product hasn't launched yet so perhaps the docs are currently internal-only. That being said, very interesting idea of linking engagement to eventual conversion to get "results" faster. It certainly seems reasonable that there is a causation relationship (increased engagement, e.g. more scrolling and longer visit duration, eventually leading to increased conversion), but I don't know how statistically valid that is. [0]: https://volument.com/learn/client-api https://volument.com/learn/client-api
- volument 7y ago
  Here's how Volument works: https://volument.com/learn/volument-data-model https://volument.com/learn/volument-data-model A/B testing in Volument is quite different from, say Optimizely. You can compare a lot of things in apples-to-apples fashion: landing pages, inner pages, market segments, campaigns, site versions, etc. And you can compare both how much traction something generates, or how engaging a page is. The causation thing is just something we measure. We measure how people behave on their first visit, how intensively they return, and how much they convert. It's not about the statistical validity, it's about choosing metrics that are essential for conversion optimization.
Tade0 7y ago
We can finally pursue our minimalistic religion, iterate quickly, and collect maximum wins. Religion implies dogma, and I don't like dogma in my field. Side note: the biggest takeaway for me here is: be careful when writing such self-confident articles. The general public doesn't take kindly to such displays.
pknopf 7y ago
This echos a sentiment I've been feeling on a few recent posts of mine. The argument against Entity Framework, and for micro-ORMs. - https://pknopf.com/post/2019-09-22-the-argument-against-entity-framework-and-for-micro-orms/ https://pknopf.com/post/2019-09-22-the-argument-against-enti... You don’t need Cake anymore; the way to build .NET projects going forward. - https://pknopf.com/post/2019-03-10-you-dont-need-cake-anymore-the-way-to-build-dotnet-projects-going-forward/ https://pknopf.com/post/2019-03-10-you-dont-need-cake-anymor... My blog is also written from scratch, using a stupid tool. https://github.com/pauldotknopf/pauldotknopf.github.io/tree/staging/generator https://github.com/pauldotknopf/pauldotknopf.github.io/tree/...
crazygringo 7y ago
Unfortunately I can't agree. There's an old quote I can't remember the exact source of, that "Microsoft Word users only use 5% of its features... but each user uses a different 5%." It's not bloated. It's just that other users have different needs from yours, and you're ignoring other users, assuming they're the same as you. But they're not. It's easy to write a minimal version that works on your dev machine in your browser. But now get it to work on all browsers on all devices on all OS's. And now build in all the little feature that big clients require for legitimate reasons. And now ensure it works with several legacy versions of API's, etc. Is it "bloated"? No. It does what it needs to do.
luord 7y ago
One adage I like is "the best code is the code you don't write", meaning that we should write as little as possible because every new line is a potential new error(s).
- collyw 7y ago
  I agree. I wish more people had this attitude.
cbanek 7y ago
> We have a single developer taking care of the codebase. Does Optimizely need ten people to handle theirs? Or twenty? We don't know, but one thing is for certain: 20 people make more redundancy, technical debt, and bugs than one. I get the point that having too many developers writing too much code can make it too much to handle. But I've seen what one person operating alone in a vacuum can do as well, and it is not pretty. It seems like really you want maybe 3 people to really understand some code. That gives you a good bus factor, but not so many people injecting ideas and patterns that the code becomes unwieldy. More important, it gives you extra code reviewers who can push back against bad code smell and hopefully find bugs, or at least try to test it. 1 might be better than 20, but 3 is better than 1.
deleted 7y ago
[deleted]
abraxas 7y ago
If disquss is hailed as an example of good design we’ve fallen so hard...

506 points by tipiirai 7y ago

Author here: over the years this has been my prime strategy on building new stuff. First jQuery Tools, then Head JS, later Riot JS. Happy to talk about minimalism on this weird announcement day. Happy holidays!

fovc 7y ago
How do you weigh minimalism in a build vs. buy decision?
- tipiirai 7y ago
  It's a strategy. To use minimalism as a competitive advantage. In an attempt to build products that are compelling. People only buy products they want.
  - pknopf 7y ago
    See https://meta.sr.ht/ https://meta.sr.ht/
cxr 7y ago
The link for the Disqus bullet (to try your alternative commenting system at the bottom of the page) is broken. It points to: https://volument.com/blog/minimalism-the-most-undervalued-development-skill#comments https://volument.com/blog/minimalism-the-most-undervalued-de... ... but what you want is: https://volument.com/blog/minimalism-the-most-undervalued-development-skill#minimalist-commenting https://volument.com/blog/minimalism-the-most-undervalued-de... Two things suggest you've still got some work to do cutting out the crap: 1. The commenting widget manages to foil my ability to select text and keep it selected. 2. If I disable JS (see #1) and reload the page, I just see one big blob of gray-green-blue.
- tipiirai 7y ago
  The link is now fixed. I'll look the other two issues after the Christmas chores. The JavaScript-disabled issue is probably non-trivial, but obviously doable. Thanks!
buckminster 7y ago
Without javascript this shows a blank page. And it's about minimalism?
- tipiirai 7y ago
  It's a bug. Not related to minimalism :) Thanks.
  - anderspitman 7y ago
    Ok, but now you have to tell us whether the bug was in your code or a dependency, and tell the truth!
    - tipiirai 7y ago
      The bug is on our code.
      - anderspitman 7y ago
        tsk tsk if you had used a dependency it would have been bug-free /s
        tipiirai 7y ago
        Yup. In case all the dependencies are bug-free.
        tipiirai 7y ago
        Another valid option is to fix bugs. Now the page renders nicely with JavaScript disabled.

hadiz 7y ago

At a recent job, people were advocating for ginkgo, a non-standard "reinvents the wheel" type of testing framework in golang. If you don't know golang, it has near perfect tooling out of the box, including a standard test framework. I joined on the brink of this decision i.e. moving to ginkgo. I was the first and only person to ask what does ginkgo do that "go test" does not for us? Nobody could really answer that. Turns out, much like myself, and most engineers who weren't Googlers at the time, didn't really know golang and its environment. They all kinda assumed that like any other popular language, esp. for system programming (like C++) golang in its infancy requires a test framework supplement. Well, no it doesn't. "go test" is standard which if we're lucky, means we never have to re-write tests 10-20 years down the line because it's the standard.

meddlepal 7y ago
I had to go look up Ginkgo... and I'm not sure it's an Apples to Apples comparison. The built-in Go framework for unit testing is great but I don't think I would want to try to write clean BDD tests with it. Part of the value-prop for Ginkgo is that it gives you a standard BDD DSL which if you're doing BDD is half the battle... describing and testing the behavior with a human-friendly programmatic interface. On the other hand if none of the team could articulate why they needed Ginkgo that probably means they don't actually know what BDD and your point still stands.
- hadiz 7y ago
  oh yeah absolutely, ginkgo has its use. It was not suited to what we were after, though.
- dillonmckay 7y ago
  Which, IMHO, would behoove the team to learn BDD conceptually, in order to assess its appropriateness as a tool in any situation.
  - quickthrower2 7y ago
    I’m yet to see BDD used even though I’ve seen BDD frameworks used a lot. BDD frameworks happen to be excellent for unit testing too! They force you to write the testing code to be better because you need to describe each action. I find in normal unit tests developers use shenanigans to shortcut testing something.

buremba 7y ago

I see the point but I don't agree with the author. If I'm not mistaken that it took more than two years just to build their product and they're still pivoting in a way that they can monetize their users. I'm not actually sure if this delay is caused by your minimalism approach but startups usually need to focus on their core business in order to be able to find the product-market fit. In an ideal world, we should be focusing only on our core business, not the tooling around the product. OK, you just set up a hook for your error events in your front-end code that lets you collect the errors as events but Sentry is doing much more than that. If it is the only feature that you need, that's OK but the reality is that as your application code grows, you will need many more features for your error tracking. Eventually, you will need the UIs that lets you understand the context of the user, aggregate multiple events as one exception, send the errors to the relevant people, etc. and you will spend much more time building out these features and the switching cost to a real error tracking tool will be much higher. The tools such as Sentry and Google Analytics provide an opinionated way to accomplish specific set of tasks for typical use-cases. The advantage is that they have seen many customers, use-cases and edge cases so adopted their product in order to cover them all. You don't need to the same unless it's your core business.

cpfohl 7y ago
Yeah, I came in here to call out the error tracking use case...a good error tracker needs to do a _lot_ more than that.
- anderspitman 7y ago
  Good for all projects, but how much does the project at hand actually require? And adding dependencies later is a lot easier than removing them.
- volument 7y ago
  I suppose your requirements are different. We want to deal with errors like we deal with inbox, fix issues until we have "inbox zero". On our case that is all the client we need. There's obviously more logic on the backend, but not much.

rado 7y ago

Great article. I wish more people would understand minimalism and accept it as company/product culture. Web bloat is ridiculous and worth fighting.

neilkakkar 7y ago

.. This would make sense if it worked. There's a fine line between "not-developed-here syndrome" and minimalism-as-you-mention-it. If you can account for all the problems with the basic functionality the original big library tried to solve, this might work. But, if you're rediscovering all the problems again, and trying to solve them again, it's probably not the best use of your time. Further, if something is big enough to become a norm (like Disqus for comments) - creating yet another sign-up form for comments has enough friction to discourage at least me from commenting. (And the one on this blog is broken). I'm not saying your approach is wrong, but there's pros and cons to both, which don't seem to be captured here.

blowski 7y ago
An example of your point is ORMs. I’d much rather work with the bloat of Hibernate than any of the in-house ORMs I’ve seen.
anderspitman 7y ago
I think the key is having someone on the team experienced enough to estimate how much time to spend experimenting up front, and to recognize when things are getting into the weeds.
tipiirai 7y ago
There is indeed a fine line between NIH and minimalism. They have a strong correlation. You have to compromise between unnecessary features/bloat/crap or simply do it yourself. It's often surprising how easy it is to make something from the scratch. Hence NIH.
- hinkley 7y ago
  It's not that fine a line. There's tons of space in the middle and I find a steady supply of coworkers who love to write code and hate to use libraries who never bother to understand half of what the libraries they do use are capable of. I may be slightly unusual in my habit of trying to find new uses for the tools we already have, but I'm not abnormal. This is something mature people should be doing as a matter of course. This "everything sucks (from my myopic viewpont)" thing is like a bizarre form of learned helplessness. And I say that as someone who complains a lot about the quality of tools and libraries. Only about 10% of the time do I think that means we should write our own. 40% we should pick a different tool, and half the time we should try to convince the author to fix the worst aspects (when the problem is deeper than a PR can address). Code you wrote is easier to understand for you. Of course you're going to be more productive with your code but what about everybody else? Are you making any compromises for the comprehension of others? Do you remember nothing about middle- and high-school coaches complaining about 'ball hogs'? The optimists think all of their code is amazing and bug free and hence cheap. But it costs everyone else time, respect (either for you, or themselves), but perhaps most importantly, resume material and independent support options. You are hijacking the project to fluff your own ego. For me, the worst quartile of my jobs have been NIH that turned into codependent bullshit drama, and it causes a pretty intense histamine reaction (as is evidenced in my phrasing in this comment) for me with people who are not self-aware enough to allow at least the possibility that maybe 50 people who have been thinking hard about a problem for five years are better equipped to solve it than you can in a week of bravado, followed by months or years of dodging responsibility for the problems you created by substituting your judgement for the rest of the team and the entire Internet. Just get over yourself and be a team player for once in your miserable narcissistic life.

dr0verride 7y ago

I like using minimalism as an starting place, but I think it's idealistic in most cases. We use senrty and we rely on many of the features you miss out on by just posting minimal exception information.

tipiirai 7y ago
I see your point. Sentry is clearly the least bloated service from the three examples mentioned.

s_gourichon 7y ago

Web site does not call external domains. Good. Still in the 15th percentile on https://www.websitecarbon.com/website/volument-com-blog-minimalism-the-most-undervalued-development-skill/ https://www.websitecarbon.com/website/volument-com-blog-mini... . Can it be improved? Something in the html/CSS prevents displaying the page until it's complete (observed on Firefox on Android). You should investigate, this will provide better impact to visitors. Is the whole web page some kind of advertisement? Overall, I agree. Perhaps you should make clearer that you compare bytes client side, not server-side handling (e.g. for error collection). Keep up the good work!

tipiirai 7y ago
Wow. Thanks for pointing out Websitecarbon. We will definitely use it to opitimize our site further. Currently our bottleneck is actually fonts. We tend to emphasize the importance of typography and make it perfect for our own taste at least. I suppose we can tweak the woff2 files and perhaps use a little less of different font-weights.

hogFeast 7y ago

Perfection comes not when you have nothing more to add but when you have nothing left to take away.

dominotw 7y ago

YAGNI ?

huffmsa 7y ago

> Minimalism Ah, but what's really discussed in the article is speed How fast a page loads. How quickly a tool can be understood. How quickly a tool can be used. How quickly the user can understand the product. How quickly they can figure out what they're doing wrong. Speed is the one true killer app. It's one of the few things that, when it's better than user expectations, will illicit stunned vocalizations of "bullshit, do it again. Oh shit, it's really that fast" from nearly everyone.

yup1 7y ago
Here's new blog post about a powerful way to make your website faster. https://volument.com/blog/spa-the-biggest-website-performance-booster https://volument.com/blog/spa-the-biggest-website-performanc...
huffmsa 7y ago
Minimalism certainly makes speed easier. But you can also have a minimal, one call API that takes forever and a day to resolve because it joins 20 tables
- yup1 7y ago
  Here's new blog post about a powerful way to make your website faster. https://volument.com/blog/spa-the-biggest-website-performance-booster https://volument.com/blog/spa-the-biggest-website-performanc...

drewg123 7y ago

This applies at all levels of the stack, even hardware. I realize the author is talking about javascript, but I can think of several hardware projects where minimalism is clearly superior. At a previous employer (whom I cannot talk about), we were working on an ASIC. The ASIC team was new, brought in for the job, and was eager to include every possible feature that stakeholders wanted. The stakeholders seem to view this as a "its my birthday" kind of scenario, and so asked for lots of features (it wasn't going to cost them anything, after all). We had one senior hardware engineer, who was not on this ASIC team that was asked to sit in on meetings, and he was the "no" man. Somebody would request a feature, and he'd sketch out on the whiteboard what it would cost in chip area, power, and verification time. The ASIC was delivered more or less on time, and was wildly successful (I think, I'd left the company by this time). If it wasn't for this "no" man, I think they'd still be trying to verify all the features other teams had asked for. I never worked at Intel, and I don't know the inside story, but I'm guessing the same thing happened with their server NICs. The original 10G and its respin (82598, 82599) were simply brilliant in their simplicity, and they were one of the first full speed 10G NICs in terms of packet rate. Flash forward to the 40g / 10g xl7xxx series, where you have a kitchen sink worth of features, and the host has to do crazy things to deal with limitations in a basic core feature of an ethernet NIC (no more than 8 DMA s/g segs per emitted TSO packet). Flash forward again to the 100g columbiaville, which seems to be more of the same -- with the same TSO bug!

GhettoMaestro 7y ago
I deal a lot with white box networking hardware and software and have never encountered this bug. Can you point me to some more info? Thank you.
- drewg123 7y ago
  See "ixl_detect_sparse()" in the FreeBSD ixl driver: https://svnweb.freebsd.org/base/head/sys/dev/ixl/ixl_txrx.c?view=markup#l155 https://svnweb.freebsd.org/base/head/sys/dev/ixl/ixl_txrx.c?... Or __i40e_chk_linearize in the Linux i40e driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/i40e/i40e_txrx.c#n3257 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... And their 100g NIC has the same bug (at least according to the FreeBSD driver that's in review now). ARGH!

edem 7y ago

Kinda anecdotal, but I've been working on OSS libraries for the last few years and what I've learned is very similar: 80% of the features aren't used by anyone, and if someone really wants something they just open an issue.

ratww 7y ago
Yeah, same experience here. I tend to be very stubborn about adding features to libraries, though. A handful of times I got pull requests that almost duplicated the size of small libraries just to cover some weird corner cases. One was support for an ORM discontinued since 2012. Another was someone who wanted a build tool to inline their assets during development phase. After asking, most people admitted that they don't really need the feature, but were simply trying to make the app complete.

_wldu 7y ago

I agree with the article. There is too much crap today in software. Much of it external crap. When I was young, I used to scoff when old programmers told me not to include external/3rd-party libraries. What did they know, these libs are so convenient! Today, I clearly see the downside of doing that and the slippery slope that it introduces. Rather than do the hard work myself upfront and pay that cost, I let someone else do it for me and simply included their work. Great, right? Not really. Now, I'm at their mercy. They break things all the time, don't address security issues, abandon the code I rely on, don't support OpenBSD armv7 (or whatever you run on), etc. Now, I'm much older and only include when there is absolutely no other way (very rarely).

criddell 7y ago
> old programmers told me not to include external/3rd-party libraries That's me. I also avoid plug ins in things like our bug tracker and build system. I'm the person that maintains our Redmine and Jenkins machines and over the years I've gotten lots of requests for plug-ins that do pretty neat things. I almost always refuse just because it makes updating such a pain in the ass. Generally, I do as little custom configuration as I possibly can these days. Twenty-five years ago customizing Enlightenment was how I spent about 30% of my time at the computer.
tasogare 7y ago
I shudder everytime I run npm install on my lab main software project, which downloads hundreds if not thousands of external dependencies and lists more than 400 vulnerabilities. On the reverse when I own a project, dependencies are kept to the minimum, often code I own too.
- collyw 7y ago
  We have a new React front-end for our application. It's fairly simple but the amount of crap installed by npm is incredible. Then trying to fix bugs is a nightmare depending on what needs done. This stuff was supposed to make our lives easier...
bob1029 7y ago

bertr4nd 7y ago

I have super mixed feelings on this. Minimalism makes for a clean, easy to understand codebase, that avoids some of the performance pitfalls associated with bigness. But sometimes it’s easy to build 80% of what you need, and then massively difficult to get to 100%, and the ease of getting to 80% can lead you astray. For instance, I can write a pretty fast matrix multiplication algorithm in maybe a few dozen lines of code. But then you look at OpenBLAS, Eigen, MKL, FBGEMM, etc. and you see thousands of lines of code. And it’s not because I’m 100x better at programming than the developers of these libraries, it’s that they’ve really put in effort to getting the best performance, in all corner cases, on all platforms. You could argue that matrix multiplication is an extreme case, and it is, but I think it’s still valuable to critically think about what you give up by opting for minimalism before you write off other people’s software as aimless bloatware.

user_50123890 7y ago
AKA "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." —Tom Cargill, Bell Labs
- jzelinskie 7y ago
  Is this the original version of this quote? I’ve both repeated and heard it many different ways. Most often “the first and last 80%s”.
hliyan 7y ago
The message I took from this article was minimalism in features and not necessarily code. And certainly not about library usage. If you're building a product, focus on building a few key features extremely well. I suspect that part of the reason for feature bloat is that a when product is assigned dedicated, long-running teams, it tends not to reach an 'end state'. The team would rarely say "okay, now the product is mature, let's place it on maintenance and go on to build something else". Instead, they may (unconsciously) continue to justify their existence by continuing to 'improve' the product.

dtwest 7y ago

This reminded me of the Twain quote: "I didn't have time to write a short letter, so I wrote a long one instead." Sometimes I don't know how to solve my problems with tiny amounts of code. It often takes skill and effort to come up with an elegant solution. But I agree it is something we should try to do when we can.

dctoedt 7y ago
> the Twain quote: "I didn't have time to write a short letter, so I wrote a long one instead." Friendly amendment: This has been attributed as being originally from Blaise Pascal in 1656 [0] [0] https://en.wikiquote.org/wiki/Blaise_Pascal https://en.wikiquote.org/wiki/Blaise_Pascal
- dtwest 7y ago
  Or maybe even earlier by Cicero. Seems like a common sentiment through history. Thanks for the link!
efxhoy 7y ago
My rewrites always end up much smaller than my original rushed implementations. I think it comes down to a few reasons * I get better at writing code. * Better understanding of the problem, the feedback from the first iteration usually tells me what the code actually had to do, not what my boss thought it needed to do. * A working but messy and bloated first iteration shows me that I can solve the problem at all, the rewrite let's me do it with some grace. The hard part is minimizing the time spent on the first messy implementation so more work can go into the good final iteration.
downerending 7y ago
The nice thing about writing a long letter is that it doesn't have to be maintained at significant cost over time. :-)

mouzogu 7y ago

It's very hard to write perfect minimal code from scratch. It takes a lot of foresight and consideration that mortals like myself simply don't possess. I think finding the optimal solution to any problem usually requires delving through a lot of crap, trial and error etc. Maybe this is why I find the trend towards minimalism a little bit condescending, if that's the right word.

clarry 7y ago
Or time to re-evaluate, refactor and rewrite. Once you've done that, you might gain that foresight. It's also known as experience. Too bad there are so many places where you're just constantly rushing to add new features on top of old stuff without ever having time to take another look at the design, fix it, and learn from it.

LaGrange 7y ago

"Be minimalist and don't use third party libraries and services. Except for ours. Use ours, because we don't have two decades of cruft under our belt excuse me, we're /minimal/. The article kinda uses a language of a sentiment I share to an extent (I think most devs are far too eager to pull dependencies — avoiding NIH doesn't mean you have to pull the entire 3rd party dependency, not if you can read a paper and implement it in a dozen lines), but while a completely in-house analytics package could be smaller, there's a reason why commercial packages are big.

anderspitman 7y ago
> while a completely in-house analytics package could be smaller, there's a reason why commercial packages are big But are those reasons your reasons, and do some of them warrant questioning in the first place?
tipiirai 7y ago
Yes. There is a reason commercial packages are big/bloated/complex etc. This is an opportunity for all of us.

swlkr 7y ago

Basecamp has a saying "underdo the competition"

justplay 7y ago

Minimalist design looks good but in practise when software were designed it was good at early stage but when complexity grows because of growing and expanding customer needs to meet different type of customer taste, software tend to get heavier and we end up writing lot of crap. Unfortunately.

mikewhy 7y ago

I'm all for minimalism, but the very first code example is a bad example. It's saying "look at how small your error handling can be" without mentioning that now you have to build something to inspect said errors. There is minimalism and there is punting the issue down the line, and this is an example of the latter.

tipiirai 7y ago
The core purpose of an error reporting client is to send the errors to the server. Anything more is some extra features (that we haven't had the need so far). Most of the logic resides on the backend, and it is not much to get the job done.

anderspitman 7y ago

Love it. I've been thinking [0] about this a lot lately. My rule of thumb these days when tempted to introduce a new dependency is try to build it from scratch first. I might spend 1 hour or 1 day, depending on my estimates of the costs/savings in the long term. I often find I just don't need the dependency. Sometimes I do, but after trying to build it myself I can fully justify why (to myself and others), and also understand how to use the dependency better. A few months ago I wanted to add an issue reporter to the help page of our open source genetics data visualization tool https://bam.iobio.io https://bam.iobio.io. I threw something together in less than 100 lines of code [1]. It doesn't even include any rate limiting or security measures. A couple weeks back I ran into a slight wrinkle that brought into question whether to keep using the tracker. I quickly analyzed the number of issues that had been submitted (including a recent influx of layman users), and simply removed it. Email support works fine for us based on our usage data. The decision was made easier because I didn't invest a bunch of time up front integrating with some external service, or building a 100% solution the first time around. > It certainly didn't help, that our former A/B testing tool emphasized short-term wins. When we added a huge sales overlay, it appeared to bring more conversions — since the return visitors were ready to take action. The new visitors probably hit the back button as soon as they arrived. This is great. All of your analytics insights are completely dependent on a) measuring the right thing and b) interpreting it correctly over the long term. EDIT: I do want to mention that these articles always point out downloaded code size as a primary factor in the decision, but I rarely see any data showing how the reduction in code size translates into an improved user experience, based on the principles of human perception. In my experience, the really big gains come from techniques like background fetching. Not that code size isn't important, but I think the main point should be the reduction in complexity that comes with it. That pays dividends in developer time and avoiding bugs, which translates directly to an improved user experience. [0] https://anderspitman.net/11/dependencies/ https://anderspitman.net/11/dependencies/ [1] https://github.com/anderspitman/issued https://github.com/anderspitman/issued

ratww 7y ago
> I do want to mention that these articles always point out downloaded code size as a primary factor in the decision, but I rarely see any data showing how the reduction in code size translates into an improved user experience, based on the principles of human perception. In my experience, the really big gains come from techniques like background fetching. Size is a huge factor when you're on a limited data plan. Maybe one website won't make a difference, but it adds up.

gumby 7y ago

I want to agree, but the story is incomplete. A lot of those products also started as MVPs, but accreted functionality in response either to customer demand or opportunities to monetize. The classic example of this is Word which started out as a small clone of Bravo but kept adding features that some subset of customers found indispensable until the whole codebase and UI became a mudball. I don’t really like MS software but a big part of the reason is a consequence of something I admire: their strong attempts at backward compatibility and preserving features that are actually used even if by a small minority. In other words: you can’t win.

anderspitman 7y ago
But as a user of a SaaS, how many of those customers are your customers?
- gumby 7y ago
  Well, take disqus: starts as a simple blog comment tool, saving you writing one. Then they add a nice feature where logged-in users can follow responses on other pages, which is nice for the blog owner as it increases engagement. But the payload got bigger and then starts to spy on you or your users. Then, as the product is free perhaps they add an ad or start to sell the spy data. And.... Or there's an address widget you used, but it kept being updated because even though you only serve the USA, other sites need support for various foreign countries... I don't want to write everything, but sometimes indeed these 3P packages are a moment of convenience leading to a lifetime of regret.

volument 7y ago

The title now matches the HN staff edit.

deleted 7y ago

[deleted]

mnm1 7y ago

Reductionist garbage. Their "minimalist" sentry clone literally does nothing as presented on the page. There must be a back end that stores errors and an interface to view them, etc. There's a reason most apps are complex: because the world is complex. Making software that does nothing and pretending it's as useful as real software in the name of fashion, "minimalism" is frankly unimpressive and uninteresting. There are no shortcuts in real life. No matter how good their sentry backend is, I guarantee it's not nearly as useful because they almost certainly left out the ui that makes sentry the useful tool it is. So tired of articles about fashion.

tipiirai 7y ago
Yes. There is a backend that stores errors and an interface to view them. This article simply compares the size/complexity/feature-richness of the frontend code. Sentry UI is good and we are familiar with it. So is ours. It's just more minimalistic.
hinkley 7y ago
Alton Brown complains about single-use kitchen tools. I find his theories on implements to be very sympathetic to my own. Invest materially and mentally into a few good tools and learn to wield them properly. Don't half-ass two things. Whole-ass one thing. For one of my hobbies I have a little speech about how you could get started with only 5 specific tools. And the punchline of that story is that it's actually 4 tools + 1 duplicate. Because the 4 are that useful on their own, and one of them wears out much faster than the rest.

carapace 7y ago

"Make it as simple as possible, but no simpler." ~Einstein

tipiirai 7y ago
Absolutely. This is highly correlated. Seems many minimalist geniuses are from Germany.
- carapace 7y ago
  And the Italians and the Renaissance, all those geniuses in one relatively tiny area. What's up with that?

layoutIfNeeded 7y ago

This page is completely empty on iOS. I guess the author should have made a minimalist static HTML page instead.

omk 7y ago
Is it HN's hug of death? I see the same on my PC.
- volument 7y ago
  It was a JavaScript error on the commenting component due to a comment from a user that removed their account. Now fixed. Thanks!
  - hinkley 7y ago
    Do you appreciate the irony that your article that brags about writing your own comment system was taken down by a bad comment?
    - tipiirai 7y ago
      Haha. I little — have to say. I'm actually quite happy how well it works. This is only the second time the commenting widget is in active production use.

xwowsersx 7y ago

I just see a blank grayish blue page.

volument 7y ago
This was due to a comment from a removed user. Now fixed. Thanks!
- useragent86 7y ago
  I still see a blank greenish-gray page. It appears to be because the BODY element has a CSS rule setting "opacity: 0", which appears to be for the purpose of enabling a CSS transition to fade in the page on load. Not exactly minimalism in terms of complexity, but it does appear minimalist in terms of content when the page is blank. :P Presumably the transition is triggered by some JavaScript. However, that JavaScript fails to execute because cookies are disabled, which causes an error: Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document. at new u (https://volument.com/v1/volument.js:17:858) at window.volument (https://volument.com/v1/volument.js:17:133) at https://volument.com/global/index.js?b:1:14673 at https://volument.com/global/index.js?b:1:60085 As a result, when cookies are disabled and JavaScript is enabled, the page appears blank. If I had a dollar for every time nowadays that I see a blank Web page because of invisible-by-default content that's made visible by JavaScript that fails to execute because it can't handle blocked cookies...
  - volument 7y ago
    This is now fixed and you can see the content when JavaScript is disabled. It's not as pretty yet but does the job for the Christmas day. Will check the localStorage thing next. Thanks!
  - volument 7y ago
    Now the cookie issue is also fixed.

NotATroll 7y ago

Feature minimalism is a good thing to strive for usually. Wrote my own dirt simple lazy loader & slider libraries, because I didn't need many of the features other libs had. On the flip side, if I need a reasonably complex component that would take quite a while for me to implement, like say. A date picker. I just grab the lightest weight, good looking one that I can find. (That also doesn't appear to be abandoned) Minimalism in everything, even minimalism.

cvaidya1986 7y ago

True.

baron816 7y ago

We embraced minimalism on my team a long time ago—no tests, no docs or comments, variable names are usually 1 or 2 characters, no indentation, no code reviews or QA, no meetings, etc.

imhoguy 7y ago
...even no code. /s
tgv 7y ago
That’s so minimal i’d call it basic.

mtm7 7y ago

This also applies to features. Easy example: if you’re implementing commenting on a social media app, you could use a textarea instead of embedding a rich text editor. The simpler option usually decreases your overhead and helps keep your product easier to use, easier to explain to potential customers, easier to develop... It’s easy to keep adding stuff (especially if your customers are requesting it) but you should evaluate if it’s truly necessary.

codr7 7y ago

The most important kind of minimalism in my mind is YAGNI. Every single time I coded something I didn't need yet; I never did, at least not the solution I came up with. And once the complexity is in there, it's very difficult to scale back. This applies to everything I've worked on, from personal projects up to 10KLOC to 3MLOC commercial systems. It's just never a good idea from my experience. The code [0] I write these days tends to be pretty raw, but every single line fills a fundamental purpose. [0] https://github.com/codr7/libceque https://github.com/codr7/libceque

meowface 7y ago
YAGNI conspires against me. When I spend a lot of time building potential future features or creating a bunch of abstractions, I pretty much always never end up using any of them and it ends up as a (potentially huge) waste of time. When I'm building something and thinking about whether or not to make it more abstract / support potential future features, and decide "nah, ain't gonna need it", inevitably within a week or month I get some feature requests for those exact things, often requiring me to do a lot of rewriting from the ground up which I wouldn't have otherwise needed to do if I had started off with a more abstract model or added those features when I was initially considering them. (Obviously this isn't literally always true, and I'm getting better at it over time, but those are the ones that stick out.)
- quickthrower2 7y ago
  This is the pain with “agile”. The problem with building the skateboard first and morphing that into a car (as per the cartoon strip meme/trope) is that a car is nothing like a skateboard. It’s a rewrite. If you can know you need a car upfront then you save a YAGNI/OFINI cycle. I’ll let you guess what OFINI means :)
  - codr7 7y ago
    It's certainly no Silver Bullet, and can be taken too far; but it was born as a reaction to the industry going way down the opposite drain. At least at that point, you know what kind of car you need. I still find it easier to refactor a simple solution into a more elaborate one than going the other way, easier to motivate as well as ripping out features is pretty much impossible in a corporate setting. Truth is always somewhere in between the extremes.

echlebek 7y ago

If you value minimalism, then why doesn't the page load any text when Javascript is disabled?

volument 7y ago
Because JS-disabled clients are an edge case and a minimalist approach attempts to solve most cases with the least amount of code. Nevertheless, we will make our site work with JS disabled. Thanks!
oftenwrong 7y ago
"chickenshit minimalism" https://idlewords.com/talks/website_obesity.htm#minimalism https://idlewords.com/talks/website_obesity.htm#minimalism
- tipiirai 7y ago
  That's a good reference article indeed. I remember that. Seems Chickenshit Minimalism is defined as "the illusion of simplicity backed by megabytes of cruft" — which is not in play on the article. But yeah... need to make that page work on non-JS browsers. Thanks!

benblack86 7y ago

There seems to be a bug in the comment form on their site. It gives me the option to edit/delete the last comment and when it asks me to create an account, it shows me someone else's email address. I feel like this is the major reason for not rolling your own.

deleted 7y ago
[deleted]
volument 7y ago
The email address issue is now fixed. We'll fix the edit option visibility issue a little later (Christmas time happened) Bugs should not be a reason to give up rolling your own stuff, but I'm sure you didn't mean it that way. Thank you for reporting this issue!

dsalzman 7y ago

KISS - Keep It Simple Stupid is my mantra

xwowsersx 7y ago

What do those pie charts show (e.g. Disqus vs Custom)? No idea how to read those.

xwowsersx 7y ago
Oh it's the size of the code in thousands of kilobytes?
tipiirai 7y ago
It's comparing the size of the code.
- xwowsersx 7y ago
  Weird though, no? Am I wrong to expect a pie chart to represent the "total" or "100%" and the slices a portion of the whole? I could be wrong, but this seems like the wrong usage of the pie chart.
  - volument 7y ago
    On those pies, the example SAAS product is the whole 100% and the tiny white slice is the custom alternative.

Mr_Shiba 7y ago

Usually product owners and business are the biggest enemies of engineering minimalism - [PO] A/B testing says button must be outside table - [DEV] But that makes the code unreliable and overcomplicates things the framework is not designed to do that, maybe if we include a regular link... - [PO] BUT AB TESTING, ACQUISITIONS, CRITICAL MISSION, bla bla bla

ggregoire 7y ago

> If you want a cheap trick to make a difference — here's one: minimalism. Focus on the bare essentials and get rid of the rest. It's an easy way to differentiate, because most others are doing the opposite: tons of crap. For a moment I thought this was about real life minimalism.

dana321 7y ago

A minimal core with just enough functionality to be useful, then a plugin framework with hooks for all the other features that everyone else needs to build in. A minimal phone with just enough functionality to be useful, then an app store to get all of other functionality you need via downloadable apps. Its a model that works well, providing an ecosystem to anyone who wishes to extend. Code is kind of the same now.. Get the basic thing going, then people fork it, improve it, submit patches, sometimes over decades. The worst software imho, is a closed architecture that has the kitchen sink included that nobody can extend. Modularism and a pluggable architecture is much better than just minimalism on its own.

jarofgreen 7y ago

This touches on the topic of doing something yourself vs getting someone else to do it for you, and I would recommend anyone interested check out Wardley Mapping. https://en.wikipedia.org/wiki/Wardley_map https://en.wikipedia.org/wiki/Wardley_map It's a way to generate discussion in your company/project/whatever about when it's appropriate to custom-roll, and when you should use commodity.

kevindong 7y ago

First and foremost: beautiful and performant website. I don't understand how exactly the Volument product actually performs A/B testing (or distinguishes between different variants). The only code docs [0] I've found are very, very light on details and doesn't mention how the active variant is detected. To be fair, the product hasn't launched yet so perhaps the docs are currently internal-only. That being said, very interesting idea of linking engagement to eventual conversion to get "results" faster. It certainly seems reasonable that there is a causation relationship (increased engagement, e.g. more scrolling and longer visit duration, eventually leading to increased conversion), but I don't know how statistically valid that is. [0]: https://volument.com/learn/client-api https://volument.com/learn/client-api

volument 7y ago
Here's how Volument works: https://volument.com/learn/volument-data-model https://volument.com/learn/volument-data-model A/B testing in Volument is quite different from, say Optimizely. You can compare a lot of things in apples-to-apples fashion: landing pages, inner pages, market segments, campaigns, site versions, etc. And you can compare both how much traction something generates, or how engaging a page is. The causation thing is just something we measure. We measure how people behave on their first visit, how intensively they return, and how much they convert. It's not about the statistical validity, it's about choosing metrics that are essential for conversion optimization.

Tade0 7y ago

We can finally pursue our minimalistic religion, iterate quickly, and collect maximum wins. Religion implies dogma, and I don't like dogma in my field. Side note: the biggest takeaway for me here is: be careful when writing such self-confident articles. The general public doesn't take kindly to such displays.

pknopf 7y ago

This echos a sentiment I've been feeling on a few recent posts of mine. The argument against Entity Framework, and for micro-ORMs. - https://pknopf.com/post/2019-09-22-the-argument-against-entity-framework-and-for-micro-orms/ https://pknopf.com/post/2019-09-22-the-argument-against-enti... You don’t need Cake anymore; the way to build .NET projects going forward. - https://pknopf.com/post/2019-03-10-you-dont-need-cake-anymore-the-way-to-build-dotnet-projects-going-forward/ https://pknopf.com/post/2019-03-10-you-dont-need-cake-anymor... My blog is also written from scratch, using a stupid tool. https://github.com/pauldotknopf/pauldotknopf.github.io/tree/staging/generator https://github.com/pauldotknopf/pauldotknopf.github.io/tree/...

crazygringo 7y ago

Unfortunately I can't agree. There's an old quote I can't remember the exact source of, that "Microsoft Word users only use 5% of its features... but each user uses a different 5%." It's not bloated. It's just that other users have different needs from yours, and you're ignoring other users, assuming they're the same as you. But they're not. It's easy to write a minimal version that works on your dev machine in your browser. But now get it to work on all browsers on all devices on all OS's. And now build in all the little feature that big clients require for legitimate reasons. And now ensure it works with several legacy versions of API's, etc. Is it "bloated"? No. It does what it needs to do.

luord 7y ago

One adage I like is "the best code is the code you don't write", meaning that we should write as little as possible because every new line is a potential new error(s).

collyw 7y ago
I agree. I wish more people had this attitude.

cbanek 7y ago

> We have a single developer taking care of the codebase. Does Optimizely need ten people to handle theirs? Or twenty? We don't know, but one thing is for certain: 20 people make more redundancy, technical debt, and bugs than one. I get the point that having too many developers writing too much code can make it too much to handle. But I've seen what one person operating alone in a vacuum can do as well, and it is not pretty. It seems like really you want maybe 3 people to really understand some code. That gives you a good bus factor, but not so many people injecting ideas and patterns that the code becomes unwieldy. More important, it gives you extra code reviewers who can push back against bad code smell and hopefully find bugs, or at least try to test it. 1 might be better than 20, but 3 is better than 1.

deleted 7y ago

[deleted]

abraxas 7y ago

If disquss is hailed as an example of good design we’ve fallen so hard...