Basecamp has a saying "underdo the competition"
Minimalism – An undervalued development skill
41–50 of 179 posts
Re: Minimalism – An undervalued development skill
#42This 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 t…
I'm glad to hear other people talking about how great the Intel 82599/Niantic was and how they have come off the rails since then.
I'm so fed up that my new year's resolution is to make a new NIC that's like the 82599 but more so.
Re: Minimalism – An undervalued development skill
#43I 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…
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…
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.
Re: Minimalism – An undervalued development skill
#44Minimalist 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.
Re: Minimalism – An undervalued development skill
#45I'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.
Re: Minimalism – An undervalued development skill
#46At 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.…
> Nobody could really answer that.
Sounds like it was dismissed without evaluation, your comments seem to support this, you seem to think it offers little or nothing over Go’s standard bare-bones testing.
Ginkgo doesn’t re-invent the wheel regarding Go’s out-of-the-box testing, it builds upon it. Ginkgo tests run just fine with ‘go test’, except the output is a little less detailed/pretty. And you can still use standard Go tests alongside Ginkgo, they play just fine together.
Go’s OOTB test story is pretty good. But one cannot easily have hierarchically structured tests, the output doesn’t clearly describe what a failed test was testing, one cannot easily enable/disable whole sections of tests (while getting reminders that tests are ‘pending’ so one doesn’t forget about them later), randomised test ordering, clean/easy before(after test methods. And those are just the features I use, from the top of my head — it does much more.
And Ginkgo is usually paired/installed with Gomega. Assertions written with Gomega are very easy/nice to read, no matter what kinds of values one is checking, and Gomega also includes all manner of helpers for assertions and matchers.
Go’s OOTB testing is pretty good. But eventually one will realise that one is re-inventing wheels when writing yet another bunch of testing helper funcs — then the path either leads to building one’s own library of helpers, or realising that someone has already done a good job of this already.
I’ve been programming Go for a few years now. For some smaller projects, I just use the standard testing stuff, but for others I can write more readable tests, test more thoroughly, and write such tests in much less time when I use Ginkgo and Gomega.
Re: Minimalism – An undervalued development skill
#47I 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…
I am the same way with 3rd party libraries. My policy is that I will allow the use of a 3rd party library if it can bring some immediate value without compromising the downstream roadmap of the product. Additionally, any 3rd party library used should be continually evaluated for risk. Keeping an eye on how frequently certain things are maintained, their various roadmaps, etc is quite the chore. But, if you don't do this you are setting yourself up for disaster. At the slightest hint of something looking like it would compromise us in a 3rd party lib, we will take the time to implement it from scratch 100% our way.
That said, there is some interesting nuance I am starting to see in various communities. For instance, in .NET land, the Newtonsoft.Json library is extremely popular and was eventually scooped up into the official Microsoft API (and then further enhanced performance-wise). As a result, we had a clean migration path from a 3rd party library to the 1st party's API implementation of the same functionality. This is the most ideal situation from my perspective, and I would really like to see more of this.
Perhaps a new system from various vendors where a 3rd party library author can apply for 1st party sponsorship and/or certification of their library. Since Microsoft owns GitHub now, this could be something they consider integrating directly into the product. GitHub already has quite a few features that could help to support such capabilities (I.e. static code analyzers, action pipelines, etc). Additionally, if you are using a CLR language like C#, exceptionally powerful tools like Roslyn are available.
I realize this may create certain perverse incentives, but seeing a "Certified by Microsoft" or similar label affixed to a GitHub repository would give me a substantial boost in confidence when using this author's library. This would also serve as an excellent canary (i.e. if this status is revoked based on malicious activity, too many incidents, lack of maintenance, etc.).
Re: Minimalism – An undervalued development skill
#48I'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.
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.
Re: Minimalism – An undervalued development skill
#49I 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…
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.
Re: Minimalism – An undervalued development skill
#50Love 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. 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.