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.
The code will just write itself!
SJW's don't eliminate discrimination. They just expropriate it for themselves.
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'
Let them know what you *really* think.
team@codevalley.com
putting the 'B' in LGBTQ+
Toyota and Subaru sell the same car. Toyota made the engine and Subaru made the body. Or is it the other way around, I don't recall. It seems to work fine, though. And Subaru engines are used by many companies, in airplanes, boats, lots of places.
In some markets, Subaru engines compete with Rotax. Each company has a line of off-the-shelf engines you can order. Some plane designs can any of three different engines - two choices from Rotax, and one from Subaru.
Those same planes use instruments made by other companies, etc. A dozen different manufacturers might make stock components that can be used in different aircraft. Airplanes need to be 100% reliable, of course, so you don't often see DUMB design processes in aviation. If it works for aviation, it certainly might work for business software.
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?
If it works for aviation, it certainly might work for business software.
And how is car production different from today software solutions? Microsoft or myriad of open source developers create an OS, Oracle or someone provides a database, someone else an integration toolkit, somebody else designs a schema and a frontend and finally a hosting/SaaS vendor puts it all together and configures the whole package.
And the 1980's, and the 1990's, and the 2000's... CASE, 4GL, XP, ITIL, SEI, yadda yadda...
"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."
This idea is an old one, and has been tried. It is known as the "software factory" and was a central part of Japan's Fifth Generation Computer (FGS) initiative from 1982 to 1992, 30 years ago. The FGSI probably holds the record for the most spectacular computer project failure in the history of computer science, with a total of $700 million spent in 2015 dollars.
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
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've been a software engineer in the civilian and military aerospace world for over 2 decades. I've seen the kinds of software that engineers write in all its hideousness. The last thing this world needs is to let EEs continue to write software. The reason being is that your premise is entirely false. Engineering software is nowhere near "easy enough".
Sure, writing a simple app for a phone is "easy enough", but there's a lot of complicated stuff going on inside avionics systems these days and it's getting more complex every year. You need good software people to write good software in that environment. Let the EEs and CEs design the hardware and leave the software to the people who have the training and skill set more suited to designing the software.
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