7 ms·

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 bi

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.
- selman89 7y ago
  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.
  - ximeng 7y ago
    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.
  - RobertRoberts 7y ago
    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!
a_wild_dandan 7y ago
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.)
- vendiddy 7y ago
  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.
  - sanderjd 7y ago
    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.
tipiirai 7y ago
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.
anderspitman 7y ago
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%.
- robmccoll 7y ago
  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.
  - anderspitman 7y ago
    If true; even more disturbing.
  - pletnes 7y ago
    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.
- lightcatcher 7y ago
  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).
odyssey7 7y ago
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.
pbourke 7y ago
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.
k__ 7y ago
Yes, something like that is the reason libraries like React exist, even tho many devs can write a VDOM in under 100 LoC.
3xblah 7y ago
Why not use APL for matrix multiplication Minimalism without sacrafice in performance Look at kx.com, shakti.com
- mlochbaum 7y ago
  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.
  - deleted 7y ago
    [deleted]
skipants 7y ago
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.
bdheik8 7y ago
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”.

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.

selman89 7y ago
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.
- ximeng 7y ago
  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.
- RobertRoberts 7y ago
  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!

a_wild_dandan 7y ago

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

vendiddy 7y ago
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.
- sanderjd 7y ago
  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.

tipiirai 7y ago

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.

anderspitman 7y ago

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

robmccoll 7y ago
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.
- anderspitman 7y ago
  If true; even more disturbing.
- pletnes 7y ago
  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.
lightcatcher 7y ago
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).

odyssey7 7y ago

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.

pbourke 7y ago

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.

k__ 7y ago

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

3xblah 7y ago

Why not use APL for matrix multiplication Minimalism without sacrafice in performance Look at kx.com, shakti.com

mlochbaum 7y ago
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.
- deleted 7y ago
  [deleted]

skipants 7y ago

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.

bdheik8 7y ago

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