The Case for Evolvable Software
Recorded at:
- Share
-
- |
Read later
My Reading List
Bio
Stephanie Forrest is Professor and Chairman of Computer Science at the University of New Mexico and a Research Professor at the Santa Fe Institute where she is an external faculty member. Before that she was a Director's Fellow at the Center for Nonlinear Studies, Los Alamos National Laboratory. She received her Ph.D. in Computer and Communication Sciences from the University of Michigan.
SPLASH's mission is to engage software innovators from all walks of life -- developers, academics and undeclared -- in conversations about bettering software. Bettering software involves new ideas about programming languages, tools, conceptual models, and methodologies that can cope with, evolve, and leverage, the complex software-intensive socio-technical system of systems that has emerged in front of our eyes during the past decades. Bettering software requires a deep understanding of the nature of these systems, an understanding that rides on the trends of the moment, but that goes well beyond. These are the topics of SPLASH.
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
measure of robustness flawed.
by
Steven Soroka
Re: measure of robustness flawed.
by
Melle Koning
If production code evolves like this you probably mean 'not readable' with 'crippled'. Correct?
The question is if that matters. As long as you can understand your the written tests, and are able to write new test-cases, than knowing exactly what to change in the production code might be less relevant; the computer might be able to figure that out.
Cheers,
Re: measure of robustness flawed.
by
Hans-Peter Störr
Re: measure of robustness flawed.
by
Melle Koning
I understand what you mean. Now just for the sake of following the proposal of evolving software: suppose that the job of a software engineer would be to add new tests only and -not- touch the production code anymore.
Would the software engineer be able to steer the evolution of the productioncode with newly written unittests? Could we add new features by writing unit tests that do not pass (yet!)?
Personally, I think we can't, because if we would add a new test, we are never sure if it is a 180 with a previous test that was written by somebody else. In other words, evolving software would then never be able to pass all tests...simply because new ones could be totally the opposite of existing tests.
Cheers,
Re: measure of robustness flawed.
by
Hans-Peter Störr
When writing software, you usually have two somewhat othogonal "safety nets" to ensure correctness: first, the developer thinks carefully about the code when changing it, and second, one writes tests to verify the whole thing. If you remove the first safety net by evolving the software automatically, you need to strengthen the second net considerably. It is not clear to me whether this actually saves human effort in the end.
Perhaps there are special areas where it is very easy to write and maintain many tests, or where there is some kind of "training area" for the evolving system, or where bugs are inconsequential and can be fixed automatically right away. Maybe the evolving system serves as a special kind of machine learning.
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think