4 ms·
I think that's the wrong perspective. Software is a tool. What you do with it is an outcome. A bulldozer is a tool. The house is the outcome. So, we already
by numlocked 10y ago
I think that's the wrong perspective.
Software is a tool. What you do with it is an outcome.
A bulldozer is a tool. The house is the outcome.
So, we already invented a bulldozer (some piece of software) and it's trivial to duplicate it and reuse it all over the world. But when we need a new type of machine it's harder because, well, it's new.
In the software engineering world the goals is generally not to facsimile something like e.g. a house. It's to create a legitimately new tool. And since there are no real capital investments required (unlike building new tools in the physical world), and folks often value their free time at a weirdly low marginal rate, you end up with tool proliferation in a way not seen in the physical world, which makes it easy to think that we're building houses when in fact we're inventing the bulldozer.
- jacquesm 10y ago> It's to create a legitimately new tool. More likely: to create a minor variation on an existing tool. There have been relatively few instances of legitimate new tool creation but many 100's (and probably 1000's) of instances of re-creating slight variations on the same tools. For instance: build tools, programming languages, libraries (95% duplicate functionality with some other library, and of course an inconsistent interface) and so on. > And since there are no real capital investments required (unlike building new tools in the physical world) Software requires enormous amounts of capital, in part due to all this re-invention. We even have a name for it: NIH, and we have a term for what happens to a software project that is a few years old (technical debt). Our tools and our processes are ill equipped to deal with the challenge and what is supposed to be building houses more often than not ends up with people re-inventing the bulldozer. Now there are times when that is the right thing to do, but most of the times it isn't.
- Retric 10y agoSlashdot, Reddit, and HN are different tools. On the surface they seem similar, but so does a Philips head screwdriver and a Frearson, yet they really are different tools.
- jacquesm 10y ago> Slashdot, Reddit, and HN are different tools. They're different end products, but they are not different tools. Conceivably they could have been built with the same toolchain, but instead they were all built with totally different tools (Perl, Lisp/Python, Arc) respectively.
- SomeStupidPoint 10y agoBut how is this not complaining that some buildings are concrete and some are wood and some are gasp a hybrid? I mean, if those engineers were better at what they do, they'd use just one material, right? And they have hundred or thousands of kinds of screws! Why do they keep reinventing them? They're just meant to hold things together -- one job!
- jacquesm 10y agoBecause in engineering there really are such requirements. In software we rarely have a good reason to start yet another 'from scratch' new hip thing that is so much better than that old thing (where 'old' is likely less than 5 years old). Technology cycles are now so short that libraries and frameworks don't even bother pretending to have a life-span longer than the stuff that will be built upon them. And those engineers with their 'hundreds or even thousands kinds of screws', they very much favor standardization, lots of work goes into attempting to create families of compatible tools and consumables and typically a change like that will result in decades of stability in the fastener industry, it is quite rare for something revolutionary to happen, most of the changes are incremental and logical. If you attempted to come up with a completely new thread or screw head there would have to be a reason better than 'I don't like the other screws' if you expect to gain any acceptance of you shiny new tech. I'm trying to imagine a world where every other week the whole of engineering would be up-ended, everybody would have to totally re-train and we'd discard everything we learned process wise over the life-time of the industry. That would be the rough equivalent of what we do in software. Ok, maybe not two weeks, but we might actually get there, life-cycles are getting ever shorter.