“The Code-and-Fix Model. The basic model used in the earliest days of software development contained two steps:
:1. Write some code.
:2. Fix the problems in the code.
Thus, the order of the steps was to do some coding first and to think about the requirements, design, test, and maintenance later. This model has three primary difficulties: (a) After a number of fixes, the code became so poorly structured that subsequent fixes were very expensive. This underscored the need for a design phase prior to coding. (b) Frequently, even well designed software was such a poor match to users' needs that it was either rejected outright or expensively redevelopment…”

Source: A spiral model of software development and enhancement. (1988), p. 61-62

Adopted from Wikiquote. Last update June 3, 2021. History

Help us to complete the source, original and additional information

Do you have more details about the quote "The Code-and-Fix Model. The basic model used in the earliest days of software development contained two steps: :1. Wri…" by Barry Boehm?

Barry Boehm18

American software engineer 1935

Rebecca Wirfs-Brock (1953) American software engineer

Source: Object-oriented design: a responsibility-driven approach (1989), p. 13

“The real value of tests is not that they detect bugs in the code, but that they detect inadequacies in the methods, concentration, and skills of those who design and produce the code.”

C. A. R. Hoare (1934) British computer scientist

How Did Software Get So Reliable Without Proof? Lecture Notes in Computer Science vol 1051 1996 pp. 1-17 : FME '96: Industrial Benefit and Advances in Formal Methods, Third International Symposium of Formal Methods Europe, Co-Sponsored by IFIP WG 14.3, Oxford, UK, March 18-22, 1996, Proceedings.

“Economic principles underlie the overall structure of the software lifecycle, and its primary refinements of prototyping, incremental development, and advancemanship. The primary economic driver of the life-cycle structure is the significantly increasing cost of making a software change or fixing a software problem, as a function of the phase in which the change or fix is made.”

Barry Boehm (1935) American software engineer

Source: Software engineering economics. (1984), p. 4

“Why don't we write code that just works? Or absent a "just works" set of patches, why don't we revert to code that has years of testing? This kind of "I broke things, so now I will jiggle things randomly until they unbreak" is not acceptable. […] Don't just make random changes. There really are only two acceptable models of development: "think and analyze" or "years and years of testing on thousands of machines."”

Linus Torvalds (1969) Finnish-American software engineer and hacker

Those two really do work. <br class="br"> Torvalds, Linus, 2011-04-13, Linux 2.6.39-rc3, 2011-04-21 http://thread.gmane.org/gmane.linux.kernel/1126136, <br class="br">2010s, 2011

“It was a rather extraordinary conversation if you think about it -- both of us speaking in code. But not military code, not Intelligence or Resistance code -- just feminine code.”

Elizabeth Wein book Code Name Verity

Source: Code Name Verity

“The spiral model presented in this article is one candidate for improving the software process model situation. The major distinguishing feature of the spiral model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process. It incorporates many of the strengths of other models and resolves many of their difficulties.”

Barry Boehm (1935) American software engineer

Source: A spiral model of software development and enhancement. (1988), p. 61

“Creating a modeling language that is also an executable language has long been a goal of the software community. Many years ago, in 1968 to be exact, while working with software components to successfully develop a telecommunications system, we created a modeling language that was the forerunner to UML. To model components we used sequence diagrams, collaboration diagrams, and state transition diagrams (a combination of state charts and activity diagrams). Our modeling language then seamlessly translated the component models into code. Each code component was in its turn compiled into an executable component that was deployed in our computer system. The computer system was a component management system—thus we had "components all the way down."”

Stephen J. Mellor (1952) British computer scientist

Source: Executable Uml: A Foundation for Model-Driven Architecture, 2002, p. xxiii: Foreword.