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?
When you can have your code in 15 minutes, the design becomes the "hard" part. http://msscodefactory.sourceforge.net.
I do not fail; I succeed at finding out what does not work.
Let them know what you *really* think.
team@codevalley.com
putting the 'B' in LGBTQ+
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.
Anybody remember CASE and the drag & drop promises of graphical programming of the 1990's? The at a high level these were great opportunities to both manage software development staff and supposedly increase productivity.
CASE failed because many assigned to the "design" role didn't have a deep enough understanding of the necessary components to produce a system, so many CASE tasks assigned were woefully under specified, and systems had so many gaps they weren't even functional.
Similarly the GUI drag & drop programming has only been successful in structural applications like designing entity relationship models. Anything past a simple loop and these technologies just don't support the complexity necessary to develop the applications of the time.
It's the Elbonian outsourcing model.
Some drink at the fountain of knowledge. Others just gargle.
This piece sounds a lot like an advertisement from a SaaS salesman. I'm in systems integration, so I hear a lot of these. "Our framework is completely extensible! Open APIs! We'll talk to any of your existing systems! We do all the work for you! Fire all those IT nerds! Just sign here and all your problems will disappear!" Now it sounds like they're moving up the stack and trying to promote snap-together replacements for in house development as well.
There was just a piece yesterday on Slashdot about how you don't need math skills to code...this just seems like a logical extension of that. Someone has to understand how these things work under the hood, what happens when they're introduced into an already overloaded data center network, etc. Yes, most phone apps and CRUD applications can be written easily by someone who knows the bare minimum of how to glue frameworks and libraries together. I see this on a regular basis when I have to make crap applications from "best of breed" consulting firms and enterprisey software companies work in the real world. The trick comes in supporting the mess you build after you release it. I've seen applications that break horribly when various security patches to frameworks occur, as well as chains of dependent stuff stop working when one item in the chain undergoes a tiny change or is configured differently. Is this grand vision of pluggable components from hundreds of vendors taking into account how brittle systems built like this are in real life? Or is the grand vision just repackaging the idea of purchaseable library components being used in software projects when you don't want to write it yourself?
Here's what I'd like to see -- make software engineering an actual branch of engineering with professional licensing. Put new developers through the same fundamentals everyone else in the profession has, to ensure that they're at least starting out at a functional level. Make PEs liable for crappy designs and bad implementations. I guarantee that once someone's reputation is on the line, you'll see fewer "JQuery boot camp" graduates banging out low quality insecure junk code. Make it a quality revolution, not an industrial revolution. If a business could be reasonably assured of a quality software product, with actual penalties if they don't get it, that would be a much better idea than promoting a future of putting 1500 ill-fitting Legos together to build an "app."
It could go the way of hardware engineering. People come up with concepts and designs and then usually go to China or India to actually make the thing. I'm not sure how that will turn out once China and India realise that the West is incapable of doing anything without them.
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
And changing programming from an 18th century style craft industry to an assembly line. Look at how computers were manufactured in the 70s and 80s vs today for an example more recent. You break off all the really hard stuff to a few top guys and the rest is done by folks earning minimum wage who don't really understand what they're doing but know if they do certain steps they get certain results. If labor wasn't so cheap this wouldn't work ( too many specific tasks) but at less than a buck an hour in many countries it becomes possible. Of course, it mean being a programmer creases to be middle class work, but I think that's the point.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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...
So that monstrous document is saying we should use libraries?
Yes, we should. We already do.
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.
Now if only we could have some way to create such crap-idea-generator scripts without having to code.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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.
There's gonna be software, and it'll fit together like KACHUNG!
Then stuff will flow through it all and be like woooosh! Then there'll be a result and one guy will own it all and be stood there with his hair waiving in the wind, and babes will be all like He's so awesome!
Goddammit, you just stole my business plan!!!! How did you get through the 7 firewalls into my Gibson server??
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
Yip, I also remember the OOP hype. Objects would magically "handle themselves" as you snap them together like Legos.
Don't get me wrong, OOP can be a useful tool used in the right place and time, but it's merely one more tool in our design belt, and makes a mess if misused just like any other tool or technique.
I'm seeing similar hype of late in FP and node.js. I'm sure they are useful for certain projects or parts of projects, but they are not even close to a general panacea.
Ironically a lot of the JavaScript-related functional programming (FP) and node.js hype is because JavaScript's OOP model is crappy. One wouldn't need so many FP "tricks" and anonymous functions if JS had decent OOP.
If you try to use a new (or more of an existing) paradigm to plug holes in a poor implementation of another paradigm, it's just passing the buck. It should be considered a work-around and NOT a revolution.
Table-ized A.I.
Um, it's not quite as bad as you describe. Things like bolts are not custom to a single model; go look up the mfgr part numbers for various bolts in your car and compare to other cars by the same mfgr; you'll find they're likely all the same. It's not like they need different kinds of 10mm bolts or flare nuts, unless there's a special application that needs a high-strength version or something. Same thing with engine gaskets: those are certainly particular to an engine, but not a car. The same engine is frequently used on multiple models (though it might be retuned, which is usually a software change, though there could be different manifolds on it too). Stalks and buttons are frequently reused across models by the same mfgr. Go to a Volvo dealership and sit in all the different models; they probably all have the same stalks, or slightly different versions of them (for when they have different options, some might have a rear window wiper and others don't, for instance).
What you don't see much is the same component from different mfgrs, at least for stuff that drivers typically see. But even here there is some commonality, as they get a lot of components from suppliers who sell to multiple mfgrs. So for instance Takata is a big seat belt and airbag maker, so while the overall modules are probably specific to automakers and even models (because an airbag is usually integrated with some piece of interior plastic), the pieces inside may very well be common. A supplier selling A/C compressors could very well use the same model for different carmakers (though the carmakers would designate it with their own part numbers), though it might have a different pulley on it because Ford wants to use a serpentine belt with ribs and Chevy wants to use a V-belt.
Wiring harnesses likely are very custom, but even here there might be some commonality (not sure though): if you have two models that are pretty similar (a sedan and a CUV for instance), they might share the same wiring harnesses in the doors if the mounting points are the same. Maybe. One thing that really is the same though is the connectors: one automaker will reuse as many connectors as possible across the whole line. And those connectors are made by a supplier, so you'll probably see that same connector on different automakers' cars.
The basic truth is that manufacturers save money by reducing their number of unique parts as much as possible, and then buying them in higher quantities, so they try to standardize as much as is feasible to realize savings by economies of scale. But a car is a complex system of parts working together, so there's only so much of this you can do. You wouldn't use the same alternator on a stripped-down econobox as you would a top-of-the-line luxury sedan or SUV.
As I mentioned in my original post, my plane can accept three engines, from two different companies.
That's probably because it was specifically designed that way, and those engines are all very similar to one another. Lycoming and Continental have a bunch of engines that are nearly identical, at least when comparing size, power levels, mounting, etc. But you're not going to grab some random engine and toss it in there.
My car also comes with three engine options. Each of those engines is also used in other cars and trucks, of different marques.
Again, that's because those cars were specifically designed that way. The mfrgs wanted the flexibility of being able to offer different engines to customers. Lots of cars have multiple engine options. But you're not going to take a random Chevy and throw in a random Honda engine, they're just far too different. There are some small companies that specialize in making kits for installing engines into cars which weren't designed for them, but these kits are usually quite pricey because they have a bunch of custom-made parts, and that's even when the new engine is from the same mfgr as the old one. You need custom-designed engine mounts, driveaxles, wiring harness adapter, maybe a different hood, etc. And a lot of times, with kits like that, you can't install all the normal equipment, so you might have to go without A/C because there wasn't any room for it.
In long-term essential software especially, it's good not to be locked in to a single supplier.
Yes, and that's why your plane was designed for multiple engines. But not just any engine, only the 2/3 models it was specifically designed for. You can't just grab some random engine (even if it's a similar size and power rating) and toss it in there (though truthfully, assuming it's a typical Cessna-like front-engine plane, it's probably easier than swapping engines in a car).
As for automakers and their suppliers, automakers have *always* used suppliers. Heck, in the early days the automakers didn't even make their cars' bodies! Have you forgotten about "Body by Fisher"?
That isn't done very much in software.
Sure it is. You get a database from one supplier, you get components for it from another supplier, you get a source-control system from yet another supplier, etc. Haven't you heard of "applications"? Even a lot of commercial software contains components from other companies; you just don't see them because it's opaque to you, just like you probably have no idea which company made the headlight assemblies for your car.
Over the last 30 years, about once a decade, there is an article about how software code can be generated and that software developers aren't needed. In the late 80's my husband worked as a subcontractor on a project for IBM where the software architects had designed the system and written out the design in pseudo code. A lowly developer like him only needed to type in the perfect code they had designed and it would work. My husband kept telling the management team that no, the code wouldn't work, the logic was flawed and it would be buggy. He fixed things on his module and did testing, in spite of direction to implement the code exactly as designed and not test it or integrate it with other modules.
This perfect code also wasn't supposed to require any integration, so they went directly from development to acceptance testing. That worked about as well as you'd expect, they had to stop testing within an hour after starting. My husband's code was one exception, it mostly worked and actually ran when the tested the system. There were a few bugs but it performed better than other modules i the system. However, they had to delay the schedule so they could get everything integrated. He left that job and went to a small company where lowly developers only worked on coding. That system had few bugs and worked pretty well. Sadly, right before he left the company, they were partnering with IBM and starting to buy into the perfect code design idea. I worked on a similar project for the DoD, I was supposed to code the design exactly as written. Even if it didn't work when it was executed, I wasn't allowed to fix the software unless I had gotten a approved bug report that stated it was priority one and the software would not run at all unless I fixed the bug. Amazingly enough, the customer killed the project before delivery.
Saw the same thing in the 90's, Java and X-Windows were going to eliminate detailed coding and allow the use of low cost, low experience developers. I still remember explaining a memory overflow bug to a Java developer and that the string was probably longer than 1024 or 2048. He told me it couldn't happen, sure enough, I counted up the string to where it overflowed, the first 1023 characters were fine, it was the 1024 where it overflowed, sigh. In the 00's, it continued, the continuing trend was to use MS Office with Visual Basic, no need to code those back office applications and waste all that time designing, implementing, integrating, beta testing and gradually rolling out into production. Excel and MS Access with Visual Basic are examples of this type of thinking and I've seen how well that has worked out for database development.
Guess it's time for business types to roll out this idea, consultants to sell it to businesses on how they can cut costs, for software development and then another batch of software consultants will come in and clean up after them from the mess left behind on these systems. Would be nice to be proved wrong, but I haven't seen that much change in the state of the art for the majority of software development. I feel a major breakthrough is required for this to happen that will completely break from previous programming practices and from what I can tell only incremental changes are occurring.
Oh, and you kids get off my lawn, dang, I feel old after writing this. :-)
I used to be an adult but then I grew up.