Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Minimalism – An undervalued development skill

volument.com

Post reply on HN
Print view View original

161–170 of 179 posts

Re: Minimalism – An undervalued development skill

#161

Post by collyw »

tasogare wrote: post #40
_wldu wrote: post #21

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…

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.

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

Re: Minimalism – An undervalued development skill

#162

Post by cbanek »

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

Re: Minimalism – An undervalued development skill

#165

Post by xwowsersx »

tipiirai wrote: post #132
xwowsersx wrote: post #110

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

It's comparing the size of the code.

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.

Re: Minimalism – An undervalued development skill

#166

Post by collyw »

quickthrower2 wrote: post #119
meowface wrote: post #113

Earlier quoted context omitted.

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…

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

Agile could never have solved this problem well. But it did encourage the problem to appear by claiming that it could.

Re: Minimalism – An undervalued development skill

#167

Post by volument »

xwowsersx wrote: post #165
tipiirai wrote: post #132

Earlier quoted context omitted.

It's comparing the size of the code.

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.

On those pies, the example SAAS product is the whole 100% and the tiny white slice is the custom alternative.

Re: Minimalism – An undervalued development skill

#168

Post by vendiddy »

sanderjd wrote: post #51
vendiddy wrote: post #43

Earlier quoted context omitted.

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…

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

Re: Minimalism – An undervalued development skill

#169

Post by efxhoy »

dtwest wrote: post #24

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.

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.

Post reply on HN