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.
>a new paradigm shift.
I stopped reading after this.
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.
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
Yeah, this is an incredibly low quality article. It doesn't specify what it means by what AI should do, doesn't specify which type of AI, doesn't specify why AI should be used, etc. Junk article.
It's basically a bullshit bingo post where someone repeats a buzzword without any knowledge of the material behind it.
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.
It's amazing how common this attitude has become. It's aggressively anti-customer, and a big part of the reason for the acceleration of the decline of software quality over the past several years.
'continuous delievery' is a term with a defined meaning. And releasing phone apps with unwanted UI/functionality in rapid succession is not part of that definition.
It is a natural consequence of a continuous delivery, emphasis on always evolving and changing and that the developer is king and no one can question developer opinion. Devolper decides it should move, it moves. No pesky human testers to stand up and say 'you confused the piss out of us' to make them rethink it. No automatic test is going to capture 'confuse the piss out of the poor non-developer users'.
If you have crashes on those nodes or customer complaints you roll back.
Note that a customer with a choice is likely to just go somewhere else rather than use your software. They'd actually have to care about your success to bother complaining if there is any hint of competition in the market.
The problem is that automated testing is no substitute for a QA team. This is fine for continuous integration, where the output is not considered production ready. A QA team consisting of people just like your real users who are paid to put up with your crap and complain rather than just go on to a competing product. Not people who know the code inside and out and are ready to help rationalize your design choices, but people who will challenge you, and rightfully tell you they don't give a shit that you think it's hard to do it the way that makes sense.
Continuous delivery is impossible to say that QA team still matters, as they have no ability to intervene when you go down the wrong path.
I don't see a reason why that would not work for embeded likewise.
Because 'crashes' and/or 'customer complaints' can mean people die in some of those cases, so saying 'rollback if it didn't work' is too late.
.
XML is like violence. If it doesn't solve the problem, use more.