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

101–110 of 136 posts

Re: A Plea for Lean Software (1995)

#101

Post by peteradio »

discreteevent wrote: post #81
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…

> Features are celebrated and make money - whereas performance can be gradually salami-sliced away, with nobody advocating for it. - Optimists tend to be promoted, so the higher up in the organization you are, the more optimistic you tend to be. If one manager says "I can do that in 4 months", and another only promises it in 6 months, the 4 month guy gets the job. When the software is 4 months late, the overall syste…

Get 10 different opinions and then have them actually implement them 10 different ways pick your favorite. Software development is already eye watering inefficient, getting people out of the way of each other at the cost of ten different implementations may just come out ahead.

Re: A Plea for Lean Software (1995)

#102

Post by pjmlp »

xcdzvyn wrote: post #70
amszmidt wrote: post #47

Earlier quoted context omitted.

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!

And Inferno as well.

Re: A Plea for Lean Software (1995)

#103

Post by dist-epoch »

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…

You are focusing on the generational trends, I was focusing on the individual.

Tell a kid learning to program today "you should program in assembly because it's efficient, like I did back in my days".

Kid looks around and sees it would take him 3 days to implement a hello world in assembly, but only 3 seconds to do it in Python. He has a 16 core computer with 64 GB of RAM. Both hello worlds run instantly. So how does that advice make sense? Kid calls you a crazy old man out of touch with the times. Kid goes on running locally a 50 GB LLM to make it do a hello world and feels very excited about the future of programming.

Re: A Plea for Lean Software (1995)

#104

Post by mattgreenrocks »

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

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…

It feels like a jobs program for a LOT of people, ultimately. This is why the ceremony is almost sacrosanct.

Re: A Plea for Lean Software (1995)

#105

Post by dist-epoch »

cxr wrote: post #98
dist-epoch wrote: post #92

Earlier quoted context omitted.

> I've been a paying slack customer for a decade at this point $10/month is not what I meant by "paying them". I worked at a company where clients would routinely pay us $200K to implement a particular niche feature which was not on the roadmap. If they asked for a non-roadmap feature, yes, the ticket would be closed "not-planned".

You seem to be choosing to engage with your own least charitable inferences rather than what reflects your counterpart's actual position. Viz: > the alternative option isn't there > I don't feel entitled. I don't have a choice in my chat app Your responses are predicated on the option being there and the person you're responding to is just not taking it. This despite the fact that his or her responses strongly sugges…

There is always an option. Threaten your employer you'll leave if they make you use Slack, quit programming and become a farmer who touches grass every day.

All this Electron app complaining reads like First-World Problems(TM).

Re: A Plea for Lean Software (1995)

#106

Post by aleph_minus_one »

falling_myshkin wrote: post #91
aleph_minus_one wrote: post #88

Earlier quoted context omitted.

> This assumes you know what you need to build. This is what in my opinion senior programmers or project managers are for. If they are not capable of handling this task decently, these people simply are not (yet) ready for this role.

Young engineer here in charge of a project and feeling quite out of their depth, I agree with this. Currently no mentorship and it will take a couple months for a senior hire. Do you have any advice? What does a senior engineer love/hate to see when they come onto a project started by engineers earlier in their career? How can I be most helpful?

My personal opinion on this topic is a little bit "postmodernist": we neither have yet a "scientific theory" of software engineering, management, and management of software project (despite the fact that there do exist people who claim otherwise). So, there exist a multitude of "schools" of how to handle these topics (with often quite conflicting opinions on what is "good" and "bad").

Having this consideration in the back of your mind:

What might be helpful concerning your questions is to consider that many programming languages suggest a specific style of approaching the programming project, structuring the code, often managing the team, ... . There exist good reasons why one talks of "Java shops", "C# shops", "Python shops", ... because these programming languages often imply very different company cultures. Note that very prevalent programming languages can also have various "subcultures" ...

So what will likely be valued is to have a good understanding of the "desired programming style", "desired problem solving approach", "desired management style", ... that is encouraged by the "programming ecosystem" in which the company is placed, and going by it.

This will likely yield a decent, conservative code base that can more easily be passed over to a more experienced programmer as soon as one becomes available: especially for such a situation, it is in my opinion much more important to "not to make huge (also architectural) mistakes" than to deliver the most fancy/ideal code (but note that if you work at a startup that has an "all or nothing" approach (i.e. if the product won't become great, the startup has failed) or is in fear of running out of money, the priorities might differ quite a lot).

Re: A Plea for Lean Software (1995)

#107

Post by scotty79 »

funcDropShadow wrote: post #99
scotty79 wrote: post #74

Earlier quoted context omitted.

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.

> But the dissatisfaction of older generation is constant for thousands of years. And there is no dissatisfaction of the younger generation? There is no, this is the old way let's do it differently because we are more clever by the young generation?

There is. But it's the other side of this interdenominational coin. Basically both generations in conflict think the other is stupid.

Re: A Plea for Lean Software (1995)

#108

Post by falling_myshkin »

aleph_minus_one wrote: post #106
falling_myshkin wrote: post #91

Earlier quoted context omitted.

Young engineer here in charge of a project and feeling quite out of their depth, I agree with this. Currently no mentorship and it will take a couple months for a senior hire. Do you have any advice? What does a senior engineer love/hate to see when they come onto a project started by engineers earlier in their career? How can I be most helpful?

My personal opinion on this topic is a little bit "postmodernist": we neither have yet a "scientific theory" of software engineering, management, and management of software project (despite the fact that there do exist people who claim otherwise). So, there exist a multitude of "schools" of how to handle these topics (with often quite conflicting opinions on what is "good" and "bad"). Having this consideration in the…

Thank you for the response, it is helpful. I am not used to Python and know that I am not using the language well. So I think it is worth focusing on this.

> not to make huge (also architectural) mistakes

I'm noticing it's the first time I'm even having to make significant architectural decisions, which is difficult because I don't have much experience to draw from, so even the smallest decisions often require a lot of research.

Re: A Plea for Lean Software (1995)

#109

Post by bcaxis »

maccard wrote: post #45
jillesvangurp wrote: post #26

Earlier quoted context omitted.

It's a bit theoretical because no editors exist that are smaller that do all of what vs code does. And a lot of what it does relies heavily on the notion that it's running in a browser. So, just tossing that out won't fly since you kind of need it for at least some of the features. It's only when you subjectively remove all the features that you don't care about that it becomes doable to make smaller editors. And tha…

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…

> Slack/Teams, Postman, Outlook, FF/Chrome, Spotify in the mix, and all of a sudden I'm running 6 full web browsers duplicated with all their resources isolated

If those apps were PWAs instead, it would mean no extra browser copies are running. In my experience this only really accounts for 70-100 MB per app for the browser copy. No reason slack couldn't be a PWA, same with Spotify.

I'm not really sure how slack and others use so much RAM. I've built quite functional, complicated, and non trivial web apps. Mine typically use The biggest performance questions for me are network latency vs local data and figuring out ways to mitigate network latency. The difference between 200 ms navigation and 5 ms navigation is pretty stark. Even if most people don't flinch at 200 ms.

Re: A Plea for Lean Software (1995)

#110

Post by rramadass »

A lot of current day Application Software is of course very much bloated. But on the other hand things at the System Level have gotten so much more complex and complicated that some of the "bloat" is actually "necessary infrastructure". The above was brought home to me long ago when i compared/read Marc Rochkind's Advanced Unix Programming 1st vs. 2nd edition; You really get to see the evolution of the OS and why it has gotten so big. With modern Cloud based distributed systems things have gotten much more worse in both dimensions of "Essential vs. Accidental" complexities.
Post reply on HN