Slashdot Mirror
Could AI Transform Continuous Delivery Development? (thenextweb.com)
An anonymous reader quotes The Next Web:
According to one study, high-performing IT units with faster software releases are twice as likely to achieve their goals in customer satisfaction, profitability, market share and productivity. Acknowledgement of this has fueled a headlong rush toward what software developers call "continuous delivery"... It's a process most technology departments aspire to but only a fraction have achieved. According to a recent survey by Evans Data, 65 percent of organizations are using continuous delivery on at least some projects, but only 28 percent are using it for all their software. Among non-SaaS companies, that proportion is just 18 percent...
So what comes next? The future of application development depends on using artificial intelligence within the continuous delivery model... We're at the precipice of a new world of AI-aided development that will kick software deployment speeds -- and therefore a company's ability to compete -- into high gear. "AI can improve the way we build current software," writes Diego Lo Giudice of Forrester Research in a recent report. "It will change the way we think about applications -- not programming step by step, but letting the system learn to do what it needs to do -- a new paradigm shift." The possibilities are limited only by our creativity and the investment organizations are willing to make.
The article was written by the head of R&D at Rainforest QA, which is already using AI to manage their crowdsourced quality assurance testing. But he ultimately predicts bigger roles for AI in continuous delivery development -- even choosing which modifications to use in A/B testing, and more systematic stress-testing.
So what comes next? The future of application development depends on using artificial intelligence within the continuous delivery model... We're at the precipice of a new world of AI-aided development that will kick software deployment speeds -- and therefore a company's ability to compete -- into high gear. "AI can improve the way we build current software," writes Diego Lo Giudice of Forrester Research in a recent report. "It will change the way we think about applications -- not programming step by step, but letting the system learn to do what it needs to do -- a new paradigm shift." The possibilities are limited only by our creativity and the investment organizations are willing to make.
The article was written by the head of R&D at Rainforest QA, which is already using AI to manage their crowdsourced quality assurance testing. But he ultimately predicts bigger roles for AI in continuous delivery development -- even choosing which modifications to use in A/B testing, and more systematic stress-testing.
Welcome to the new age of yesterday.
>a new paradigm shift.
I stopped reading after this.
that's all, folks...
Go back to the drawing board and finish the flowchart before writing the code.
Holy Fuck.
Continuous integration
Prototyping
Incremental development
Rapid application development
Agile development
Waterfall development
Spiral development
Now, introducing, "Continuous Delivery"...or something.
Here is the actual model, a model that will exist for the next 1,000 years.
1. Someone (or something) gathers requirement.
2. They get it wrong.
3. They develop the wrong thing that doesn't even work they way they thought it should
4. The project leader is canned
5. The software is implemented by an outside vendor, with all the flaws.
6. The software operates finally after 5 years of modifications to both the software and the workflows (to match the flaws in the software).
7. As soon as it's all running properly and everyone is trained, a new project is launched to redo it, "the right way".
8. Goto 1
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Feature creep as a development model. Good times.
So, if my IT team wants to be twice as likely to achieve our goals, all we need to do is be "high-performing" Great! All our problems are solved.
A pair of proposal writers went drinking and one said he could write any story, so they used a random buzzword generator to pick the topic.
Can AI Transform Continuous Synergistic Delivery of Agile Development for Vertical Integration Systems Deployed in Collaborative Partnership Regions as a Total Cloud Service with Structured Performant Full Stack Data Modelling and Biogender Diversity Programs?
"Continuous delivery"? Just as well title it "Never-ending bugs" or "Endlessly never-working system". I'm fairly certain their billing system has similar characteristics: "Continuous billing" or "You'll never finish paying."
That none of you has even the faintest idea what this is about. Otherwise you wouldn't have translated the reasonable and effective subject matter into buzzwords. There really isn't any of that sort of thing.
I notice the targets are all set from the company's point of view... including customer satisfaction. However it's quite easy to meet any goal, as long as you set it low enough.
Companies like Comcast or Qwest objectively have abysmal customer satisfaction ratings; but they likely meet their internal goal for that metric. I notice, in their public communications, they always use phrasing along the lines of "giving you an even better customer service experience" - again, the trick is to set the target low and keep it relative.
#DeleteChrome
Any professional outfit will test a new release (in-house or commercial product) thoroughly before letting it get anywhere close to an environment where their business is at stake.
This process can take anywhere from a day or two to several months, depending on the complexity of the operation, the scope of the changes, HOW MANY (developers note: not if any) bugs are found and whether any alterations to working practices have to be introduced.
So to have developers lob a new "release" over the wall at frequent intervals is not useful, it isn't clever, nor does it save (the users) any money or speed up their acceptance. It just costs more in integration testing, floods the change control process with "issues" and means that when you report (again, developers: not if) problems, it is virtually impossible to describe exactly which release you are referring to and even more impossible for whoever fixes the bugs to produce the same version to fix and then incorporate those fixes into whatever happens to be the latest version - that hour. Even more so when dozens of major corporate customers are ALL reporting bugs with each new version they test.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Another one?
Keep at it kids, the faster you release buggy as fuck code the more I get paid to save your asses after you get breached.
AI is enough of a problem, why make it worse?
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
One study, well then I'm sold.
But do you know who likes Continuous Delivery?
Not the users.
The users hate stuff changing for the sake of change, but trying to convince management seems an impossible task.
Gotta chase them buzzwords, gotta catch 'em all. Sounds like some kind of manager of a failing division explaining that he is so far ahead of everyone else that he ought to be promoted over to an actual profit-making division. Sadly, it often works.
Anytime I see the words paradigm shift I hear silver bullet and tune out.
I suspect that article was actually written by an AI. That would explain why it makes so little sense to human mind.
sic
Loaded with marketing buzzwords. Doesn't say anything new about anything. Reads like an advertisment. Did someone pay to run this? Because it's shit.
IT in my company does network, Windows, Office and Virus etc. type of work. Is this what they talk about? Anyway, it's been long outsourced to IT (as in "Indian"
technology)...
4wdloop
I recently interviewed at a couple of the new fangled big data marketing startups that correlate piles of stuff to help target ads better, and they were continuously deploying up the wazoo. In fact, they had something like zero people doing traditional QA. It was not totally insane at all. But they did have a blaze attitude about deployments -- if stuff don't work in production they just roll back, and not worry about customer input data being dropped on the floor. Heck, they did not worry much about data losses even when things were working "correctly". To some people big data means no data really matters much, I guess.
That is a fine way to make money when these things are new and expectations are low, and there are easy ways to pick off a tiny slice of that googlenormous flow of ad money to achieve that IPO bliss. I could see AI helping out here.
But continuous delivery can easily suck for code that actually has to work so that people do not get fired or go bankrupt or even die. Continuous AI buzzwordology is not ready for this world.
You want your deployment system to be predictable, and as my old AI professor used to say, intelligent means hard to predict. You don't want AI for systems that just have to do the exact same thing reliably over and over again.
A continuous delievery pipeline has as much AI as a nematode has natural inteligence ... probably even less.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
1) Make something worthwhile (worth your effort and worthy for usage)
2) Goto 1)
The silver bullet is hidden inside 1) and depending on how short the cycle can be made.
Analyst who understands neither software development nor AI proceeds to try to sound insightful about both.
XML is like violence. If it doesn't solve the problem, use more.
It's a genetic algorithm where YOU are the population being flushed out each cycle.
Table-ized A.I.
All I know is that, as a user, rapid-release or continuous delivery has been nothing but an enormous pain in the ass to me and I wish it would die the horrible death it deserves already.
As long as customers are comfortable with doing this, I do not see a problem. Now, that will require that developers keep making continuous, worthwhile improvements to the code. Not some fluff change from a marketing recommendation that users want a lighter shade of red for their 'Stop' button.
As long as customers are comfortable with doing this, I do not see a problem
I'm a developer, not a "normal" user, and I would not be comfortable with this at all. However, it would be better than what is usually being done, because at least with that system I could easily decide when to upgrade and when not to.