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

81–90 of 136 posts

Re: A Plea for Lean Software (1995)

#81

Post by discreteevent »

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 system complexity makes it easy to assign blame elsewhere, so there's no way to judge mis-management when it's time for promotions.

- There's a disconnect between engineering and marketing. It's not surprising -- marketing wants all the whiz-bang features, it wants to run in 16 megabytes, and it wants it yesterday. Although engineering would like the same things, it is faced with the reality of time limits, fixed costs, and the laws of nature.

- The complexity of our system software has surpassed the ability of average SGI programmers to understand it. And perhaps not just average programmers. Get a room full of 10 of our best software people, and you'll get 10 different opinions of what's causing the lousy performance and bloat. What's wrong is that the software has simply become too complicated for anyone to understand.

- There was never an overall software architect

- We should sell 'bloat credits', the way the government sells pollution credits

- SGI software has a cracked engine block, and we're trying to fix it with a tune-up.

From 1993:

https://www.seriss.com/people/erco/sgi-irix-bloat-document.t...

Re: A Plea for Lean Software (1995)

#82

Post by vendiddy »

I lament how bloated software has become but take hope that there has been counter cultural movement for fast software.

bun for the js runtime

zed for text editors

superhuman for email

Nothing is perfect, but I hope the market starting to value performance will lead product teams to prioritize performance.

Re: A Plea for Lean Software (1995)

#83

Post by maccard »

dist-epoch wrote: post #66
maccard wrote: post #59

Earlier quoted context omitted.

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 p…

> Pay them to do what you want, or stop using them.

I've been a paying slack customer for a decade at this point. I pulled up my email, my support ticket for "slack is using more ram than visual studio" was in February 2015. I don't have the political sway over Salesforce to makthem make these sorts of decisions.

> You feel entitled to use a $10K machine to compensate for slow...

Youre doing it again. I don't feel entitled. I don't have a choice in my chat app, my employer forces it on me. And even if I did, slack is on the whole the least worst option. As for postman. I did the same thing. I was a paying customer, I submitted support tickets, provided traces when asked and ultimately I did decide to change tool.

> while continuing to use their convenient products, you say they are bad.

Am I not allowed to have an opinion just because I have a fast machine? Am I not allowed to want my software to be better?

> The Postman programmers say the same thing:

No they say "performance is a top priority for us, we're sorry you're not happy with it. Please send us your hardware specs" and the ticket gets auto closed after 2 weeks.

> Obviously they love the iteration speed that Electron gives us.

It's not just electron - snappy electron apps exist. Startup time aside. VSCode is pretty damn good. Figma is an excellent example of how good it can be (and if you want to compare what it looks like when a company cares Vs a company doesn't, see figma and Miro).

Re: A Plea for Lean Software (1995)

#84

Post by maccard »

nercury wrote: post #51

I would argue that the bloat comes when the performance impact is not perceivable compared to the development time. The easiest optimization strategy is just to load it all up into the memory. Compare that to other strategy like catching partial file data, and it's obvious why the simpler solution is often chosen. Another example that comes to mind is vector art vs baked art. You can render nice icons as vector art.…

Load what all up into memory? That doesn't solve the N+1 problem, or chained async methods. It causes caching issues (what if something else changes the files you're working with?).

Re: A Plea for Lean Software (1995)

#85

Post by dasil003 »

aleph_minus_one wrote: post #28
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…

> 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). Based on my job experience, this is rather an artifact of how software projects are (badly?) managed. Give each of the developers some small "hotspots" to work on (i.e. critical code fragment that is - hard to implement correctly and fast - which is c…

This assumes you know what you need to build. 90% of the challenge in large scale development is nailing down requirements, especially when the problem space is too big for any individual to fully understand.

Re: A Plea for Lean Software (1995)

#86

Post by epanchin »

Walled gardens like Apple’s App Store could charge app developers based on resource usage.

At the very least they could add a resource (battery especially) usage traffic light.

That said, it would encourage small apps rather than efficient apps.

Re: A Plea for Lean Software (1995)

#87

Post by ZaoLahma »

NL807 wrote: post #54
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…

>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, there's no removing it. Unfortunately this is happening, because compute power is cheap these days. It allows programmers to be lazy, take short cuts and not think about good software architecture. There is no economic incentive to optimise,…

> It allows programmers to be lazy, take short cuts and not think about good software architecture.

I think it has little to do with laziness, and more to do with the taboo of reinventing wheels. If there's a very generic and very broad solution to your very specific and very narrow problem, you're encouraged to use (or invent!) the very generic and very broad solution.

This leads to everything being abstracted to the point where most of your application does absolutely nothing. Just look at the call stack of a modern java web application. The depth of the layers of abstractions that you need to navigate to reach anything that performs any real work is vertigo inducing and nauseating.

It far from ideal and I agree that economics is behind it, but I strongly oppose the wording that it "allows" programmers to be lazy.

Re: A Plea for Lean Software (1995)

#88

Post by aleph_minus_one »

dasil003 wrote: post #85
aleph_minus_one wrote: post #28

Earlier quoted context omitted.

> 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). Based on my job experience, this is rather an artifact of how software projects are (badly?) managed. Give each of the developers some small "hotspots" to work on (i.e. critical code fragment that is - hard to implement correctly and fast - which is c…

This assumes you know what you need to build. 90% of the challenge in large scale development is nailing down requirements, especially when the problem space is too big for any individual to fully understand.

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

Re: A Plea for Lean Software (1995)

#89

Post by nick__m »

Kuinox wrote: post #75
zozbot234 wrote: post #44

Earlier quoted context omitted.

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.

How large are those two pizza ? I can eat a small 8" alone but a slice from a jumbo 18" is enough... Also if someone eats a 18" pizza alone, is he a 10x programmer?

Re: A Plea for Lean Software (1995)

#90

Post by jillesvangurp »

vidarh wrote: post #38
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…

Next to nothing of what VS code does depends on it running in a browser other than to the extent VS Code has made it so. It's not special. If anything it's one of the most clunky editor I've used because it tries to shoehorn everything into a convoluted UI. It's because my time matters to me I avoid VS Code as much as possible. The problem with VS Code is not that it's too slow, or too memory hungry. It could use far…

Markdown and html, image, and other previews, documentation, connectivity, it's a lot more than you think.

If you don't like it, use something else of course. But there are valid reasons for it being browser based and a lot of people choose to use it at this point.

Post reply on HN