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.
"What?"
Because "None of us is as dumb as all of us."
my bullshit meter just exploded
.
Or more likely, yet another company trying to sell its product that will make the need for software engineers obsolete.
Self-writing code!!!
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...
The summary reminds me of when you ask a child to describe something.
It was great!
There were planes, and they were all like woooosh, and firing there guns kabooom!
And then there was this guy, and he did something and the planes stopped, and everyone was all like woah!
This summary is basically the same thing except older children in suits who call themselves management.
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!
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+
I mean, the ONLY thing on their site is this white paper.
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.
Sounds like talking heads from the 90s.
Rational process, Java, and Corba were all supposed to create an era of "Internet" applications and software design by connecting components. This thinking brought us early versions of FireFox with XPCOM objects everywhere. Bulky, slow, and hard to work with.
Perhaps something will come of this, but software design standards don't seem to have advanced much in the right direction to make it happen. We're still arguing over process for creating reliable time estimates and development solutions, much less some grand unified software vendor plan. The cynic in me points this as someone that wants to outsource more engineering jobs to low cost firms.
We'll call it ware something, middle something ... ohhh middleware yes middleware,
and they can run on general application servers that provide standard basics tooling enterprise like, I like that Enterprise Edition, oh and it must use Java yeah Java EE middleware.
and they need to use the latest jargon Rest and small, not small ... mini oh I know micro, micro services... Java EE middleware micro services.
This is going to be revolutionary
Hey can we sell those apps in the App store?
Really, the same or similar code has probably been written hundreds of thousands of times through the years. We keep paying coders to write the same code again and again. There is no reason that we could not automate this process and get rid of the need for people who are mostly redundant and definitely overpriced. You should be able to whiteboard a program's major components, pay some graphical designers for art and placing the components where they should go, and an automated process fill in 90% of the code. The core section that is unique the particular software in question would still need to be hand coded by developers but in theory would only need to be done once as this wouldn't change much. It's where things are headed.
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.
Was this article written by a person or a computer?
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.
In the future all programmers will be super fit and experts at dance dance revolution
http://www.wired.com/2015/07/b...
The problem is you can only build so much from templates until you need more templates. That's the crux.
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.
About 35 years ago, a British company brought out a software product called "The Last One", a "program generator" that took high level descriptions and generated a BASIC program. They tried to go beyond the features of the 4GLs of their day (PowerBuilder, etc.) Of course, that software is long gone, and would be totally obsolete anyway. More recently, there are many other efforts at model-driven development, many of which point in the same direction as the vision of these wannabe "revolutionaries". About 10 years ago, Ravenflow (now owned by Versata) tried to generate use case and scenario diagrams (not code) from English, with limited success. Earlier this week, I saw an announcement that Facebook has developed "software that writes software". But I think we're still a long way from the point where software designers and developers have to worry about being replaced by requirements analysts who can describe "what" they want a program to do and have it automagically appear.
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.
Just watched Mr. Robot season finale. Revolution looked fun when they were planning it, but then everyone's 401k disappeared with the debts ... just sayin' ...
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?
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?
I also think, that an industrial revolution for software manufactoring is on the horizon, for the reasons named.
I differ in opinion about it's forming. What I personally think is more probable is the more frequent parametrization of software, but not in the sense of options in the delivered product, but in the build-process. E.g. a Developer writes an App for a Guide through "Louvre"-Museum , and then parametrizes its code step by step to use it also for other museums, e.g. "Prado"; the customer assebles her App through a Web-Interface an get's the compiled app deliverd to the App Store.
> Who is actually making the software
Make.
No seriously my interpretation is that that they are proposing something like how airplanes are built. Some companies make engines, others make instruments like altimeters, others make seats. Someome designs the whole aircraft, assembling an engine from Rotax, Subaru, Pratt & Whitney, or some other engine maker, with instruments from a company that makes instruments, etc.
Oracle's BPEL is exactly for this revolution, where in you can drag around existing services, translate different format, add user task user interfaces and more. The problem is, there is always a little change that is needed, that you end up creating a complex workaround that makes it not worth it.
Who will have to tie all these disparate entities together across time and the whole worldwide group of drone-coders.
Those MMs will have to keep prodding them to do their job, fix the problems, then introduce the "upgrades" and rehash everything over again and again.
That is a really efficient way to engineer products, right?
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.
Please do not read this sig. Thank you.
If it works for aviation, it certainly might work for business software.
You left out the 4GLs from the 80s.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
FTA:
Problem: Intellectual Property Exposure
Solution: Intellectual Property Protection
Premise:
1. Simplify Integration (this is not bad by itself)
2. Reduce Portability - components can only be used for what the supplier intended - runtime restrictions on how something can be used - content is defined at runtime, context is enforced
3. Reduce Re-Use: "harness strong context-dependency to render uneconomical any prospects for component re-use" - "remove the glue logic and the concept of the component" "synthesize on the fly" "replace the context-independent component with a context-dependent fragment"
This is NOT about automating ANYTHING but the how code fits together.
In the end, the suppliers own the code. The client owns the requirements. They propose that doing this will make suppliers want to code components that can interoperate since they can sell the components to multiple clients. In the current model, they say that code developed for the client cannot be re-used due to current contract logic.
This only occurs in small firms creating custom code. In larger firms, IP is retained and licensed to the client even if it is created for the client through contract terms.
This proposal in my view is nothing more than attempt to stifle coding - something the big companies have been trying to do for 50 years without much success.
But we do need to stay vigilant or we will have the same problem we do today in broadcasting: think Blue Ray.
Counter-example: LEGO Mindstorms programming interface
GUI drag-and-drop programming interface seems to work just fine for autonomous robots performing remarkably complex tasks...
I have a degree in Industrial and Systems engineering and worked in areas ranging from coding (in multiple languages from assembly up), systems analysis, network architecture and design and even network security so I can follow the buzzwords and hand waving in this about as well as anyone I suspect. However, it is still the most unmitigated piece of managerbabble and bovine excrement that I have read in a long time.
And the 1980's, and the 1990's, and the 2000's... CASE, 4GL, XP, ITIL, SEI, yadda yadda...
CRUD - Create, Read, Update, Delete.
I like it! Thanks!
Faster! Faster! Faster would be better!
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 facilitate intellectual property ownership
Mechanical engineers can buy a screw, ball bearing, gearbox and use them freely, wherever they fit. They don't need to adopt a design "religion" or include a large, restrictive set of base classes and frameworks
For anything really complicated they skip the Labview (that's what the LEGO GUI really is) and go straight to fast and powerful C.
This sounds like the Java Beans idea when Java came out. We were all going to be building interoperable Bean components. It was hilarious back then, and it is hilarious now. Ignore it.
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.
This is the greatest thing ever. We can outsource all of our code to china pakistan and india and integrate it automatically into our applications with no review for security!
"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."
For those of you who have managed global software project using facilities across the world, then you know what the failure of this methodology will be. It takes a 1000 page document to define the effort and outcome needed, but despite that document, the "Hello World" project will be buried in things like what font is to be used? What color should the text be? Should the text scroll, should the text blink on and off? What is the blinking rate? All this and more just for a simple printf statement! And for each off the wall question or idea, code writing stops... until another document is generated to clarify in detail what is to be done. Cost and time overruns are infinite if there aren't enough coders in silivaley to manage the coders overseas. The typical ration is 3 overseas and 1 in the US to do the actual work.
Life is in a state of dynamic equilibrium, it both blows and sucks
They have actually just described part of a fictional dystopia.
So, a whole bunch of people just graduated from school and realized the way we're currently doing software development is a lot of hard work, and all you need to do is automate it with magical fairies. As if no other generation of programmers before have come out of school with the same ideas. Further (relevant) reading.
"I have never let my schooling interfere with my education." - Mark Twain
This is an old idea. Back in the 1980s, a headhunter was no longer interested in talking to me after I said I was a computer programmer--he wanted to talk to designers. Well, of course, at our company (GE), we did the whole shebang: requirements, design, coding, testing, and integration. Simply saying I was a programmer had negative connotations.
A few years later (c. 1990), at a smaller company, I worked as a subcontractor to a large defense contractor and I encountered people who preferred just designing programs, writing them in a high-level pseudo-design language and then passing the designs off to "programmers" to be coded and tested. The problem is that there was no feedback loop, so these designers never really learned from what they did right and what they did wrong (as well as not getting hands-on experience with the technologies we were using), precious experience for a software developer.
This was written by B. Meyer some 20 years back
"Beyond this, it is hard to assess the contribution of Structured Design to the overall goal of
software engineering – software quality. Whatever its authors may have intended, the main practical
effect of Structured Design will have been to convince a notable segment of the computing industry
that:
As opposed to ‘‘programming’’, a despicable occupation fit for the toiling masses, design is a
noble craft, the only one worthy of consideration by the data processing elite.
This craft is carried out by drawing circles and connecting them with arrows."
See subject: I found that once you design classes or full-blown objects, they tend to become "application specific" whether you like it or not (unless you want to build "gazillions" of little ones, each one doing some TINY specific part & then, you have to KNOW what each actually does in order to "restitch" & reuse them).
ActiveX controls, VCL, they're along those lines too... yes, it's "doable" but how well for actual business processes? I worked in the MIS/IS arena & NO 2 BUSINESSES DO BUSINESS EXACTLY THE SAME, nor is their data the exact same.
How on earth would you actually make this work?? It hasn't fully, yet, in that specific arena (business).
It's EASY to "come up with an idea", ANYONE can do that - it's the devil in the DETAILS of actually making it happen that NOT ANYONE CAN DO (hence why there's actual coders).
APK
P.S.=> Especially since it seems NOBODY IS ACTUALLY WRITING THE CODE HERE in this "idea" (another 10,000 ft. idea from those that apparently haven't actually done the job is what this sounds like, & what MinWee alluded to as well -> http://developers.slashdot.org... )
... apk
Oh, man! I can see the licensing battles now! That ought to make for a very slow 'revolution'.
“He’s not deformed, he’s just drunk!”
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/
This is probably the dumbest thing I've seen published by Slashdot.... isn't this simply some sort of redefinition of "libraries" or "modules"?
Oompa Loompa, mofo!
"Never give up, for that is just the time and place when the tide will change." -Harriet Beecher Stowe ^_^
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 System Design from Provably Correct Constructs" which used a logical design model (HOL) to generate good programs. IMNSHO, coding is the least productive use of a Software Engineer's time.
"The mind works quicker than you think!"
Actually,
This is how software is done in the aerospace world. We start with a top level requirements document, break that into lower and lower level requriements, and about the time that we're done with that, writing the software is easy enough that there's really no need for programmers; the engineers can do it.
Software development is a design process. There is no such thing as "industrialised design" in any market you care to name, e.g. architecture, engineering, music, art etc. You might as well propose symphony composition through a supply chain of specialist musicians. Ludicrous.
npm etc?
A chaotic hell of vendor published packages, which takes forever to find that one piece of software that you need....
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.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Not to mention how hard it is to do source code control (svn, git, etc.) on CASE specifications, especially when (like LabView) they're in binary files. Sure, you can build a toy in a few days, but you can't maintain a large project with that shit because there's no way to track changes.
Visual LEGOid drag-a-block gooey editors are flashy and give PHBs boners, but change management is un-sexy and gets ignored by the people pushing that crap. (Once they've sold it to your PHB, their job is done!)
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Sounds like someone is wants to get away with paying programmers $25k a year
When "designers" are able to accurately and thoroughly able describe the solution, they can hit the "build" button. I do it all the time. I accurately (most of the time) and thoroughly (as much as I can or need to) describe the solution to my problem in eclipse using the Java language. Once I am happy, I run a build script and my product comes out. I think what the OP _really_ wants is a way to talk around a problem and have someone else go do it. Then, when that (person/company/outsourced "peer" resource) delivers the wrong thing, the "designer" can blame the implementer. You know, just like it is now.
We can barely, just barely make distributed busses and their devices, work correctly.
ADB, FireWire, Thunderbolt, USB
Of those 4 items, only USB has worked out, because Microsoft has taken charge of most of the protocol and architecture. Thunderbolt works now. However it will be very interesting to see if it continues to work into the future. ADB/Firewire died, for reason related to the fact that no one could agree, greed, and technical reasons.
where the emphasis is no longer on writing code, but on decentralized design – code becomes simply a by-product of this collaboration.
Not going to happen until there's an AI that can understand a design doc.
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
As I mentioned in my original post, my plane can accept three engines, from two different companies. In long-term essential software especially, it's good not to be locked in to a single supplier.
My car also comes with three engine options. Each of those engines is also used in other cars and trucks, of different marques.
What I didn't mention is what they are suggesting that's "new". It's been done before, but they are suggesting that it may become the predominant model. That's outsourced components built to spec. Right now, an equipment manufacturer can ask Honda to build an engine that meets their specs. Toyota outsources 70% of their production this way, specifying what their suppliers will build for them. So they don't choose an alternator off-the-shelf, they specify that they want alternators that produce 70 amps, at X rpm, etc. Then the alternator manufacturer builds what Toyota ordered. That isn't done very much in software. You could ask me to build you a component which scrapes Slashdot stories and outputs XML and I wouldn't need to know what you're using it for. In some ways it could IMPROVE quality by enforcing disciplined encapsulation and making highlighting the assumptions that we often make.
HAHAHAHAHAHA....*pause for breath*.....BWAHAHAHAHAHAHAA
Whew. That was a good one. Man you had me going there, Slashdot.
Now for an encore I'm going to build a pocketwatch. Well...I'm not actually going to build one, I'm just going to talk about what one does. Then I'll outsource all the gears and springs to experts, then throw them in a pillowcase and shake the thing until i get a watch. The watch should happen as a by product.
Weaselmancer
rediculous.
Any time you hear something like this run. This is just a manager's way of paying you less by making you work like an industrial revolution wage slave:
https://en.wikipedia.org/wiki/Piece_work
Management's most cherished goal is setting the cost of labor at something approaching the value zero. Right now software developers make up a large labor cost that is "draining" the efficiency with which they can transfer dollars from the consumer to the shareholders. They will not rest until that inefficiency is taken care of.
One day the managers from all the major companies are just going to be sitting around saying, "Where did all our customers go. We can't seem to sell anything any more." Someone will have to remind them that they fired or marginalized all the other people in their companies and now there is no one left to buy their products.
Maybe it means there actually is something to it?
Having read the entire article I feel there is much in there that I don’t fully understand or isn’t fully explained, and that quite possibly the devil is in the details, but at the same time, I don’t feel confident in dismissing it outright.
Some aspects of it seem facsinating. For this thing to work, the very notion of a programming language or compiler would have to be rethought. It sounds like it might involve some framework that is both a market for vendors and also a “compiler" that assembles the “fragments” together into code that actually runs. It boggles my mind. It sounds vaguely like distributed anonymous corporations, another thing I have read about that boggles my mind.
But just because I don’t understand it, I won’t dismiss it outright. That’s the things about a crazy idea. It can either be revolutionary, a paradigm switch that experts in the field (current software developers) dismiss, or it is complete bullshit. This feels like one of those ideas.
CASE did not fail.
It is still a huge market in the software industry. Just because you don't use a CASE system does not mean others do not either.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
back in the day you got your software from the same vendor, possibly even the hardware. when something went wrong, be it some service stopping, some communication link dropping or some tape getting stuck, the vendor took responsibility, and you paid just one or a couple of hefty bills.
then came the revolution of decentralization. it was supposed to be cheaper and more efficient. since then when something went wrong chances were you wouldn't even know who to call from a constellation of providers of apps, middleware, drivers, services, components and whatnot, each of which dependent on it's own chain of providers, so you could have to live with the problem for a looooong time before it was even known who's problem it was, all this in exchange of a hefty collection of smaller bills which totals considerably more.
turns out it wasn't more efficient and cheap at all, just more convenient and profitable for the industry.
now it's about going totally cloud-nuts? yeah, what could possibly go wrong ...
and guess who just so happens to have several patents on the code generation?
Anons need not reply. Questions end with a question mark.
It's complete bullshit, at least at the current state of the art. It's not a new idea either. People who aren't actual developers have been pushing this idea of drag-and-drop "programming" since the early 80s at least. 30 years of work, and the most they've managed are tools to automate generating the boilerplate code to lay out UI elements in the software's interface. They haven't even managed to automate moving the values from the UI fields into the software's internal objects/variables, the task's just too complex for their tools. So, why would anyone thing they'll overnight overcome all the problems and hurdles in their way and suddenly make orders of magnitude more progress in the next couple-three years than they have in the last 3 decades?
The ability to separate design from construction is something that's possible in almost all engineering fields.
But there is one exception: software engineering. Software engineering is unique because the design and the construction are one and the same. With software, there is no separation of "blueprint" versus "finished article", like there is in all other engineering fields.
The whitepaper's ideas depend on the separation of design and construction. That won't work in software engineering, where no such separation exists.
I've seen many bullshits - but this one beats most (if not all) of them :)
When I got to this point: ...
'We propose to simplify component integration to its irreducible minimum – concatenation'
I was like - 'whaat' ?!? - that's enough
They propose a 'software revolution' by creating a 'software assembly line' ???
Family Lovisa - please don't lose our time, as we're actually trying to solve the mess of so many similar prophets like you coming from the past.
It seems you don't really UNDERSTAND software - so how the hell are you planning to SOLVE its problems.
Yet another pontificate by academics who have never actually worked on a software project about the reasons why so many software projects fail. The problem is that we have a propaganda machine that says "anyone can make software" and the reason for that is simply to create the illusion of increased supply in order to suppress salaries and benefits for software and IT folks. After 20+ years in this game I now know what the "methodology" business is all about. Just another MBA snake oil. The same shit goes for "microservices". Oh look....lets have an entire OS container for one web service that does one stupid little thing and just use the "cloud" to scale it out. Ya, who wins here --- hardware vendors, cloud vendors, offshore outsourcing. It's all shit. Its amazing I still work in this field after all the shit I've eaten in it. There are some amazing software craftspeople who make the shit that really counts - kernels, drivers, hypervisors, etc. That's never what the mainstream press is talking about -- they are talking about bullshit marketingware nonsense that some corporate asshat dreamed up and wants live RIGHT NOW and the $18/hr kids who graduated yesterday in koombukafuckaracha are struggling to get it live. Yeah, I'm a little bitter ... :-)
The outright dismissals are most likely coming from the more experienced developers who have seen this promise at least once before during their career. Every so often someone, or a group, comes along with this silver bullet that promises to change how industry is going to work. It almost never does and it certainly won't overnight. If your manager comes in and says that a product or process will solve all the groups problems with development then your BS detector should be going off full tilt. There are no silver bullets. There are tools that can help your process. Nothing can fix everything.
As to this somehow writing the code as a byproduct. The best developers tend to be lazy. If there's something that they do repeatedly then they will find a way to automate it (even if it takes longer to do than the task itself). So if there was a way to generate code automatically or to create a language that would express what we want the computer to do more naturally then someone would probably have done it already as there would be a lot of money or fame for doing so.
"...Code is no longer the Software Engineer's specific responsibility. Instead, engineers from each layer of the hierarchy contribute to the overall design until an executable coalesces as if by magic from their combined efforts."
The article contains no actual method for constructing software. You will notice that the authors talk about Intellectual Property a lot, which puts the article in the domain of Law or Economics.
... I want to do a play in the shack in the little shack in the backyard... come on gang let's sing....and I want to play the Grand Piano.... and be an ballerina... and an astronaut... and lets dig a hole to China!
We have all seen this before. A zillion things like UML being used for code generation. And yes, I fully believe that this will be the future of programming. I personally pretty much think in symbols for what I am going to do. Way back in the early days of VB (before .net) they had an interesting idea that you would click on a button and that would bring up the code that "powered" that button. This sort of symbolic thinking is definitely the way to go. But this breathless reporting on this "breakthrough" deserves to have propellers attached and be put on the front page of Popular Mechanics.
Here is a simple litmus test. Every language that has taken the world (at least eventually) by storm had a slow but almost methodical progression from interesting idea to reaching an interesting point where the language was ready and suddenly the world was seeking just such a language. C++ was object oriented just as the Windowed operating environment really was calling for something more than C. Perl was ready in the early days of the web and Python came into its own when hyper efficiency of a language was no longer a chief concern but ease of use was.
Even languages such as Go are being thrust upon us by the likes of Google aren't really getting as much traction that such a marketing effort would suggest.
So in the history of languages I can't think of a single one that did something that others could already do that took over in a flash; even if that language was theoretically better.
So my prediction for the eventual graphical/symbolic language that will eventually take over is that nobody but a very few will hear about it for many years as it slowly matures. Then some new problem will come along where that language is very very good at solving the problem. At that point everyone will leap aboard that language. The alternative is that some dildo at a company like Apple will choose it as the de facto standard for programming their proprietary system such as iOS 11 and then force it down our throats. I very much doubt that one person in 1000 who knows Objective-C learned it for any other reason than to make iOS apps.
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.
Just what we need: immensely complex software. So now it'll be easier than ever to roll out complex piles of spaghetti code like Windows. Will this software be less bug-free than today's? Will it have fewer potential security exploitations? I'm doubtin' it.
CUR ALLOC 20195.....5804M
So, why would anyone thing they'll overnight overcome all the problems and hurdles in their way and suddenly make orders of magnitude more progress in the next couple-three years than they have in the last 3 decades?
I don't think the author is claiming to fix anything overnight. I think the argument is that the way things are is a product of history and that there *may* be another way to look at things. The paper doesn't offer a solution, not today, not in a hundred years. It is merely asking us to consider an alternative and I found it to be fascinating. It's more speculative fiction at this point than an actual blueprint, but that's no reason to dismiss something just because it is speculative.
All this been done before. Take Borland of 15 years ago or so, for example.
* Database: Program against SQL Links and plug any one from a number of popular database engines.
* User interface: VCL library for Windows and drop-in replacement CLX for Linux.
* Components: instead of making your own, purchase pre-made components from a catalog, and combine them in your RAD application.
Oh yes, RAD, Rapid Application Development, remember that?
Told you---old and busted
"They propose shifting developers from the coding domain .. but on decentralized design – code becomes simply a by-product of this collaboration"
This sounds like it was written by some middle manager who would prefer they didn't have to rely on their programmers to a) write the code and b) actually generate revenue for the organization.
The outright dismissals are most likely coming from the more experienced developers who have seen this promise at least once before during their career. Every so often someone, or a group, comes along with this silver bullet that promises to change how industry is going to work. It almost never does and it certainly won't overnight.
I made a similar reply to somewhere else. I didn't feel the author was proposing a silver bullet or something that could be done today. It took decades to develop software engineering as it is today, and this alternative model would take decades too (assuming it works), which makes it all but impractical in reality.
But I think the author is asking us to consider the possibility. It's more speculative fiction at this point than an actual blueprint, but I feel there is some value in questioning the way things are.
>> That isn't done very much in software. ...
> Sure it is. You get a database from one supplier
> Even a lot of commercial software contains components from other companies;
You write your software to communicate with MySQL or Oracle. Off-the-shelf MySQL. You don't normally have the MySQL team create a unique database engine to your specs in order to integrate it as part of your software. Like "body by Fisher", not "Interstate battery". I think they are pushing the "body by Fisher" model. So you'd hire my company to build the authentication system that goes into your product, a unique authentication system designed for your needs.
I don't know if their approach will work well or not.
I can't believe how many people are freaking out in the comments on this one. That paper describes the unix model of software architecture and open source development.
Many companies are already using this type of model instead of purchasing some monolithic ERP system that does half of what they need well and the rest is a nightmare. Companies that have the most successful systems have an on-staff team that works on integrating many pieces of software that do exactly what is needed. This paper proposes the same model but with hiring a consulting company to pick your software and integrate it instead of having an in-house team.
The only part I disagree with is their idea of having every piece of software custom built, that's just stupid and needlessly expensive. Companies just need to start purchasing modern software with clean API's instead of decades old shit that is impossible to integrate.
The same principle does work in software. Chrome and Safari use the same 'engine'. With enough thought and effort it works fine. The problem is generally business software is typically bespoke to a specific business and also big and sprawling. It's more like a custom aircraft carrier than a car!
Translation: More cheap outsourcing
Designing our software at all, instead of slapping it together, would be a good approach.
I just don't see it here. It needs more than a shift one layer of abstraction up.
Assorted stuff I do sometimes: Lemuria.org
Back in the 80's some software company was doing the rounds with "Our system will write your software without you knowing programming".
It was supposed to be "The Last" program ever written.
Sounded like crap then and it sounds like crap now.
Pick one and you might get it, pick both and you get neither.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Isn't this pretty much what topcoder already does?
Without having read the actual PDF (naturally), the description basically matches the competitive software component marketplace that topcoder provides. And, yes, like other commenters have mentioned, it seems like a Mechanical Turk style race to the bottom. Thankfully their component model seems a litte broken to me, so, perhaps that's why it hadn't taken over the industry.
Signatures are a waste of bandwi (buffering...)
...then their whole idea of design and development is doomed to fail. Their entire website consists of:
1. The whitepaper linked in the summary.
2. A chance to 'stay notified' by handing over your email address.
3. A contact email address.
4. A privacy policy.
Seriously. That's it. I don't even know what this website is for. Or who made it. Or why.
The only thing missing is a bunch of links that all lead to an 'under construction' page that will stay there for eternity.
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.
The reason it's RWD: it's sporty. You can drift it. It's the spiritual successor to the ae86 RWD toyota corolla, which is an iconic drift car. AWD is for poor road conditions, not for motorsports.
Well you'd want Subaru BRZ, which is the AWD version of the Toyota 86.
... procedural programming ... modular programming ... object oriented development ... remote procedural programming ... edifact ... component oriented development ... model driven software engineering ... service architecture ... microservices
It people just love new stuff we keep reinventing the wheel with a few enhancements
I'm a professional programmer and I've used the new Lego mindstorms interface and I wasn't impressed. Initially I was overthinking how to use it, since they have made things very simple. So for an absolute beginner the level of entry is very low. However, such programs are simply learning exercises and are effectively useless for anything. The moment I wanted to do anything interesting or complicated the whole approach blows up in your face. Try implementing a loop. Now try conditional branching. Unless I missed it in the manual, they don't have a vanilla "IF" branching block, all the branching is "tacked on" to other operating blocks.
A lot of visual coding (Labview included) interfaces suffer in exactly the same way. They're easy to get started on, but they are no good for doing anything complex or interesting. So I have always wondered what is the point of them.
Right. Because those two things are mutually exclusive.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
See subject: Want to know what blows those out of the water in OOP? Rootkit drivers... drivers in Ring 0/RPL 0/kernelmode can "pierce into" & view ANY running processes' data - EVEN WHEN SET AS "PRIVATE/PROTECTED" in object instancing/marshalling...
* Think about it, especially in the case of rootkits & their malicious intent, when the use drivers (& they often do)... it's how/why keyboards work for every app there is & minus large delays (since kernelmode gets more CPU service) - by polling interrupts vs. every app having to write a keyboard routine.
APK
P.S.=> Each object you create/instance, also adds typically between 572k & 1mb of added overheads as well & for what? The above?? So much for the "invulnerability of objects"... MAYBE vs. usermode programs, but NOT kernelmode ones such as drivers & rootkits that utilize them! apk
Design doesn't happen in a top down way in healthy projects. This is a recipe for gold plated, over engineered, unimplementable crap.
Those rally drivers just don't know how wrong they are.
Negative, the Subaru BRZ is still RWD. They left it that way intentionally. Also, Subaru did design the engine, but it uses a Direct Injection system developed by Toyota.
It sounds like a perpetual-motion machine crossed with a multi-level marketing scheme. Everyone gets rich! Except they won't.
Has anyone check out the www.codevalley.com website?
What is the web server they are using? the page source looks unusual.
Did they build there own?
Yes, they totally didn't form that into blink vs WebKit, where safari/WebKit is now significantly lagging behind chrome/blink
Who will take responsibility for fixing bugs when they realize a mistake was made? This isn't so much of an 'Industrial' revolution as it as Bureaucracy revolution. It won't even take a major zero-day exploit before the finger pointing starts and patches (assuming they come out at all) take months to years to come out.
Not to mention how hard it is to do source code control (svn, git, etc.) on CASE specifications, especially when (like LabView) they're in binary files. Sure, you can build a toy in a few days, but you can't maintain a large project with that shit because there's no way to track changes.
Visual LEGOid drag-a-block gooey editors are flashy and give PHBs boners, but change management is un-sexy and gets ignored by the people pushing that crap. (Once they've sold it to your PHB, their job is done!)
Don't I know it. We've got some legacy Labview stuff running around to control instrumentation, etc (exactly what Labview is for, in theory) but as feature creep sets in those things have gotten incredibly unwieldy. I'm trying to move us towards Python for automation and control scripts because at least it plays nice with SVN and is easy to document.
Looks like youre famous. Check out their site.