Hacker News Reader

Comment by bertr4nd | Hacker News Reader

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.

View on HN

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.

Microsoft applications released as store apps were an attempt at minimalism in features. Their music, skype, mail, even the control panel replacement "settings." Windows 10 has been cutting features left and right.

To Microsoft, minimalism means:

Rebuild a popular piece of software from scratch

Release the NEW improved shiny app that follows a new design fad. Gloss over the fact that it's unreliable, slower, more crash prone & lacks over 50% of the old apps features by promising fix the 'issues' and missing features with future updates.

Retire the old but fully featured (still working) app while the new stuff still lacks basic functionality.

Retire this NEW stuff when it's still lacking promised features. And replace it something that lacks even more features.

Windows 10's attempts at minimalism means that a feature you rely on today might be gone forever with the next update or hidden - requiring a treasure hunt.

There's just one app that MS didn't screw up by going minimal -- OneNote. I still can't figure out the Win32 version. The store version just clicks for me. They once included an excellent RADIAL Menu for OneNote but removed it inexplicably.

(Radial Menu of OneNOte https://www.youtube.com/watch?v=Job4Rg-sbDo)

Developers pursing minimalism tend to release software that:

Require too many steps to accomplish simple tasks because controls are HIDDEN away behind hamburger menus and/or frustrating gestures. Example - windows 8's charm bar that required moving the mouse off screen to the top right corner to reveal the settings menu.

Have too much white space - and have tiny text (self explanatory)

Replace intuitive, native, user friendly controls with a Minimal but frustrating version - example removing the Underline of hyperlinks in webpages, even changing the mouse icon on hover. Sometimes, links and normal texts are indistinguishable. Another example super tiny (or hidden) scroll bars

Going mobile only - even when the site / service doesn't use any mobile only features.

Mobile first - Mobile first and minimalism are often mentioned together and is an excuse to release featureless but bloated websites or apps.

MacOS has been going in a similar direction. But Microsoft really has user-hostile faux-minimalism down to an artform, consistently removing and hiding features for minimum user benefit and maximum irritation.

Small case in point - the search bar in Excel 365. Until recently it was a text box next to a magnifying glass, and you could type into it.

Now it's just a magnifying glass. You have to click on it to reveal the text box. Only then can you type your search term.

This change produces absolutely no user benefit. There is no rational reason to add an extra click. Long-term users now have to go through "Wait, what...?", where previously muscle memory would just work.

Another example: the AutoSave switch in Office 365. Users quite understandably assume that "AutoSave" means the file is saved automatically.

In fact this is a OneDrive-only form of AutoSave. AutoRecover - a different and much older local drive auto-save feature - is unrelated, and has a separate setting in Preferences.

Providing a minimal switch in the UI which doesn't mention the distinction is guaranteed to confuse anyone who doesn't already understand the difference - especially when clicking the switch tells you AutoSave isn't available because of your privacy settings, and doesn't mention OneDrive at all.

Windows 10's networking settings is the perfect example of this. You open the Windows 10 network settings, find the button to get to the Windows 7 version, then click the button to get the XP version that actually gives you a list of all the network interfaces with the controls you want.

It's both. Minimalism should be applied to all layers from the big picture (features) to the implementation details.

> focus on building a few key features extremely well.

This. You nailed it.

Recently, on my first software job (freelance) I messed this up. I had very little opportunity for contact with the client and they were slow and unreliable with providing feedback. I could tell we would go over schedule if I didn’t produce a lot more work with each feedback cycle and I desperately wanted to do a good job so I let myself get weighed down with imagining things that they might think I was stupid for not including in each version.

I am still unsure of how I should have approached this, but I know I messed up because at the end it was just way too much effort to fix bugs and add features, but I didn’t have the time to refactor. If anyone has advice, I would be grateful.

Send a spec of what’s reasonable given the budget and ask for approval before continuing. If you’re worried about bugs increasing the time consider adding a contingency to the budget. Pad everything out a bit. If this runs to multiple cycles, give them deadlines for feedback and push out the schedule if you don’t hear in time.

Also if it’s your first time and you need the cash and experience, you can overdeliver a little. But if nobody is ever unhappy with you then be aware that you probably are overdelivering.

1. Having such negative experience pushes you to make a harder, but better, decision in the future. Embrace this, it will happen repeatedly in different ways to you forever.

It is the power base of personal change.

2. It's ok to make the client responsible for everything in writing. Especially if you do not have a deep committed relationship with them.

I have clients I have worked with for over 15 years and they don't even need a quote from me to start work, and they send me a check for any reasonable amount up front.

I have other clients where I spell out every single detail before I start and I do not deviate (add or subtract) from this list (for both our benefits) without written request from them and possibly a fee change.

3. I give away free work to many clients for many reasons. Some I don't even let them know, and others I make sure to put it on the invoice as a discount and rate. This way they know that I did the work, I did it for free, and they should recognize that. Also so that it's easy to charge for this work in the future.

A lesson I learned hard was a few failures:

1. When to start: I did a bunch of work when a client said ok on the phone. When I invoiced he was mad because he didn't remember saying "ok" to start work. So, now I only start work with an email record, period. Even if it's annoying, even if it delays work, even if it makes the client annoyed. Every single time I ask "can you send me an email with the ok to start this work?" (or I prompt them with an email and they reply) Again, some clients verbal is ok, but only if I know them really really well. (ie, lots of previous work with them)

2. Extra work: I did a bunch of extra work/features on one project, and they wanted me to support the extra work also for free forever. (forever... sigh) And were angry when I said I couldn't...

3. Accountability for timelines: I had a project that every weekly meeting more features got added to the project. We spent half to over half our budget in meetings. (yes that bad) So I made sure to document all time spent on everything one month. The next month the lead project manager started cutting back the meetings instead of us devs complaining about not having enough time, the project manager _knew_ we didn't.

4. Specs and Expectations: Numerous times I "imagined" what the client actually wanted because I knew better than them. I would build something expecting to be paid for it (or at least appreciated) and it would be presented and the client would ask for it to be _removed_ from the project.

This was the last kick in the teeth I would ever take from this, ever, ever again.

Then later a new client (a state university) had visual layouts of interfaces given to me. I had learned some lessons about being screwed over before, so I was going to stick to their layouts no matter what. After it was built, they were _really_ pissed, and had the gaul to say to me:

"Why did you build it this way?" And I said "Because it was how it was designed and specced out". Their reply?

"That isn't what we wanted, you were supposed to make what we wanted."

Unreal, but I won this argument hands down. No one can read minds and people who expect you to don't have a reasonable argument if you provide your experience on why you will never do this again. What can they say to you?

My long term clients _never_ give me a hard time about anything extra I do, ever. I know them, they know me and they say "make something that solves this problem the best way you can", and we may tweak, but we respect each other and I fix my errors, and they pay for theirs and we meet happily in between no matter what.

Also, I will no longer support software for free indefinitely, I say I offer free bug fixes for 6 months. Any new features is paid work. And support after 6 months will need to be negotiated. (all this depending on the client and project)

I state as much as possible up front about everything (in writing) so there are as few arguments as possible (I hate arguments with clients they really suck). Doing this extra work kinda sucks sometimes, but the older I get the less I have to do this. The first time it saves your ass you will be happy. And as soon as you write it and hand it over you will have instant peace of mind.

It may take you a few projects to get the handle of these ideas, but it's obvious you recognize there is a problem. But communication and clear expectations is the solution. I have also learned to say "Sorry, I meant to state this up front, I failed to do so, so I will give you X for free for my screw up, but I still need Y to do Z"

Keep at it, what you are facing is normal, and your desire to do good work is commendable and will pay off in the long term in ways you can't imagine.

Cheers!

That's interesting that extra work got you on the hook for extra support. Could you give a little detail about the extra feature you added that they asked you to remove? That's the sort of experience that I don't want to have myself.

Been in the industry over 20 years now, so I am sorry I for not being more specific with my examples here. (I learned this lesson many years ago) But here's some recollections.

In the process of building something if I added say a color picker or a calendar date selector, but the client wanted just a text field. Then the color picker/calendar date selector has an issue with a really, really old browser and I have to spend time debugging it at their request. (again because "young and inexperienced" me can't explain it properly)

My current self would just remove it, and/or explain it will cost extra. Soo 100% of the problems I described above are solved with mature communication that I learned the hard way.

--Features requested vs features built--

A client will ask for 100 features up front, we build 10 and by the time we have an alpha, he bails on 90 of them, and adds 20 new ones. Of those we bail on half again. This is so normal that I now bring this up at meetings to help us prioritize development.

I have had very long term clients ask me to remove something, then later ask "where did that feature go?", ha. I have to laugh at this, and I explain to them "I don't remove features without written request, if you want me to spend time looking up why this is removed (likely from an email) I can do that..." But they never have me do this.

I have built extra templates/views, sorting features, even tools to add/remove things the client didn't want users to have access to, so I had to delete them. (no one would pay for a toggle to disable a feature they didn't request, hence the delete on my dime)

One client even went so far as to say he didn't want _his_ clients (it was a CMS for web sites) to see how easy it was for him to build sites using the software. (his clients had access to the software for content maintenance)

I had built an LMS (Learning Management System) with a group once (again, I was young and eager to impress) and I vaguely recall adding some features for working with quizzes or something, but because I had at least 2 PhD's on the team, that mightly protested something about "that isn't how that process is supposed to work...blah blah", that I had to remove it.

I was the sole developer on a project with at least 2 designers and 6 (yes 6) project managers... ugh. They asked for the dumbest things and I would protest a little by building it a "smart" way that wouldn't piss off the users. But I had to revert everything and try to hack my way through making their overly complex visual designs work on web 1.0 _and_ support super old versions of IE at the same time... because project managers know what users want best.

--Design alterations on the fly--

When CSS was still immature, and many layouts were very hard to build, I made some complicated things in a mapping program that insurance workers would use to map out and plan routes and such. Google maps was very new (so maybe 2006/7 ish) and we were building on top of this. And I would build layouts that I thought were ideal for users, because the client was just the business guy he left the design work up to me. And I had to rework the design a few times. Even after I had already specced everything out, and the client agreed.

The lesson here was that the client blamed me for bad design decisions based on our poor communications. I had visually laid out the entire app before building it, but because we kept redesigning the visuals, doing a visual spec for each change was overwhelming. So I just made changes sorta willy-nilly based on meetings. And the client would come back and call a design decision a "bug" so he expected me to fix it for free... ugh.

--Verbal change requests--

I had a client freak out on me (he had a temper and I was young and didn't have courage) claiming I had "told him to do X & Y" on a phone meeting 6 months prior. And therefore I was on the hook to fix it for free. I don't even recall what it was, but I remember the verbal bashing I got.

This is where I learned to stand up for myself in a mature manner. I told him I don't recall saying that, and that I make a point to only make changes like he was describing in writing. And I pointed out that it was unfair and unreasonable to expect me to remember what I said on a phone call last month, let alone 6 months ago. And this is one the reasons I get do changes like this in writing, to avoid these exact conflicts.

He was angry, and I weathered the storm, but it was a valuable lesson. Not everyone is nice and reasonable, but you may have to work with some people this for a time. And having a good set of communication and process rules keeps you from getting blamed for something that isn't your fault.

This is getting long, but I didn't mean to imply "support" was some huge on-going thing for some giant feature I had spent days on. But more edge cases that the OP was bringing up, but seriously impacted my motivation on the work and affected my relationship with the client.

Wow, lots of experience there. I guess I should not expect written communication to cover me if I want to do anything that doesn't come out of Jira.

I think it all depends on your client and your relationship with them.

If it's a large corporation with no relationships possible (ie, this is a hard learned lesson in itself), I'd likely want as much in writing as possible.

If you are working with a small shop with people you know well, maybe it doesn't matter so much?

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

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

I've also gone the other direction from minimalism in codebases, and consider it a positive change as a developer. As a junior, I always wanted to roll my own: roll my own advanced multi-select autocomplete input, roll my own Modbus communication library, roll my own internal tool for the company to use rather than an existing product, etc. So what happened? Now we have a relatively buggy implementation that we have to support.

Now? I see things differently. I look at the problem and evaluate existing solutions. 90% of the time, there's a battle-tested open-source (or cheap) solution which fits our requirements that I can quickly integrate without burning piles of company cash building and supporting my custom crap. Yes, it's not minimalist. But it's overwhelmingly a better decision most of the time.

(Mind, I suspect one's experience is highly dependent on the developer ecosystem one is in. Just my 2c.)

This can be considered minimalist. For example:

We use Heroku instead of a custom AWS setup We use Sentry instead of a hand rolled exception tracking system We use Postgres instead of a custom

We are minimalist in the sense that we minimize the code we have to maintain in house.

That there are two opposite interpretations of "minimalist" in the article and thread with respect to build-new vs. use-existing decisions probably suggests that it isn't a very meaningful metric.

It would be ideal if you could start with the tactic the article advocates and then easily switch from a stripped down custom approach to a more common denominator standard approach exactly when it begins to have better ROI. But in the real world, switching costs are high, ROI is impossible to measure perfectly, and there are other variables that matter a lot (like your future employees' familiarity with tools). My personal preference is in line with the article's suggestion - I strongly prefer building little purpose built things to reading documentation for and hacking around inconvenient parts of standard tools - but I tend to think it makes better business sense to go with the standard tools for things that aren't directly in your project's core competency.

It's best handled case by case as with most decisions.

Should one build their own database? Probably not. That introduces more complexity.

What about an npm package to pad strings? It's simpler to write that logic than to deal with one more dependency.

Giving two extreme examples to illustrate that "minimalism" may not be a useful criteria.

So seems like we're in agreement :)

Minimalism isn’t a metric, because as you say, there is no object or method of measurement given. Might as well say that your metric is “betterness”. Better what?

I've found that, to some extent, the reason that I tend to roll my own implementation of various things is that I don't have the authority to add dependencies to our codebase.

Some of the transition from rolling your own to just using something else probably comes naturally from gaining sway over a project to the point that you can actually make the call to import a new package.

I've followed a similar trajectory over the years, but I'm currently back to minimalism. Perhaps the pendulum will swing again. In any case I'm not as extreme about NIH as I used to be. I try to make the decision for pragmatic reasons, not emotional ones.

What pushed me back was the current JavaScript landscape, with endless breaking changes to the major UI frameworks and constant security vulnerabilities being reported in our code bases by GitHub (they're even doing auto pull requests now).

In my experience, updating any decently sized web app project is a huge pain, and very time consuming. Everything is constantly moving. Libraries, frameworks, build tools, node, etc etc. These are all dependencies.

It looks like yours was a case of NIH syndrome. That has nothing to do with minimalism.

NIH is absolutely relevant here since article showed 3 (out of 3) examples of it.

The comment was relevant, and welcomed. Sorry if my response gave other impression. I just don't agree with that premise of the article.

There is extremely bloated software that can be replaced by a few lines of code but, in general, minimalism is hard to get right and requires a high level of expertise.

I agree with what you're saying about how the greedy approach to covering all your cases isn't usually optimal, but if a manager tells me that their rat's nest of a 30-year-old enterprise software codebase is an outcome comparable to the decades of research put into matrix multiplication algorithms, I'm going to assume that department is bonkers until proven otherwise.

Often these systems grow according to that greedy approach, sprouting a feature here and there as sales tells the team to add things, and then you're left with a system that was more grown than designed.

I wish I could read the article but it got the hug of death, so I'm basing this on your comment:

I agree with you -- that's why I think clean code is less important than clear boundaries. All that messy code for matrix multiplication poses a lot less risk for consumers of it when the API is clear. eg. Pass in a 2D array of integers, receive an integer in return.

That's pretty obvious for me to say, I think, but you run into situations where an app, for some reason or another (the main culprit IMO being Not-invented-here-syndrome), couples code like these matrix calculations to constructs unique to the codebase (objects, database structure). That's when it turns to hell.

You bring up a good point, but I think the takeaway is that you need to be thoughtful about the process, not necessarily that one way or the other is always right.

How often are breaking changes introduced to the APIs of OpenBLAS or LAPACK? I would guess approximately never (I could be wrong though. I'm actually surprised and a bit disturbed how much activity the GitHub repos are still getting).

Beyond that, how much of the API do you need, or are likely to need in the future? Why not implement that matrix multiplication yourself to start, but abstracted in a way where you can drop in OpenBLAS in the future? You can even copy their API if you don't want to abstract, and include a bit of profiling to warn you if it suddenly gets very slow on a certain platform.

In my experience the chances are good you'll never need that last 20%.

I believe there's work to be done for each new CPU architecture (Broadwell, Skylake (AVX-512), Cascade Lake, let alone ARM or other architectures). The code needs to be updated for things like L1 cache size, number of registers per core, and number of adders per core. So there will likely continue to be frequent work on BLAS implementations until there's some very smart optimizing and profiling compiler (which is related to what ATLAS does I think).

That activity is probably grad students and post-docs looking to publish any overall optimizations or implementations for exotic architectures they can come up with.

Some of the activities in the last decade includes significant improvements in the documentation, build and test automation. The code might have been good before, but the usability and quality of testing has improved significantly.

If true; even more disturbing.

If you need the full power of BLAS, etc then it’s absolutely the right call to use the library. The situation outlined in this article is different: you just need one function (say dot product) and so the minimalist approach is to not take the dependency.

I surely understand what you are talking about. However, the three examples mentioned on the article are such examples where only 0.5% of the code does the core job. I'm sure there are more such examples, but doesn't apply to all project of course.

Yes, something like that is the reason libraries like React exist, even tho many devs can write a VDOM in under 100 LoC.

Why not use APL for matrix multiplication

Minimalism without sacrafice in performance

Look at kx.com, shakti.com

Do not use APL if your main requirement is fast matrix multiplication. I implement Dyalog APL—our matrix multiply is not as good as typical BLAS implementations and I think this is also true of other APLs (most currently maintained APLs are not performance-focused).

J replaced their matrix multiply with a good BLAS-based implementation a few years ago but only supports double-precision floats and tends to be slower than Dyalog for other operations. I don't know about K's performance.

I feel like this misses the point

Those projects are organized around one monolithic package of code that could be broken out into there separate libs and composed together in novel ways.

A GUI is just the set of default compositions an opinionated team felt would connect best with an abstract perfect customer in mind.

Each chunk of code could be managed then by smaller teams, and the inputs/output spec more easily understood by all.

Unix composability at scale is what the web and devops has been peddling philosophically, IMO.

Lots of people like the desktop metaphor. Personally more of a “computer is a text editor I use to compose interesting outputs”.

Reply on news.ycombinator.com