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

A Plea for Lean Software (1995)

liam-on-linux.dreamwidth.org

Post reply on HN
Print view View original

71–80 of 136 posts

Re: A Plea for Lean Software (1995)

#71

Post by zelphirkalt »

dist-epoch wrote: post #49
maccard wrote: post #45

Earlier quoted context omitted.

Back in 2014 my company switched from Skype to this hot new tool called Slack for messaging. On my £10,000 workstation with dual xeon processors, 64GB memory and a 1TB SSD, you know what was the second most resource intensive app after my c++ compiler, and above my IDE? Slack. We used to close our chat program to compile to save the 1GB memory it was using. > It's a bit theoretical because no editors exist that are s…

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.

For me that wouldn't work, because the impact Slack has is not measured in time loss directly (or at least not only, since Slack is truly a laggy piece of crap), but instead in annoyance and feeling bad about using basically spyware on my system. Basically each interaction adds a bit of pain and questioning, why I am even doing this shit.

Not GP, but they could buy me a 1024 core monster if it exists, it would still not solve the problem of Slack.

Re: A Plea for Lean Software (1995)

#72

Post by Jensson »

mirekrusin wrote: post #40
marginalia_nu wrote: post #12

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.

It is better to sometimes be hurt than always be hurting. Organizations are so afraid of only 1 person understanding something that they create processes so that 0 persons understand it.

Re: A Plea for Lean Software (1995)

#73

Post by scotty79 »

I've been using pc computers for nearly 30 years and they are faster today than the've ever been. Of course not thousands times faster. Just slightly faster. The biggest kick was SSDs.

My computer could be way faster but it's fast enough that I don't care to remove from autostart the software that doesn't need to be there.

I think that's the reason of software not keeping the pace with hardware in terms of speed. It's just fast enough and if you make it faster people just pile up stuff to make it as slow as tolerable for them.

Re: A Plea for Lean Software (1995)

#74

Post by scotty79 »

glenstein wrote: post #69
hugryhoop wrote: post #5

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…

There is real thing happening. But the dissatisfaction from that thing happening is what's the criticism is all about. And those are two separate things. Things changing might be real or not. But the dissatisfaction of older generation is constant for thousands of years.

Re: A Plea for Lean Software (1995)

#75

Post by Kuinox »

zozbot234 wrote: post #44
lp4vn wrote: 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…

Never understood the "two pizza team" since I eat a single pizza alone.

Re: A Plea for Lean Software (1995)

#77

Post by markb139 »

michaelt wrote: 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…

>I've come to suspect the normal way large companies are organised makes performant software almost impossible.

I think this is a bit of an over generalisation. There were (and still are) many large companies producing performant and reliable software. I suspect when things just work (think of the global phone system) people don't realise how much software is involved. When was the last time you picked up a fixed line hand set and there was a software bug preventing you from calling any other handset on the planet - without varying delays or dropped packets?

Re: A Plea for Lean Software (1995)

#78

Post by scotty79 »

simpaticoder wrote: post #57

Very few people ever even attempt to write "lean software". The definition is a little nebulous, but "software without bloat" is a good one. This means that you have few dependencies, and the ones you have themselves have few dependencies, for a starter. But right there you have the first problem, which is that dependencies grow stronger with the number of users, and the number of users grows with applicability, henc…

Shouldn't our tools be able to remove unused parts of the dependencies?

Re: A Plea for Lean Software (1995)

#79

Post by Traubenfuchs »

1vuio0pswjnm7 wrote: post #76

If software getting larger is a sign of "progress", then someone could write a 2TB text editor right now and call it the most advanced editor ever written. Because inevitably, some day, editors with reach 2TB, right?

In the future, with an Apple Vision Max 16, we achieved full and perfect immersion. Text editors now come with 3D environments you can "sit in" while writing text on your virtual, haptic feedback keyboard. One extreme definition 3D environment has the size of 1 TB. As a minigame, the jungle one comes with a realistic tiger that you can tame, like a tamagochi.

If you ignore the tiger, the object containing its affection values will remain null, causing a nullpointer (and crashing the 3D environment) eventually as the text editor tries to check if you fulfilled the requirements for the tiger stripe font you can get if your affection levels with the tiger are high enough.

Re: A Plea for Lean Software (1995)

#80

Post by mjburgess »

Dwedit wrote: post #53
baal80spam wrote: post #8

Electron entered the chat.

I blame Firefox and other web browsers which deny loading JS files if your page was loaded from file://. If you could simply run an HTML file from your hard drive and have a fully functional web application, you wouldn't need Electron.

They would also, presumably, need to provide a whole native OS api for a variety of syscalls (etc.) that wouldnt otherwise be supported.
Post reply on HN