Live data from Hacker News

A Plea for Lean Software (1995)

liam-on-linux.dreamwidth.org

61–70 of 136 posts

Re: A Plea for Lean Software (1995)

#61

He was calling 1995 text editors which used 4 MB of RAM incredibly bloated compared to the lean software of his youth which ran in 32 KB. Now we do the same, but we look at the text editors of 1995 which used 4 MB of RAM as incredibly efficient and well made, paragons of craftsmanship. Things never change, the old generation fights the new one and calls it stupid.

BBEdit was first released in 1992; I'm not sure what that version was like, but I'm still using it now. That said, the version on my disk right now (30.3 MB) wouldn't have fitted into the RAM of the Performa 5200 I had in the 90s (8 MB initially, can't remember what I upgraded it too in the end, 24 or 32…)

Re: A Plea for Lean Software (1995)

#62
post #6

I've come to suspect the normal way large companies are organised makes performant software almost impossible. Features are celebrated and make money - whereas performance can be gradually salami-sliced away, with nobody advocating for it. If you can add a feature and it adds just 50ms to a 300ms pageload - it's unlikely anyone is going to block its release on performance grounds. And once the feature is released, th…

> Features are celebrated and make money

I like your take, but I'm not 100% sure this is accurate.

Obviously to some extent features make money, and "featureless" software by definition couldn't exist. But I think a lot of software contains features that don't drive demand at all - the worst contender for this that I can think of is [Microsoft Teams' Together Mode](https://www.microsoft.com/en-us/microsoft-teams/teams-togeth...) which I doubt has led to a single sale of the product worldwide, but probably adds some maintenance burden.

I think a bigger part is, like you mentioned, the organisation of companies. Engineers like building things, and although maintaining software and improving performance can be rewarding, you'd struggle to find developers that are happy to only do that. Features also lead to promotions more than maintenance, so there's a strong personal incentive to create features even if they don't have a business benefit.

Re: A Plea for Lean Software (1995)

#63

Test your software on shitty hardware. It's great that your development computer has 32 cores and 64GB of RAM. But your users aren't so lucky.

This 1000x. Every developer should get a Pentium 3 500 MHz and 256 MB of RAM and figure it out from there. And yes I dogfood, I have a small 15 year old laptop with a Core 2 Duo CPU and an old Via C3 500 MHz industrial PC where I test my stuff on.

Honestly, even just an i5 with 16GB ram with YouTube running in the background, an iPhone 11 if you're making an iPhone app and a galaxy S10 if you're making an android app.

Re: A Plea for Lean Software (1995)

#64

Earlier quoted context omitted.

There's a lot of overhead and inefficiencies in how large companies do anything. It's hard to organize thousands of people well. It's the social equivalent of the old 'Command-line Tools can be 235x Faster than your Hadoop Cluster'[1] conclusion. You put a hundred developers on a project and you'll generously get twice the meaningful output of ten developers (but 50 times the LOC; as demanded by conway's law). The up…

People take holidays, get sick and change jobs - having 1-3 ppl team means you'll hit brick wall that will hurt sooner or later, more so if at least one of devs was really good.

This is a real concern if you're looking at it as someone who is managing people... but a 1-3 person team does not need a manager to tell them what to do, and generally is not hired but spontaneously organized.

It's an inherently more unpredictable way of working, but that definitely cuts both ways. There are definitely more risks, but also far greater payoffs in terms of what you can do working in this fashion.

The principle of ensuring predictable velocity across a team comes a cost of limiting maximal produtivity amongst talented individuals.

Re: A Plea for Lean Software (1995)

#65
post #6

I've come to suspect the normal way large companies are organised makes performant software almost impossible. Features are celebrated and make money - whereas performance can be gradually salami-sliced away, with nobody advocating for it. If you can add a feature and it adds just 50ms to a 300ms pageload - it's unlikely anyone is going to block its release on performance grounds. And once the feature is released, th…

Your competition will benefit when you stumble. All software has competition.

Re: A Plea for Lean Software (1995)

#66
post #59

Earlier quoted context omitted.

Since your time is so valuable and you are obviously very upset about this, your company should pay Spotify to write a more efficient app. Or your company should buy you a new 96 core Threadripper 1 TB RAM system so that when you use Spotify/Slack/Postman it doesn't impact your productivity.

If your only response is a personal attack, don't say anything at all.

I was just reflecting your thinking - somehow you feel that Postman/Slack/.... owe something to you. Pay them to do what you want, or stop using them.

You feel entitled to use a $10K machine to compensate for slow IntelliJ for maximum productivity and convenience, yet deny others (Postman/Slack/...) using the most productive and convenient technology for them (Electron). And while continuing to use their convenient products, you say they are bad. Use IRC, use curl instead of Postman.

The Postman programmers say the same thing: our users have $3K+ machines, no point in optimizing code to be fast, instead lets add more features since it's clearly working and our users are not switching. Obviously they love the iteration speed that Electron gives us.

Re: A Plea for Lean Software (1995)

#67
post #55

Related: “A Plea for Lean Software” by Prof. Niklaus Wirth (Non-PDF Version) - https://news.ycombinator.com/item?id=33203181 - Oct 2022 (2 comments) A Plea for Lean Software (1995) [pdf] - https://news.ycombinator.com/item?id=27661559 - June 2021 (137 comments) A plea for lean software by Niklaus Wirth [pdf] - https://news.ycombinator.com/item?id=27617277 - June 2021 (1 comment) A Plea for Lean Software (1995) [pdf]…

Also this one by Bert Hubert:

A 2024 plea for lean software - https://news.ycombinator.com/item?id=39315585 - Feb 2024 (240 comments)

Re: A Plea for Lean Software (1995)

#68
post #20

Earlier quoted context omitted.

Development in any corp today, even middle-sized ones, is a big red tape festival. You have a project divided in sprints that are divided in (often meaningless) tasks, then you have a completely bloated CI/CD system and then things get deployed to three or four environments where people pretend to test everything. Things that might be developed by a journeyman developer in five days take six weeks to be done by a tea…

Wasn't "Agile" development supposed to fix this, by keeping team sizes small and workflows as simple and iterative as possible? AIUI, the fabled "two-pizzas team" size was intended as an upper bound for the most complex projects only, not as the new normal. (The "test everything" culture was also AIUI in the service of quick iteration; the first versions of Agile are from the early 2000s when dynamic languages were s…

The problem is not with the Agile methodology itself. One of its core tenets is valuing "individuals and interactions over processes and tools".

The problem is that companies don't understand what this means, and find it simpler to pay an "expert" who will bastardize this definition, and implement processes and tools that make them appear useful to the company. There's an entire industry built on this model.

Re: A Plea for Lean Software (1995)

#69

He was calling 1995 text editors which used 4 MB of RAM incredibly bloated compared to the lean software of his youth which ran in 32 KB. Now we do the same, but we look at the text editors of 1995 which used 4 MB of RAM as incredibly efficient and well made, paragons of craftsmanship. Things never change, the old generation fights the new one and calls it stupid.

>Things never change, the old generation fights the new one and calls it stupid.

I was with you until here, which I think is the wrong take. That is, this gets it exactly backwards. It's not just that every generation gets upset at the previous generation so let's all shrug and move on, it's that this is really a thing that is unfolding from one generation to the next.

It seems like the reflex of oh well the previous generation said it so let's ignore it comes up a lot, to the point that I have this go to example that I use every time it does. I'm a baseball fan. And one thing you used to hear in the '80s, with a guy like, say, Rob Deer or Steve Balboni, was that they tried too hard to hit home runs and they struck out too much. Then you heard that in the '90s as well. Then you heard that in the 2000s, especially with money ball and guys like Jack Cust. Then it just kept getting even more extreme with guys Carlos Pena and now Joey Gallo.

So one thing you could say is, well, every generation says that there were less strikeouts in third day. But there's actually data on this and..... it's true! Almost every decade, from the 1800s through every decade of the 1900s through now, strikeouts really have been going up year to year. And so that intergenerational commentary, well, it's describing a real thing that really is happening.

The same can be said of other things, like people saying they always used to remember the environment being better. Or people saying attention spans are getting shorter. But, they are.

The instinct here I think is to dismiss these since every generation says it. But I think the conclusion should be opposite, that these are real things unfolding on a multi-generational level. So if you see it happening with software, maybe that's because there's really something to it.

Re: A Plea for Lean Software (1995)

#70
post #10

Earlier quoted context omitted.

That 1995 text editor didn't handle unicode. Didn't edit all the languages of the world. Didn't handle emoji. Didn't do auto-complete. Didn't replace colors in CSS with their actual color and popup an inline editor to edit them. They didn't edit remotely (editing remotely is not the same as tmux + vim). VSCode not only edits the files. When you're in a terminal on the remote machine and type 'code somefile', somefile…

I know that this is becoming a trope, but Smalltalk and Lisp Machines did all those things far before 1995. Similarly, GNU Emacs today is capable of all of the above and has been managing for multiple decades at this point in a more modern take of the world... Remote editing back in the 1980s was such a common thing on the Smalltalk and Lisp Machines that all system code was on another machine, more times than not yo…

> Smalltalk and Lisp machines

Lest we mention Plan 9!

Post reply on HN