An Idea For Software's Industrial Revolution 289
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.
More and more abstraction (Score:5, Insightful)
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.
Re:More and more abstraction (Score:5, Funny)
Magical Elves!
It's a whole new paradigm! A new Economy! There's no downside! Etc. etc.
Re: (Score:2)
Magical Elves!
From the magical land of "Hache Won Bea"
Re: (Score:2)
Re: (Score:3)
So,
Step 1) Code essentially nothing but libraries.
Step 2) ?????
Step 3) Profit!
Re: (Score:3)
Other way around:
1) Use essentially nothing but libraries someone else wrote
2) Slap a cutesy GUI on it
3) Profit!
Notice there's no ??? step. This is the current business model, and it's currently raking in the cash.
Re: (Score:3)
Re:More and more abstraction (Score:5, Insightful)
Decentralized design?
That's another way of saying 'incoherent design'!
Imagine 1000 incompatible mini 'rational rose' like abominations attempting to work together.
Someone is pumping a stock.
Toyota engine, Subaru body. Subaru in airplanes (Score:4, Interesting)
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.
non sequitur for today is: (Score:3, Funny)
If it works for aviation, it certainly might work for business software.
Re:Toyota engine, Subaru body. Subaru in airplanes (Score:5, Insightful)
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.
Re:Toyota engine, Subaru body. Subaru in airplanes (Score:4, Insightful)
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.
Re:Toyota engine, Subaru body. Subaru in airplanes (Score:4, Insightful)
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.........
Re: (Score:2)
If it works for aviation, it certainly might work for business software.
It didn't work for the 787, did it? [forbes.com]
Re:Toyota engine, Subaru body. Subaru in airplanes (Score:4, Insightful)
Here's that "same car" thing:
https://en.wikipedia.org/wiki/... [wikipedia.org]
"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.
Re: (Score:3)
Email these guys if you disagrree with their POV team@codevalley.com
Re:More and more abstraction (Score:4, Funny)
Who is actually making the software
The coding is not done by programmers, but by peers. It says so right in the summary. Duh.
Re:More and more abstraction (Score:5, Funny)
Better give these peers some work to do, right now, resetting connections is the only thing they seem to do.
Re: (Score:2, Insightful)
Agile works great when you apply it to an organization that refuses to do a proper requirements gathering process.
An code generation based off design type system could work if you could create software that doesn't have to contend with insane contradicting requirements based off of flawed business rules that can't change. Otherwise you will always need to tweak around the pure design aspects.
Re: (Score:3)
The word 'proper' is a trigger word for me . So lets talk about requirements gathering; what is 'proper' requirements gathering? How much detail do you need to get for it to be good enough?
Requirements are like measuring the perimeter of a country; the shorter your ruler the longer it is, the more curls and crannies you find. And so it is with requirements; the more detail you get into the more you find. But there is a point at which the requirements become the application. There is a point where the proces
It's comoditization (Score:3)
Isn't it obvious? (Score:2)
Oompa Loompa, mofo!
Re: (Score:3)
I agree. Something I read 10 years ago really resonated with me, and it refutes this whole idea. From The New Methodology [martinfowler.com] (2005):
Separation of Design and Construction
"The usual inspiration for methodologies is engineering disciplines such as civil or mechanical engineering. . . . Many design decisions, such as how to deal with the load on a bridge, are made as the drawings are produced. The drawings are then handed over to a different group, often a different company, to be built. . . . This allows the cons
Re: configure; MAKE; make install (Score:4, Interesting)
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.
Re: (Score:2)
Isn't that how it works already? Most programming today doesn't involve a lot of algorithm design - all the 'essentials' are done and ready in libraries.
Re: (Score:2)
That has not been my experience at all. I think it depends on what you are doing.
Re: (Score:2)
How is that any different from current software? The people who make your OS are not the same people who make the database, the web server, the office software etc. In the open-source world, these are all entirely separate projects and teams, and even in the commercial world they're either separate companies (Oracle DB on Windows, for instance) or are separate teams (MS Office on Windows). The Microsoft stuff is really a special case anyway; for the most part, you usually get software from different orga
Re: (Score:3)
So that monstrous document is saying we should use libraries?
Yes, we should. We already do.
Re:configure; MAKE; make install (Score:4, Insightful)
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.
Re: (Score:3)
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
Re: (Score:3)
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 othe
Re: (Score:2)
Whenever I program, I use a programming language made by one company with libraries and frameworks from other companies to run on an OS build by yet another company. How is their proposal different?
Re: (Score:3)
As Albert Einstein used to say :" two things are infinite in this world. Stupidity is one".
As Albert Einstein used to say about misattribution: "I didn't say that."
If we just use some buzzwords (Score:5, Funny)
The code will just write itself!
Re: (Score:2)
Good sig.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
"They envisage a global supply-chain of these software experts" - In other words they envision finally turning software into something that involves as few first world salaries as possible. It gets designed and then created by globalized software sweatshops with the aid of sophisticated software. The stock prices then rise temporarily as profits increase and then two years later the entire tech economy implodes. The state of the software industry and the tech economy are thus inexorably turned to shit.
Re: (Score:2)
Re: (Score:3)
They idea is that you you a human like language to describe how the program works and then a program converts that into the actual code.
I think we should call it a compiler.
Re: (Score:2)
human like language to describe how the program works
PHB.
program converts that into the actual code.
Code monkey.
Re: (Score:3)
The code will just write itself!
Yes, using the latest language: iMaginary TM
... And your application is ready instantly, and It Just Works.TM
iMaginary : iMagine the possibilities of magical code.
Featuring the patented iMaginary Natural Language Authoring (TM) which allows you to just tell iMaginary what application you want, followed by the command "Make It So"
Include whatever features are on your wishlist, with "Unlimited Adjective Parameters TM" to enhance the final product, such as "Run Really Fast" for code that just ex
Re:If we just use some buzzwords (Score:5, Funny)
I hear that if you say "peer-to-peer design-domain decentralized design" into a mirror three times, an actual coder will appear and write all your software.
No, the 'actual coder' will come up behind you with a baseball bat and rearrange your cranium.
Re: (Score:2)
And WTF? Software isn't 'industrialized'? The A380, the 787, the LHC, the Internet - these are 'artisanal' products?
Dilbert called this (Score:3)
It's the Elbonian outsourcing model.
hmm... (Score:5, Insightful)
my bullshit meter just exploded
Re: (Score:3)
That + concatenation. If we only use concatenation, and don't let the customers dictate requirements to us (seriously), then all our problems are solved. I honestly have no idea how this company got funding, but if they make a lot of noise, it will be fun to watch them crash and burn.
Re: (Score:2)
I honestly have no idea how this company got funding, but if they make a lot of noise, it will be fun to watch them crash and burn.
I take that back. If you're the type of company that contracts from Accenture or Oracle or HP, then you're likely to do better with the system these guys are suggesting.
Re: (Score:2)
Holy shit that's even worse.Yeah it just looked at it and it's basically...the complete opposite of open source. Not even "closed source" but like...completely closed and obfuscated platform where you may not know what the software is doing. It's difficult to describe how monumentally stupid this is. I find myself...stupefied.
Re: (Score:2)
Heh. I'm no expert, but that's pretty much the impression I got.
It's almost like they expect us to have faith that the software works as expected.
What's that smell? Oh, sole-source contracts with options for technical support. Lots and lots of technical support.
Ka-ching!
Re: (Score:2)
So it's a system that assumes everybody is nice and honest and nobody will ever try to cheat.
Re: (Score:2)
Funny, it was my Bogo-meter that pegged. The bogon flux emanating from the article was simply off the charts.
Re:hmm... (Score:5, Funny)
my bullshit meter just exploded
Great. More industrial hardware issues. What code was it running, and have you considered decentralizing the peer-to-peer supply chain of software vendors to build a distributed fix?
Yet Another Software Engineering Revolution? (Score:2)
.
Or more likely, yet another company trying to sell its product that will make the need for software engineers obsolete.
Self-writing code!!!
Re: (Score:2)
yet another company trying to sell its product
Except they don't actually have any products (unless you consider babble a product). The only thing on their website is a link to the the same PDF listed in the summary.
Re: (Score:2)
Re:Yet Another Software Engineering Revolution? (Score:5, Insightful)
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...
Re: (Score:3)
Now if only we could have some way to create such crap-idea-generator scripts without having to code.
It's about time (Score:5, Insightful)
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...
Re:Actually (Score:4, Interesting)
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.
*Industrial* revolution? (Score:5, Insightful)
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.
Dear god, what did I just read?! (Score:5, Insightful)
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?
Re: (Score:2)
"You know what would make our software better? If no one here is allowed to know how it works!"
Yes (Score:3)
When you can have your code in 15 minutes, the design becomes the "hard" part. http://msscodefactory.sourceforge.net [sourceforge.net].
Re:Yes (Score:4, Insightful)
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).
Re: (Score:2)
Re: (Score:2)
No more of this bullshit "we build it, but if it crashes, burns your operations etc... it's none of my problem" mantra.
What's wrong with that? No one's willing to actually pay for code that's developed to, for instance, avionics standards, nor are they willing to wait that long. Why should software developers accept any legal liability for it if they're not being compensated appropriately? If the code they buy sucks, maybe they should find a better vendor. You get what you pay for, and caveat emptor.
Email them (Score:4, Funny)
Let them know what you *really* think.
team@codevalley.com
We've been here before (Score:2, Insightful)
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 Slashdot Turing Test (Score:2)
Was this article written by a person or a computer?
So how is this different from the promises of 1994 (Score:3)
Anybody remember CASE [wikipedia.org] 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.
Re: (Score:2)
You left out the 4GLs from the 80s.
Re: (Score:2)
For anything really complicated they skip the Labview (that's what the LEGO GUI really is) and go straight to fast and powerful C.
Interpretive Dance (Score:2)
In the future all programmers will be super fit and experts at dance dance revolution
http://www.wired.com/2015/07/b... [wired.com]
Maybe an Engineering Revolution? (Score:3)
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."
Oooh. A new acronym (Score:2)
CRUD - Create, Read, Update, Delete.
I like it! Thanks!
Re: (Score:2)
Not everyone is a web monkey, err excuse me, "ninja." There's still a few of us out there that have to put together something more than ad containers or online catalogs. It is frustrating to me that the conversation always uses them as the representatives for the profession. The detritus of the software development profession tend to settle here. Low barriers to entry I suppose... Either way it skews perceptions and underserves the rest of us.
I partially agree with your assertion of raising the barrier
in a way its probably right (Score:3)
Remember "The Last One"? (Score:2)
Re: (Score:2)
Needed: Cast-iron QA (Score:5, Insightful)
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?
Re: (Score:3)
BINGO! (Score:2)
Is this just a really buzzwordy-I-win-bullshit-bingo way of saying "lets outsource our jobs to China/India and surf youtube all day"?
Because all Apple does is call up Foxcomm every year and tell them "yea, we need a new phone this year, make it a bit bigger and round out the edges, you kno wat I mean", right?
Sure, all that's required is perfect organization. (Score:2)
And a design that makes sense without real world testing from the get go. Good luck with that.
This idea sounds like it was formed by a newly minted MBA with no experience in real world sofware development. It's looks like it's designed to churn out cheap untested and untestable crap that might just be good enough to sell. Once. Which is workable (financially) from the the MBA scum's point of view.
Extreme Managerbabble (Score:2)
What's old is new, all over again (Score:2)
The 1970's are calling (Score:5, Insightful)
And the 1980's, and the 1990's, and the 2000's... CASE, 4GL, XP, ITIL, SEI, yadda yadda...
This is the wrong direction (Score:2)
Currently, the limiting factor in software development is managing complexity
Simple programs become complex as features are added and design decisions evolve
The current direction of layers and layers of frameworks on top of managed runtimes is wrong. It simply adds more incomprehensible complexity
We need modeling and visualization tools to help us manage and control the complexity
Almost everything the author said in the article is the wrong direction. We don't need non-interchangeable parts, designed to fac
They're already patenting the idea (Score:2)
Patents by Inventor Noel William Lovisa
SERVICE IMPLEMENTATION
Application number: 20150032573
Abstract: The present invention provides a method of allowing a user to obtain a service using a processing system. The method utilises components each of which corresponds to a respective service portion provided by a respective entity. The method includes causing the processing system to determine a combination of components defining a sequence of service portions, in accordance with input commands received from the user. The processing system then implements the components in accordance with the component combination, thereby causing the sequence of service portions to be performed, such that the desired service to be performed.
Cool we can outsource to china (Score:2)
I'm sure I have heard this before (Score:5, Insightful)
I think I know what happened (Score:2)
Can You Say "Software Factory"? (Score:5, Informative)
This idea is an old one, and has been tried. It is known as the "software factory" [mit.edu] 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.
What on earth? (Score:2)
Way behind the times! (Score:2)
For many years, many of us thought that this was the bewst way to produce good software. Perl programmers admire "programs that write programs" (Something that us LISP programmers have been doing for decades). Programs like Rational Rose and Embarcadero and even Eclipse can generate pretty dang good code from models (UML), and there are dozens of good generators out there built on things like FSM design. James Martin wrote books in the'70's called something like, "Software which is Provably Correct" and Sys
You still have to tell it what to do. (Score:2)
You still have to tell it what to do.
Whether you use a language to tell the computer what to do or use a shitload of incomprehensible configuration options to do exactly the same thing.
Either way you are programming, though in only one of these do you actually have a chance to know what is going to happen.
Managing Complexity (Score:5, Insightful)
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
Re: (Score:2)
Re: (Score:3)
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??
Re: (Score:3)
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 JavaScrip