Slashdot Mirror
An Idea For Software's Industrial Revolution
An anonymous reader writes: Tech company Code Valley makes the bold claim that a software industrial revolution may be imminent (PDF). They propose shifting developers from the coding domain (current software development practice) to a "design-domain," where the emphasis is no longer on writing code, but on decentralized design – code becomes simply a by-product of this collaboration. In this design-domain, software programs are designed (and built) by a peer-to-peer supply chain of software vendors, each owned and managed by a software engineer. They envisage a global supply-chain of these software experts capable of reliably delivering immensely complex software.
Who is actually making the software, and why does it make since to divorce design from the people executing it? This is the dumbest idea since Agile was invented.
my bullshit meter just exploded
This kind of nonsense keeps popping up every few years. It was about time some "visionary" tried selling this crap again.
I'm sure it's different this time and there's this new thing that will solve all the problems they had the last 15 times someone has tried to push this idea...
No No No! A thousand times NO!
Software is a service sector, not manufacturing. Trying to treat it as an industrial process is incorrect and leads to poor management and dysfunction. A development team is more like builders designing constructing the factory, or tools and dies work to be used in the factory, than factory work. But even that is a dangerous analogy. It is soft process rather than a hard process in that it is mostly intangible.
Do not think of it as industrial in any sense and you will have a better grasp on things.
putting the 'B' in LGBTQ+
First, it seems like the fundamental misunderstanding these people are making is that the code you write embodies your "specialization". Wrong. Your value is not in the code you wrote yesterday, it's in the problem solving ability in that particular domain that resides between your ears. Your value is the code you can write tomorrow.
No convoluted construct is required if you want to retain ownership of the code and just license it to whoever wants it written. Put it in the contract. If the buyer won't take it now, they won't take it with some clunky layer of nonsense on top of it, either.
Seriously, the problem with no industry and no organization anywhere ever is that there aren't enough layers of people making "contributions" that someday trickle down to people who actually do work. It's far more often the converse. You have people with an idea filtered through layers to people who will be tasked with implementing it, who clearly and succinctly explain what's wrong with the idea and how to fix it, then that useful content is filtered back out before it gets to the people who want the thing to begin with. And so yet another project cruises on towards its iceberg.
But sure, add more layers. What could possibly go wrong?
The design was always the hard part. Which doesn't make the coding easy. Just easier (unless you screwed up the design, then the code can be impossible).
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
The assumption underlying this is that we can safely hide everything under a million layers of abstraction until all you're doing is giving vague hints to the computer about what you want and it spits out perfectly polished software applications. And BAM, suddenly you don't need those expensive engineers anymore because nothing is complex anymore. Everything is simple and easy.
The problem is that if it's easy to do, your competitors are probably doing it already. As the capabilities of the platform expand, the appetites of the customer for new features expand. When arithmetic becomes easy, we demand statistical analysis. When this becomes easy, we demand reports. When reports become easy, we demand pie charts and graphs. When this becomes easy, we demand it be displayed on a screen instead of a printout. When this becomes easy, we want a dashboard that shows us everything in real time. When this becomes easy, we want the computer to isolate actionable information in real time. And then handle it without waiting for the user. We're constantly pushing the boundaries of what is possible in software. There's no way to automate this process because there's always more information to gather and always quicker ways to make effective use of it. It's like assembling legos using pieces that don't exist yet.
The industrial revolution came about because of the development of rigid specifications that covered what parts had to do. If a part met specs, it would work; this made them interchangeable and meant you could get them from anyone who so qualified.
In order for software to do the same, they require the same rigid specifications that can be tested for. Wake me when we have those, okay?
Just focusing on two parts: You think you can just thoughtlessly bolt any engine to any propeller?
Not unless you want to die. The FAA certifies them as sets. The certification process is long and involved.
And idiots still take saws-alls to propeller tips. Thinking they need 20 cm more clearance and never thinking a prop has a resonance frequency.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
It's the other way around: the car you're referring to is RWD coupe with a flat-four engine. If it had been Toyota engine / Subaru body, it would have been an AWD coupe with an inline-four engine instead.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
And the 1980's, and the 1990's, and the 2000's... CASE, 4GL, XP, ITIL, SEI, yadda yadda...
If it works for aviation, it certainly might work for business software.
It does. Plenty of companies use Hadoop as a component, for example.
It doesn't work the way these guys are recommending, but anyway.........
"First they came for the slanderers and i said nothing."
"I'm just an idea guy. I have some really great ideas. I just need someone else to do the easy parts like writing all the code."
Here's that "same car" thing:
https://en.wikipedia.org/wiki/...
"Toyota, led by project leader Tetsuya Tada,[5] offered Subaru involvement in their sport coupé project, co-developing a new boxer engine known as the D-4S..."
The key here is "co developed". It wasn't either team's ANYTHING, you'll note as you go through that article- the initial engine was dropped for a co-developed engine, each team made components of the car at different parts...
Essentially, it wasn't two teams communicating to a common spec with clearly delineated design borders, but two teams working together to make a car, crossing lines on each subcomponent constantly.
It is the OPPOSITE of an example about a top level down design manager jack-off fantasy, as discussed in the OP.
Forget about these wild dreamers replacing software engineers, I bet we could replace said wild dreamers with a small perl script that cranks out terrible ideas...
What's more, you make it sound like complex products are assembled from off-the-shelf parts. That simply isn't true for most things. With aircraft even, there's only certain engines which will fit in a certain chassis. With cars, it's much worse; car chasses are designed specifically for certain engines (usually made by the same company). All the components in the engine bay have to be fitted around the engine itself; you can't just take some other engine and slap it in there without serious modifications and reliability concerns. All the other parts are usually made specifically for that car too, esp. anything in the interior. They don't just grab some dashboard off the shelf, they design it specifically for that model, to fit in aesthetically and functionally, the seats are designed for that model, etc. There'll be a degree of commonality across one manufacturer's line to save costs (they might use some of the same switchgear between two adjacent models, they might even use the same engine, like in my Mazda3 where the optional 2.5L engine is the exact same engine used in the higher-end Mazda6, and also in the CX-5 SUV (though probably with some tuning changes, so it's likely not exactly the same)), but you're not going to swap a power window switch assembly from a Ford to a Chevy without making a lot of modifications.
I will show my age. I remember when COBOL, with it's English-like syntax, was supposed to make programming so simple that even your secretary could do it. No go -- writing significant software is managing complexity. No amount of syntactical sugar can hide this.
It's deja vu all over again