Hacker News Reader

Comment by a4isms | Hacker News Reader

Many years ago—2002!—Joel Spolsky wrote this:

https://www.joelonsoftware.com/2002/05/06/five-worlds/

His thesis was that before arguing about software development tools, practices, anything really, it's vital to establish what kind of development you're doing, because each "world" has its own requirements that in turn motivate different practices and tools.

The worlds he quoted were Shrink-wrap; Internal; Embedded; Games; and Throwaway. Shrink-wrap is no longer a thing for most developers, and we can probably name some others today that didn't exist then. But the basic advice he gave then matches what you're saying today:

We need to anchor arguments about tooling in a statement about the type of development we're trying to address, and we need to appreciate that the needs of each world are different.

View on HN

This is also why it's often frustrating to try to understand people's opinions regarding programming and code. There's almost always too little context, even without handwavy or subjective stuff like "it's too complex" or general bandwagoning.

Actually, I feel like many times the conversations about code are pretty shallow anyway with not much info. Maybe it's just difficult without properly established context but OTOH that can quickly get complicated and require a lot more effort.

100% this. The biggest problem I see is understanding the context of what you are building. Even inside a SaaS company. Are you building a feature that is a core part of the service or just a test shot to see if its possible to sell,or maybe you already sold something to a customer that is not your target customer. Yhey still need it and should get it. But maybe its more important to be quick and dirty. if its a core part, Then you need to make sure the architecture is good and maybe even add more test then normal. Context matter so much

That was one of the most interesting reads I've read in a while, thanks.

So much great and timeless stuff was written in the 2000's, it's great and should be part of everyone's read list. Another one that's still pretty timeless is https://randsinrepose.com/

I think a really good example of this is that lots of times even when making a web app, different people make the web app from the people who made the marketing site for selling the web app.

Thanks for the JoS link, a thought-provoking read as always! (And it doesn't feel like a 23-year-old blog post - love your work Joel).

I agree with Spolsky in theory. But in practice, I've been on one project in the last few decades which I actually think benefited from integrating a web framework. The majority of projects I've worked on absolutely did not need JavaScript, and the rest would have been served by an approach similar to what's described in the OP--a few minimal vanilla JS files to create a few web components.

And yet large teams of very smart people reach for NPM as just part of their initial setup process. It's so ubiquitous that I essentially had to learn to not write this way on my own, by asking myself "can I do this without JS"? Almost every time I asked that question, the answer was "yes", and the non-JS way was much easier. But for a long time I wondered if I was wrong--maybe the framework JS way is easier in some way I don't understand--because everyone around me was doing it the framework JS way. It's taken me years of experimentation to build up a preponderance of evidence to persuade myself that in fact, the framework JS way is just worse, most of the time.

Everybody wants to be Facebook or Google, but the fact is you probably just aren't. You probably don't have their problems and you probably don't need to use their tools.

Shrink-wrap is still very much a thing, even if distribution is entirely digital in most cases. It's dominated by internal line-of-business apps, sure, but that was true back then also.

True!

Of course, Shrink-wrap 2020-2025 is not exactly the same as Shrink-wrap 1995-2000. You mentioned digital distribution. Speaking from my lived experience... We shipped software on golden masters that were used to manufacture DVDs at scale.

At that time, the entire software industry worked on long release cycles because of the friction of shipping software on manufactured media. And in those days, people read physical dead tree computer magazines, which had long lead times for articles. This affected software development, because months before we were scheduled to "ship," we were sharing screen shots with journalists, doing interviews, and placing stories in magazines timed to drop when we released.

I remember a death march to get a product ready so that we'd have DVDs to give away at JavaOne in the Moscone Center, where our CTO was scheduled to give a talk. The way software was distributed in those days all strongly influenced the way companies attempted to manage software development.

Reply on news.ycombinator.com