3 ms·

The first time you build anything it's artisanal. Look at the process of building the first doll, or the first car etc... of a multi million run of the same obj

The first time you build anything it's artisanal. Look at the process of building the first doll, or the first car etc... of a multi million run of the same object. The difference in software is once you're done with the first one, there's nothing else to do.

fsloth 9y ago
"The difference in software is once you're done with the first one, there's nothing else to do." I'm not sure if I parse what you wrote correctly. Currently we can't have enough software written. And solutions - patterns (but not in the god awful Gang-of-four sense) - are transferable between isomorphic problem spaces. Following the doll metaphor, a police doll, a firefighter doll, a child doll, a werewolf doll, a gorilla doll - * a bicycle!?*. Sometimes you truly come up with something totally new, and adapt.
- dredmorbius 9y ago
  And a large part of the reason we can't get enough software written is that our teams are adversarially pitched against one another. One set of Great Minds is writing advertising, code, another ad-blockers, another HFT and financial derivatives crud that's quite likely to precipitate yet another financial speculation-bubble-crash cycle. And basic needs and wants go unanswered, in large part because those with the needs and wants have no financial means to pay for them. For numerous reasons, the information which should be more available and standardised ... is instead obfuscated and/or sliced-and-diced behind ad-ridden, paginated, metadata- and classification-free CMSes. You can dig in to find various economic, power, political, psychological, sociological, and other reasons for all of this. But the upshot is that the frenetic code-generating that's going on is doing little to move the needle on improving either quality-of-life or overall systemic health. Frequently the opposite. This is a Big Problem.
  - deleted 9y ago
    [deleted]
  - BoiledCabbage 9y ago
    The problem is or tools and languages for expressing thought to a computer are terrible. And we're terrible at developing better ones, and we're terrible at evaluating their fitness, and we're terrible at adopting better ones once they come along. It's a limitation of or brains. The cost of re-learning how to think is too damn high. The solution space of ways to solve programs with computers is highly dimensional. We are climbing a local minima and we're not gonna be sitting anything different part of space any time soon. What's even worse is we can't even iterate quickly because it takes us so long to evaluate large changes, and the costs of making small changes are too high to be worth it. We're still using Algol syntax 50 years later! It isn't better, it isn't well constructed. It arcane, and unnecessary - but the tech costs of moving away from it are to high. Someone could fix improve Algol syntax in a few days max and every Algol derived language (c/c++/java/js/c#/...) would benefit. But nobody in hell is gonna update every algol derived compiler ever written and update all the code ever written to match. It'd be ludacrious! But here, exactly the type of incremental improvement you'd make in a development cycle if it were a library being written now, is impossible to make because of change costs. Think of rapid prototyping and small iterative improvements - this is exactly the opposite. When the engineering overhead to fix a bug is minimal ( "I'll code it in 10, run through automated tests and CI, then deploy") you fix every small bug you see. When the overhead is huge ("10 mins to code. But it'll reset our multiweek manual test pass, and force us to not physically ship until next product cycle") you don't bother and code rots. That's the problem, and that's where we are.
    - dredmorbius 9y ago
      I'm not particularly convinced. Your comment reminds me of someone's essay on programming languages, and of the improved efficiency of adopting same. There was machine language, and then assembler, and then the first set of third-generation languages, and then ... C. And for all that's come along after C, there's been some progress, but in general, relatively little. Each variant has its advantages, and disadvantages. C itself has major problems (it's insecure as hell), but ... works well enough. And so we're caught in a bit of a hairpin-bend effect. I'd have to see a particularly good argument that this is a fundamental limitation of human minds, or of technological sociology (that is: the net effects of programmer skill and education), or something like that.
  - deleted 9y ago
    [deleted]
tboyd47 9y ago
That's only if the company doesn't know how to run a software project. Most of the value extracted from software is in the maintenance phase, not the development phase. When the principal developer on a successful project leaves, it multiplies the time and effort involved in maintaining the code, and then what happens? No one does the maintenance, and two years later the new team decides to rewrite it. Sunk cost fallacy is not a fallacy when you're talking about years of fully tested work lost, and you can't even find people who know what the requirements were.
juliendorra 9y ago
It stays artisanal because you can modify and craft your product even after it is shipped and used, now in real time with web apps. It’s a quite unique mix of constant craft and creative changes with world scale instant distribution of these artisanal changes. There is right now a programmer-artisan crafting some Google/Facebook/Startup code and this code will directly change the product. No intermediate. It’s a lot more like radio and talk tv –where talents have to recreate each day their entire show, and creating the show is producing it– than the toy industry, where creation and production are entirely separate processes.
seanmcdirmid 9y ago
As a researcher, this is kind of what scares me about becoming a professional SE. In research, every time I start a new project, there are lots of unknowns and challenges. Hopefully the real world isn't so dull!
- TeMPOraL 9y ago
  It kind of is. A typical software job is about doing pretty much the same thing you do in every other software job; the primary variable is the client and their idiosyncrasies. (Lucky are those who get a job doing something more interesting than CRUD webapps or mobile apps.)
contingencies 9y ago
Insightful comment. Added to https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup ;)

fsloth 9y ago

"The difference in software is once you're done with the first one, there's nothing else to do." I'm not sure if I parse what you wrote correctly. Currently we can't have enough software written. And solutions - patterns (but not in the god awful Gang-of-four sense) - are transferable between isomorphic problem spaces. Following the doll metaphor, a police doll, a firefighter doll, a child doll, a werewolf doll, a gorilla doll - * a bicycle!?*. Sometimes you truly come up with something totally new, and adapt.

dredmorbius 9y ago
And a large part of the reason we can't get enough software written is that our teams are adversarially pitched against one another. One set of Great Minds is writing advertising, code, another ad-blockers, another HFT and financial derivatives crud that's quite likely to precipitate yet another financial speculation-bubble-crash cycle. And basic needs and wants go unanswered, in large part because those with the needs and wants have no financial means to pay for them. For numerous reasons, the information which should be more available and standardised ... is instead obfuscated and/or sliced-and-diced behind ad-ridden, paginated, metadata- and classification-free CMSes. You can dig in to find various economic, power, political, psychological, sociological, and other reasons for all of this. But the upshot is that the frenetic code-generating that's going on is doing little to move the needle on improving either quality-of-life or overall systemic health. Frequently the opposite. This is a Big Problem.
- deleted 9y ago
  [deleted]
- BoiledCabbage 9y ago
  The problem is or tools and languages for expressing thought to a computer are terrible. And we're terrible at developing better ones, and we're terrible at evaluating their fitness, and we're terrible at adopting better ones once they come along. It's a limitation of or brains. The cost of re-learning how to think is too damn high. The solution space of ways to solve programs with computers is highly dimensional. We are climbing a local minima and we're not gonna be sitting anything different part of space any time soon. What's even worse is we can't even iterate quickly because it takes us so long to evaluate large changes, and the costs of making small changes are too high to be worth it. We're still using Algol syntax 50 years later! It isn't better, it isn't well constructed. It arcane, and unnecessary - but the tech costs of moving away from it are to high. Someone could fix improve Algol syntax in a few days max and every Algol derived language (c/c++/java/js/c#/...) would benefit. But nobody in hell is gonna update every algol derived compiler ever written and update all the code ever written to match. It'd be ludacrious! But here, exactly the type of incremental improvement you'd make in a development cycle if it were a library being written now, is impossible to make because of change costs. Think of rapid prototyping and small iterative improvements - this is exactly the opposite. When the engineering overhead to fix a bug is minimal ( "I'll code it in 10, run through automated tests and CI, then deploy") you fix every small bug you see. When the overhead is huge ("10 mins to code. But it'll reset our multiweek manual test pass, and force us to not physically ship until next product cycle") you don't bother and code rots. That's the problem, and that's where we are.
  - dredmorbius 9y ago
    I'm not particularly convinced. Your comment reminds me of someone's essay on programming languages, and of the improved efficiency of adopting same. There was machine language, and then assembler, and then the first set of third-generation languages, and then ... C. And for all that's come along after C, there's been some progress, but in general, relatively little. Each variant has its advantages, and disadvantages. C itself has major problems (it's insecure as hell), but ... works well enough. And so we're caught in a bit of a hairpin-bend effect. I'd have to see a particularly good argument that this is a fundamental limitation of human minds, or of technological sociology (that is: the net effects of programmer skill and education), or something like that.
- deleted 9y ago
  [deleted]

tboyd47 9y ago

That's only if the company doesn't know how to run a software project. Most of the value extracted from software is in the maintenance phase, not the development phase. When the principal developer on a successful project leaves, it multiplies the time and effort involved in maintaining the code, and then what happens? No one does the maintenance, and two years later the new team decides to rewrite it. Sunk cost fallacy is not a fallacy when you're talking about years of fully tested work lost, and you can't even find people who know what the requirements were.

juliendorra 9y ago

It stays artisanal because you can modify and craft your product even after it is shipped and used, now in real time with web apps. It’s a quite unique mix of constant craft and creative changes with world scale instant distribution of these artisanal changes. There is right now a programmer-artisan crafting some Google/Facebook/Startup code and this code will directly change the product. No intermediate. It’s a lot more like radio and talk tv –where talents have to recreate each day their entire show, and creating the show is producing it– than the toy industry, where creation and production are entirely separate processes.

seanmcdirmid 9y ago

As a researcher, this is kind of what scares me about becoming a professional SE. In research, every time I start a new project, there are lots of unknowns and challenges. Hopefully the real world isn't so dull!

TeMPOraL 9y ago
It kind of is. A typical software job is about doing pretty much the same thing you do in every other software job; the primary variable is the client and their idiosyncrasies. (Lucky are those who get a job doing something more interesting than CRUD webapps or mobile apps.)

contingencies 9y ago

Insightful comment. Added to https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup ;)