Software Engineering: Software Engineering (Just the Quotes)

"Software engineering is the part of computer science which is too difficult for the computer scientist." (Friedrich Bauer, "Software Engineering", 1971)

"[Software engineering is the] establishment and use of sound engineering principles to obtain economically software that is reliable and works on real machines efficiently." (Friedrich Bauer, "Software Engineering", Information Processing, 1972)

"Throughout the software life cycle, there are many decision situations involving limited resources in which software engineering economics techniques provide useful assistance."(Barry Boehm, "Software Engineering Economics", 1984)

"Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. Much of the complexity he must master is arbitrary complexity [… ] because they were designed by different people, rather than by God." (Fred Brooks, "No Silver Bullet", 1986) 

"Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter 'How to program if you cannot'." (Edsger W Dijkstra, "On the cruelty of really teaching computing science", 1988)

"One principle problem of educating software engineers is that they will not use a new method until they believe it works and, more importantly, that they will not believe the method will work until they see it for themselves." (Watts S Humphrey, "The Personal Software Process", 1997) 

"Software is a great combination between artistry and engineering." (Bill Gates, "Bill Gates Speaks: Insight from the World's Greatest Entrepreneur", 1998)

"In all engineering disciplines nowadays, software engineering excluded, there exists an established engineering process to develop a system, which is accompanied by a number of suited modeling description techniques. Software engineering, being a rather new field, has not as yet established any clear methodical guidance or a fully standardized modeling notation." (Bernhard Rumpe, "Executable Modeling with UML: A Vision or a Nightmare", 2002)

"The entire history of software engineering is that of the rise in levels of abstraction." (Grady Booch, "The Limits of Software", 2003)

"Software engineering concerns methods and techniques to develop large software systems. The engineering metaphor is used to emphasize a systematic approach to develop systems that satisfy organizational requirements and constraints." (Hans van Vliet, "Software Engineering: Principles and Practice", 2007)

"The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exist." (Grady Booch et al, "Object-Oriented Analysis and Design with Applications", 2007)

"A lot of research in software engineering strikes me as hopelessly naive in one of two ways. Most of it fails entirely to account for the social and belief aspects altogether. It looks at its object of inquiry as if it was entirely material and inert; as if 'software' was some kind of naturally occurring substance, the properties of which can be revealed in the equivalent of a test tube." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"Design is the process of taking something that appears in the mind’s eye, modeling it in one or more of a number of ways, predicting how that thing will behave if it is made, and then making it, sometimes modifying the design as we make it. Design is what engineering is about. Furthermore, modeling is how engineering design is done. This includes mental models, mathematical models, computer models, plans and drawings, written language, and (sometimes) physical models." (William M Bulleit, "The Engineering Way of Thinking: The Idea", Structure [magazine], 2015)

"The fact that software engineering is not like other forms of engineering should really come as no surprise. Medicine is not like the law. Carpentry is not like baking. Software development is like one thing, and one thing only: software development. We need practices that make what we do more efficient, more verifiable, and easier to change. If we can do this, we can slash the short-term cost of building software, and all but eliminate the crippling long-term cost of maintaining it." (David S Bernstein, "Beyond Legacy Code", 2015)

"Over-engineering is a real disease of many engineers as they delight in design purity and ignore tradeoffs." (Alex Xu, "System Design Interview: An insider's guide", 2017)

"Good engineering is the difference between code running in eight minutes or eight hours. It affects real people in real ways. It's not a 'matter of opinion' any more than a bird taking flight is a 'matter of opinion'." (H W Kenton)

Software Engineering: Software Engineering (Definitions)

"Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines." (Peter Naur & Brian Randell, 1968)

“[Software engineering is the] establishment and use of sound engineering principles to obtain economically software that is reliable and works on real machines efficiently. (Friedrich Bauer, "Software Engineering", Information Processing, 1972) 

"(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. (2) The study of approaches as in (1)." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"(1) The disciplined and systematic application of methods, techniques, and tools to the development, operation, and maintenance of software and software-intensive systems. (2) The building of large, complex software-intensive systems by teams of engineers and programmers. (3) The study of the activities defined in (1) and (2)." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A discipline that advocates a systematic approach of developing high-quality software on a large-scale while taking into account the factors of sustainability and longevity, as well as, organizational constraints of time and resources." (Pankaj Kamthan, "Pair Modeling", 2008)

"Application of a systematic, disciplined, quantifiable approach to the development of Information Systems/Software." (Leonor Teixeira et al, "Web-Enabled System Design for Managing Clinical Information", 2008)

"Techniques, models, and processes to develop quality software" (M J Escalona & G Aragón, "The Use of Metamodels in Web Requirements to Assure the Consistence", 2008)

"To engineer the development of software comprises a rigorous analysis and design of the product, the application of formal methods in the development process an in the resulting product description, and modularization of the relevant parts of the software to allow for malleability and for reusability." (Alke Martens & Andreas Harrer, "Software Engineering in e-Learning Systems", 2008)

"It is the computer science discipline concerned with creating and maintaining software applications by applying technologies and practices from computer science, project management, engineering, application domains, and other fields." (Graciela D S Hadad & Jorge H Doorn, "Creating Software System Context Glossaries", 2009)

"Software engineering is a well-established discipline that groups together a set of techniques and methodologies for improving software quality and structuring the development process." (Ghita K Mostéfaoui, "Software Engineering for Mobile Multimedia: A Roadmap", 2009)

"The software engineering discipline covers the development of software systems. Software engineers focus on applying systematic, disciplined, and quantifiable approaches to the development, operation, and maintenance of software." (Rick Gibson, "Software and Systems Engineering Integration", 2009)

"A discipline that advocates a systematic approach of developing high-quality software on a large-scale while taking into account the factors of sustainability and longevity, as well as, organizational constraints of resources." (Pankaj Kamthan, "A Social Web Perspective of Software Engineering Education", 2010)

"Is a systematic and disciplined approach to developing software, which applies both computer science and engineering principles and practices to the creation, operation and maintenance of software systems." (Christian Scholz et al, "From the Lab to the Factory Floor: Engineering Software for Wireless Sensor Networks", 2012)

"Is the study and application of engineering to the design, development, and maintenance of software. In short, the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software." (Rosanna Costaguta, "Data Mining Applications in Computer-Supported Collaborative Learning", 2015)

"An engineering discipline that involves with all aspect of software development that applies engineering approaches in order to deliver high quality software products." (Seyed R Shahamiri, "The Challenges of Teaching and Learning Software Programming to Novice Students", 2018)

"The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software." (Tamer Abdou et al, "Developing a Glossary for Software Projects", Encyclopedia of Information Science and Technology, Fourth Edition, 2018)

"Software engineering is the discipline and best practices used in developing software." (Alex Thomas, "Natural Language Processing with Spark NLP", 2020)

"The application of engineering to the development of software in a systematic method." (Shanmuganathan Vasanthapriyan & Kalpani M U Arachchi, "Effectiveness of Scrum and Kanban on Agile-Based Software Maintenance Projects", 2020)

"The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches." (Antonio A M Costa, "Disciplined Teams vs. Agile Teams: Differences and Similarities in Software Development", 2021)

"The systematic application of engineering approaches to the development of software." (Jan Bosch et al, "Engineering AI Systems: A Research Agenda", 2021)

"It is the establishment and use of robust, targeted engineering principles to obtain economic, reliable, efficient software that satisfies the user needs." (Mirna Muñoz, "Boosting the Competitiveness of Organizations With the Use of Software Engineering", 2021)

"The application of engineering to the development of software in a systematic method." (Kamalendu Pal & Bill Karakostas, "Software Testing Under Agile, Scrum, and DevOps", 2021)

"The application and the study of systematic, disciplined, quantifiable approaches to the development, operation, and maintenance of software." (IEEE 610.12)

Laurent Bossavit - Collected Quotes

"A lot of research in software engineering strikes me as hopelessly naive in one of two ways. Most of it fails entirely to account for the social and belief aspects altogether. It looks at its object of inquiry as if it was entirely material and inert; as if 'software' was some kind of naturally occurring substance, the properties of which can be revealed in the equivalent of a test tube." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"As practitioners, it is both in our interest and within our responsibility to pay attention to research. This includes not just the findings of such research, but also its processes and its institutions. Read research papers; find out what’s happening in that world and why it’s not more relevant to your work; weigh in; make your voice heard." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"As software professionals, we should be interested in knowing at least the basics of our own history, for just the same reasons that as citizens we are expected to know about our national history and about world history: so that we will be able to make informed decisions and know who to trust, who to listen to; so that we are not deceived by lies. Untrue histories generally have an agenda - 'someone trying to sell you something', as the saying goes." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"But 'average cost to fix one defect' is a stupid metric […] It makes bad projects look good, and good projects look bad. How? By failing to divide the costs of fixing into two categories: fixed costs of detecting and fixing defects - costs which are the same no matter how buggy or how good the product is - and variable costs, those which you pay for each defect." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"But if you want to count defects, you first have to decide what (literally) counts as one. We have a hard time even agreeing among a single team on what counts as a defect - in fact I’m pretty sure my own thinking has changed over the years, so I’m not even agreeing with myself." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"But we have now reached the most pressing problem in software engineering: low standards for research publications. Most of what passes for 'research' in the discipline is ridiculously careless with respect to examining the 'terms of inquiry'." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"Creating mockups to communicate is not intrinsically a bad idea. But, as we are subject to confirmation bias, there’s always a risk that we will stop at our first design attempt and become reluctant to ask if there are better ways to achieve the same goals. Making these first ideas very detailed; putting them into a document; and especially blessing that document with the label 'requirements' are all moves which make further revision less likely, and put us more at risk from confirmation bias." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"Debugging is known as an open-ended sort of activity, and even seasoned programmers expect variable completion times when  faced with this type of task."  (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"I do not dispute that there are large variations in reported measurements of programmer productivity; however, close examination of the evidence suggests that this observed variability originates in vague definitions of the term, in unreliable instruments of measurement, or in uncontrolled environmental factors, much more than it does in the intrinsic capabilities of programmers at comparable levels of training and experience." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"If a picture is worth a thousand words, a false picture is a thousand times more serious than one careless word." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"Often, the hard work in research isn’t in performing the experiment and collecting data (that tends to be grunt work, in fact, in most disciplines). The hard work consists of designing the experiment that will rule out the most alternative explanations for what you see happening (or think you see happening)." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"Science journalism is a fine and important thing, but it has a well-known failure mode: sensationalism, where the lure of an attention-grabbing headline causes writers to toss caution to the wind and radically misrepresent a claim." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"Software development […] needs to be studied with tools that borrow as much from the social and cognitive sciences as they do from the mathematical theories of computation." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"Software engineering is a social process, not a naturally occurring one- it therefore has the property that what we believe about software engineering has causal impacts on what is real about software engineering." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"The problem is that we cannot infer variations in individual productivity from data collected at the team level: we do not have an adequate theory of how a team’s productivity results from the aggregation of individual abilities, and in particular we cannot assume that a team’s output is a linear sum of individual 'productivities'." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"The problem, as we know, is that projects are very different from each other: there are big projects and large projects, there are projects with lots of defects and projects with… even greater numbers of defects. How do we make these comparable with each other?" (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"The wonderful thing about over-precise statistics is that they are the easiest to expose as being Leprechauns, as you can trace their spread from one dubious source to another." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"We cannot leave this enterprise to academia: that system’s inertia is too great. I believe that many of us will have to become scientists, and study software development even as we practice it." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"When looking at a graph or chart, purported to be backed by empirical data, remember to ask: what specific measurement does each of the points I’m looking at represent? If the picture is a curve, and it has many more data points than were actually measured, ask: was the method for interpolating the missing points actually valid?" (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

Ian Sommerville - Collected Quotes

"A feasibility study is a short, focused study that should take place early in the RE process. It should answer three key questions: a) does the system contribute to the overall objectives of the organization? b) can the system be implemented within schedule and budget using current technology? and c) can the system be integrated with other systems that are used? If the answer to any of these questions is no, you should probably not go ahead with the project." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"A model is an abstraction of the system being studied rather than an alternative representation of that system. Ideally, a representation of a system should maintain all the information about the entity being represented. An abstraction deliberately simplifies and picks out the most salient characteristics." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Agile approaches to software development consider design and implementation to be the central activities in the software process. They incorporate other activities, such as requirements elicitation and testing, into design and implementation. By contrast, a plan-driven approach to software engineering identifies separate stages in the software process with outputs associated with each stage." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Agile methods universally rely on an incremental approach to software specification, development, and delivery. They are best suited to application development where the system requirements usually change rapidly during the development process. They are intended to deliver working software quickly to customers, who can then propose new and changed requirements to be included in later iterations of the system. They aim to cut down on process bureaucracy by avoiding work that has dubious long-term value and eliminating documentation that will probably never be used." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Computer science is concerned with the theories and methods that underlie computers and software systems, whereas software engineering is concerned with the practical problems of producing software. Some knowledge of computer science is essential for software engineers in the same way that some knowledge of physics is essential for electrical engineers. Computer science theory, however, is often most applicable to relatively small programs. Elegant theories of computer science cannot always be applied to large, complex problems that require a software solution." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Design patterns are high-level abstractions that document successful design solutions. They are fundamental to design reuse in object-oriented development." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"In general, software engineers adopt a systematic and organized approach to their work, as this is often the most effective way to produce high-quality software. However, engineering is all about selecting the most appropriate method for a set of circumstances so a more creative, less formal approach to development may be effective in some circumstances. Less formal development is particularly appropriate for the development of web-based systems, which requires a blend of software and graphical design skills." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Models are used during the requirements engineering process to help derive the requirements for a system, during the design process to describe the system to engineers implementing the system and after implementation to document the system’s structure and operation." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Most designers think of design patterns as a way of supporting object-oriented design. Patterns often rely on object characteristics such as inheritance and polymorphism to provide generality. However, the general principle of encapsulating experience in a pattern is one that is equally applicable to all software design approaches." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Programming is a personal activity and there is no general process that is usually followed. Some programmers start with components that they understand, develop these, and then move on to less-understood components. Others take the opposite approach, leaving familiar components till last because they know how to develop them. Some developers like to define data early in the process then use this to drive the program development; others leave data unspecified for as long as possible." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Software systems do not exist in isolation. They are used in a social and organizational context and software system requirements may be derived or constrained by that context. Satisfying these social and organizational requirements is often critical for the success of the system. One reason why many software systems are delivered but never used is that their requirements do not take proper account of how the social and organizational context affects the practical operation of the system."(Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"System engineering is concerned with all aspects of the development and evolution of complex systems where software plays a major role. System engineering is therefore concerned with hardware development, policy and process design and system deployment, as well as software engineering. System engineers are involved in specifying the system, defining its overall architecture, and then integrating the different parts to create the finished system. They are less concerned with the engineering of the system components (hardware, software, etc.)." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

Titus Winters - Collected Quotes

"A boat without a captain is nothing more than a floating waiting room: unless someone grabs the rudder and starts the engine, it’s just going to drift along aimlessly with the current. A piece of software is just like that boat: if no one pilots it, you’re left with a group of engineers burning up valuable time, just sitting around waiting for something to happen (or worse, still writing code that you don’t need)." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Code coverage can provide some insight into untested code, but it is not a substitute for thinking critically about how well your system is tested." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Fixing a bug is much like adding a new feature: the presence of the bug suggests that a case was missing from the initial test suite, and the bug fix should include that missing test case." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"[...] do not underestimate the power of playing the social game. It’s not about tricking or manipulating people; it’s about creating relationships to get things done. Relationships always outlast projects. When you’ve got richer relationships with your coworkers, they’ll be more willing to go the extra mile when you need them." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Given enough time and enough users, even the most innocuous change will break something; your analysis of the value of that change must incorporate the difficulty in investigating, identifying, and resolving those breakages." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"In a professional software engineering environment, criticism is almost never personal - it’s usually just part of the process of making a better project. The trick is to make sure you (and those around you) understand the difference between a constructive criticism of someone’s creative output and a flat-out assault against someone’s character." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"In addition to developing the proper culture, invest in your testing infrastructure by developing linters, documentation, or other assistance that makes it more difficult to write bad tests." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"In short, performance ratings are indicative only of how a person is performing in their given role at the time they are being evaluated. Ratings, although an important way to measure performance during a specific period, are not predictive of future performance and should not be used to gauge readiness for a future role or qualify an internal candidate for a different team. (They can, however, be used to evaluate whether an employee is properly or improperly slotted on their current team; therefore, they can provide an opportunity to evaluate how to better support an internal candidate moving forward.)" (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Knowledge is in some ways the most important (though intangible) capital of a software engineering organization, and sharing of that knowledge is crucial for making an organization resilient and redundant in the face of change. A culture that promotes open and honest knowledge sharing distributes that knowledge efficiently across the organization and allows that organization to scale over time. In most cases, investments into easier knowledge sharing reap manyfold dividends over the life of a company." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Making good engineering decisions is all about weighing all of the available inputs and making informed decisions about the trade-offs. Sometimes, those decisions are based on instinct or accepted best practice, but only after we have exhausted approaches that try to measure or estimate the true underlying costs." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"One of the broad truths we’ve seen to be true is the idea that finding problems earlier in the developer workflow usually reduces costs." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"People are inherently imperfect - we like to say that humans are mostly a collection of intermittent bugs. But before you can understand the bugs in your coworkers, you need to understand the bugs in yourself. We’re going to ask you to think about your own reactions, behaviors, and attitudes - and in return, we hope you gain some real insight into how to become a more efficient and successful software engineer who spends less energy dealing with people-related problems and more time writing great code." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Programming is the immediate act of producing code. Software engineering is the set of policies, practices, and tools that are necessary to make that code useful for as long as it needs to be used and allowing collaboration across a team." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"This is what good management is about: 95% observation and listening, and 5% making critical adjustments in just the right place." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"When an engineer refactors the internals of a system without modifying its interface, whether for performance, clarity, or any other reason, the system’s tests shouldn’t need to change. The role of tests in this case is to ensure that the refactoring didn’t change the system’s behavior. Tests that need to be changed during a refactoring indicate that either the change is affecting the system’s behavior and isn’t a pure refactoring, or that the tests were not written at an appropriate level of abstraction." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

Edmond Lau - Collected Quotes

"A work environment that iterates quickly provides a faster feedback cycle and enables you to learn at a faster rate. Lengthy release cycles, formalized product approvals, and indecisive leadership slow down iteration speed; automation tools, lightweight approval processes, and a willingness to experiment accelerate progress." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Adopting a mindset of instrumentation means ensuring we have a set of dashboards that surface key health metrics and that enable us to drill down to the relevant data. However, many of the questions we want to answer tend to be exploratory, since we often don’t know everything that we want to measure ahead of time. Therefore, we need to build flexible tools and abstractions that make it easy to track additional metrics." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"At fast-growing teams and companies, the number of problems to solve exceeds available resources, providing ample opportunities to make a big impact and to increase your responsibilities. The growth also makes it easier to attract strong talent and build a strong team, which feeds back to generate even more growth. A lack of growth, on the other hand, leads to stagnation and politics. Employees might squabble over limited opportunities, and it becomes harder to find and retain talent." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Because we spend so much of our time at work, one of the most powerful leverage points for increasing our learning rate is our choice of work environment." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"But like many other aspects of code quality, building an abstraction for a problem comes with tradeoffs. Building a generalized solution takes more time than building one specific to a given problem. To break even, the time saved by the abstraction for future engineers needs to outweigh the time invested." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Continuous deployment is but one of many powerful tools at your disposal for increasing iteration speed. Other options include investing in time-saving tools, improving your debugging loops, mastering your programming workflows, and, more generally, removing any bottlenecks that you identify." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Developing the skills to automate takes time, whether they be using shell scripts, browser extensions, or something else. But the cost of mastering these skills gets smaller the more often you do it and the better you get at it." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Fine-tuning the efficiency of simple actions and saving a second here or there may not seem worth it at first glance. It requires an upfront investment, and you’ll very likely be slower the first few times you try out a new and unfamiliar workflow. But consider that you’ll repeat those actions at least tens of thousands of times during your career: minor improvements easily compound over time." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Good metrics accomplish a number of goals. First, they help you focus on the right things. […] Second, when visualized over time, good metrics help guard against future regressions. […] Third, good metrics can drive forward progress. […] Fourth, a good metric lets you measure your effectiveness over time and compare the leverage of what you’re doing against other activities you could be doing instead." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"How can we reduce integration risk? One effective strategy is to build end-to-end scaffolding and do system testing earlier. Stub out incomplete functions and modules, and assemble an end-to-end system as soon as possible, even if it’s only partly functional. Front-loading the integration work provides a number of benefits. First, it forces you to think more about the necessary glue between different pieces and how they interact, which can help refine the integration estimates and reduce project risk. Second, if something breaks the end-to-end system during development, you can identify and fix it along the way, while dealing with much less code complexity, rather than scrambling to tackle it at the end. Third, it amortizes the cost of integration throughout the development process, which helps build a stronger awareness of how much integration work is actually left." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"In any engineering discipline (and in life), there will always be more tasks to do than you have time for. Working on one task means not working on another. Therefore, regular prioritization is a high-leverage activity, because it determines the leverage of the rest of your time." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"It’s wishful thinking to believe that all the code we write will be bug-free and work the first time. In actuality, much of our engineering time is spent either debugging issues or validating that what we’re building behaves as expected. The sooner we internalize this reality, the sooner we will start to consciously invest in our iteration speed in debugging and validation loops." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Many of us are familiar with the concept of a minimal, reproducible test case. This refers to the simplest possible test case that exercises a bug or demonstrates a problem. A minimal, reproducible test case removes all unnecessary distractions so that more time and energy can be spent on the core issue, and it creates a tight feedback loop so that we can iterate quickly." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Project estimation and project planning are extremely difficult to get right, and many engineers (myself included) have learned this the hard way. The only way to get better is by practicing these concepts, especially on smaller projects where the cost of poor estimations is lower. The larger the project, the higher the risks, and the more leverage that good project planning and estimation skills will have on your success." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Project estimation is one of the hardest skills that an effective engineer needs to learn. But it’s crucial to master: businesses need accurate estimates to make long-term plans for their products. They need to know when resources might free up to work on upcoming features or when they can promise feature requests to customers. And even when we don’t have pressure to ship against a deadline, how long we think a project will take affects our decisions of what to work on." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Projects fail from under-communicating, not over-communicating. Even if resource constraints preclude the dependency that you want from being delivered any sooner, clarifying priorities and expectations enables you to plan ahead and work through alternatives." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Sometimes, we build things in a way that makes sense in the short-term but that can be costly in the long-term. We work around design guidelines because it’s faster and easier than following them. We punt on writing test cases for a new feature because there’s too much work to finish before the deadline. We copy, paste, and tweak small chunks of existing code instead of refactoring it to support our use cases. Each of these tradeoffs, whether they’re made from laziness or out of a conscious decision to ship sooner, can increase the amount of technical debt in our codebase." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"To be effective engineers, we need to be able to identify which activities produce more impact with smaller time investments. Not all work is created equal. Not all efforts, however well-intentioned, translate into impact." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"The best strategy for optimizing your iteration speed is the same as for optimizing the performance of any system: identify the biggest bottlenecks, and figure out how to eliminate them. What makes this difficult is that while tools, debugging workflows, and programming environments might be the areas most directly under your control as an engineer, sometimes they’re not the only bottlenecks slowing you down." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"The faster that you can iterate, the more that you can learn about what works and what doesn’t work. You can build more things and try out more ideas. Not every change will produce positive value and growth, of course." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"[…] the first heuristic for prioritizing high-leverage activities is to focus on what directly produces value. At the end of the day (or when it comes time for performance reviews), what matters is how much value you’ve created. […] the first heuristic for prioritizing high-leverage activities is to focus on what directly produces value. At the end of the day (or when it comes time for performance reviews), what matters is how much value you’ve created." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"The freedom to choose what to work on and how to do it drives our ability to learn—as long as we have the support that we need to use that freedom effectively. At established companies, employees tend to work on specialized projects, but they also have access to more coaching and structure. At smaller companies, you’ll end up wielding significantly more autonomy over the total surface area of product features and responsibilities, but you’ll also need to take more ownership of your own learning and growth." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"The next time you find yourself repeatedly going through the same motions when you’re fixing a bug or iterating on a feature, pause. Take a moment to think through whether you might be able to tighten that testing loop. It could save you time in the long run." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"To invest in your own growth, you should carve out your own 20% time. It’s more effective to take it in one- or two-hour chunks each day rather than in one full day each week, because you can then make a daily habit out of improving your skills. Your productivity may decrease at first (or it might not change much if you’re taking time away from web surfing or other distractions), but the goal is to make investments that will make you more effective in the long run." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Ultimately, software quality boils down to a matter of tradeoffs, and there’s no one universal rule for how to do things. […] Rigidly adhering to a notion of building something 'the right way' can paralyze discussions about tradeoffs and other viable options. Pragmatism - thinking in terms of what does and doesn’t work for achieving our goals - is a more effective lens through which to reason about quality." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"When establishing our goals, it’s important to choose carefully what core metrics to measure (or not measure) and optimize. When it comes to day-to-day operations, however, you should be less discriminatory: measure and instrument as much as possible. Although these two principles may seem contradictory, they actually complement each other. The first describes a high-level, big-picture activity, whereas the second is about gaining insight into what’s going on with systems that we’ve built." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"When you write to teach other people, you gain a deeper understanding of ideas you’re already familiar with and pinpoint the details that you didn’t fully understand." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015) 

"Why is continuous deployment such a powerful tool? Fundamentally, it allows engineers to make and deploy small, incremental changes rather than the larger, batched changes typical at other companies. That shift in approach eliminates a significant amount of overhead associated with traditional release processes, making it easier to reason about changes and enabling engineers to iterate much more quickly." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

Barry W Boehm - Collected Quotes

"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, "Software Engineering Economics", 1981)

"If we look at the discipline of software engineering, we see that the microeconomics branch of economics deals more with the types of decisions we need to make as software engineers or managers." (Barry Boehm, "Software Engineering Economics", 1981)

"Poor management can increase software costs more rapidly than any other factor. Particularly on large projects, each of the following mismanagement actions has often been responsible for doubling software development costs." (Barry Boehm, "Software Engineering Economics", 1981)

"Software Engineering Economics is an invaluable guide to determining software costs, applying the fundamental concepts of microeconomics to software engineering, and utilizing economic analysis in software engineering decision making." Barry Boehm, "Software Engineering Economics", 1981)

"Throughout the software life cycle, there are many decision situations involving limited resources in which software engineering economics techniques provide useful assistance." (Barry Boehm, "Software Engineering Economics", 1984)

"An important feature of the spiral model, as with most other models, is that each cycle is completed by a review involving the primary people or organizations concerned with the product. This review covers all products developed during the previous cycle, including the plans for the next cycle and the resources required to carry them out. The review's major objective is to ensure that all concerned parties are mutually committed to the approach for the next phase." (Barry Boehm, "A spiral model of software development and enhancement", IEEE, 1988)

"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, "A spiral model of software development and enhancement", IEEE, 1988)

"The primary functions of a software process model are to determine the order of the stages involved in software development and evolution and to establish the transition criteria for progressing from one Stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus, a process model addresses the following software project questions: (1) What shall we do next? (2) How long shall we continue to do it?" (Barry Boehm, "A spiral model of software development and enhancement", IEEE, 1988)

"If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process." (Barry Boehm, 1995)

"Success in all types of organization depends increasingly on the development of customized software solutions, yet more than half of software projects now in the works will exceed both their schedules and their budgets by more than 50%." (Barry Boehm, "Software Cost Estimation with Cocomo II", 2000)

"Agile development methodologies promise higher customer satisfaction, lower defect rates, faster development times and a solution to rapidly changing requirements. Plan-driven approaches promise predictability, stability, and high assurance. However, both approaches have shortcomings that, if left unaddressed, can lead to project failure. The challenge is to balance the two approaches to take advantage of their strengths and compensate for their weaknesses." (Barry Boehm & Richard Turner, "Observations on balancing discipline and agility", Agile Development Conference, 2003)

Software Engineering: Decision-Making (Just the Quotes)

"Engineering is a method and a philosophy for coping with that which is uncertain at the earliest possible moment and to the ultimate service to mankind. It is not a science struggling for a place in the sun. Engineering is extrapolation from existing knowledge rather than interpolation between known points. Because engineering is science in action - the practice of decision making at the earliest moment - it has been defined as the art of skillful approximation. No situation in engineering is simple enough to be solved precisely, and none worth evaluating is solved exactly. Never are there sufficient facts, sufficient time, or sufficient money for an exact solution, for if by chance there were, the answer would be of academic and not economic interest to society. These are the circumstances that make engineering so vital and so creative." (Ronald B Smith, "Engineering Is…", Mechanical Engineering Vol. 86 (5), 1964)

"Flow charts show the decision structure of a program, which is only one aspect of its structure. They show decision structure rather elegantly when the flow chart is on one page, but the overview breaks down badly when one has multiple pages, sewed together with numbered exits and connectors." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"By pulling together all of the decisions affecting the choice of modules and interrelationships in a system, we necessarily affect the way in which other decisions are organized and resolved. Thus, some issues which have traditionally been approached in a certain way during the earliest phase of a project may have to be dealt with in an entirely different manner at a much later stage once the designer graduates to a structured design approach." (Edward Yourdon & Larry L Constantine, "Structured Design: Fundamentals of a discipline of computer program and systems design", 1978)

"If we look at the discipline of software engineering, we see that the microeconomics branch of economics deals more with the types of decisions we need to make as software engineers or managers." (Barry Boehm, "Software Engineering Economics", 1981)

"Throughout the software life cycle, there are many decision situations involving limited resources in which software engineering economics techniques provide useful assistance."(Barry Boehm, "Software Engineering Economics", 1984)

"From time to time, a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100–200 lines. (A line is a noncomment, nonblank line of source code.) Decades of evidence say that routines of such length are no more error prone than shorter routines. Let issues such as the routine's cohesion, depth of nesting, number of variables, number of decision points, number of comments needed to explain the routine, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Inheritance is the idea that one class is a specialization of another class. The purpose of inheritance is to create simpler code by defining a base class that specifies common elements of two or more derived classes. The common elements can be routine interfaces, implementations, data members, or data types. Inheritance helps avoid the need to repeat code and data in multiple locations by centralizing it within a base class. When you decide to use inheritance, you have to make several decisions: For each member routine, will the routine be visible to derived classes? Will it have a default implementation? Will the default implementation be overridable? For each data member (including variables, named constants, enumerations, and so on), will the data member be visible to derived classes?" (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Executable UML is designed to produce a comprehensive and comprehensible model of a solution without making decisions about the organization of the software implementation. It is a highly abstract thinking tool to aid in the formalization of knowledge, a way of thinking about and describing the concepts that make up an abstract solution to a client problem." (Stephen J Mellor, "Executable UML: A Foundation for Model-Driven Architecture", 2002)

"The traditional view on software architecture suffers from a number of key problems that cannot be solved without changing our perspective on the notion of software architecture. These problems include the lack of first-class representation of design decisions, the fact that these design decisions are cross-cutting and intertwined, that these problems lead to high maintenance cost, because of which design rules and constraints are easily violated and obsolete design decisions are not removed." (Jan Bosch, "Software architecture: The next step", 2004)

"As a noun, design is the named (although sometimes unnamable) structure or behavior of a system whose presence resolves or contributes to the resolution of a force or forces on that system. A design thus represents one point in a potential decision space. A design may be singular (representing a leaf decision) or it may be collective (representing a set of other decisions). As a verb, design is the activity of making such decisions. Given a large set of forces, a relatively malleable set of materials, and a large landscape upon which to play, the resulting decision space may be large and complex. As such, there is a science associated with design (empirical analysis can point us to optimal regions or exact points in this design space) as well as an art (within the degrees of freedom that range beyond an empirical decision; there are opportunities for elegance, beauty, simplicity, novelty, and cleverness). All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." (Grady Booch, "On design", 2006)

"Successful information design in movement systems gives the user the information he needs - and only the information he needs - at every decision point." (Joel Katz, "Designing Information: Human factors and common sense in information design", 2012)

"A software architecture encompasses the significant decisions about the organization of the software system, the selection of structural elements and interfaces by which the system is composed, and determines their behavior through collaboration among these elements and their composition into progressively larger subsystems. Hence, the software architecture provides the skeleton of a system around which all other aspects of a system revolve." (Muhammad A Babar et al, "Agile Software Architecture Aligning Agile Processes and Software Architectures", 2014)

"As software professionals, we should be interested in knowing at least the basics of our own history, for just the same reasons that as citizens we are expected to know about our national history and about world history: so that we will be able to make informed decisions and know who to trust, who to listen to; so that we are not deceived by lies. Untrue histories generally have an agenda - 'someone trying to sell you something', as the saying goes." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"DevOps recognizes the importance of culture. The acronym CAMS (culture, automation, measurement, and sharing) is used to encapsulate its key themes. Culture is acknowledged as all important in making development and IT operations work together effectively. But what is culture in this context? It is not so much about an informal dress code, flexible hours, or a free in-house cafeteria as it is about how decisions are taken, norms of behavior, protocols of communication, and the ways of navigating hierarchy and bureaucracy to get things done." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Making good engineering decisions is all about weighing all of the available inputs and making informed decisions about the trade-offs. Sometimes, those decisions are based on instinct or accepted best practice, but only after we have exhausted approaches that try to measure or estimate the true underlying costs." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Great engineering managers find ways to give work meaning and make that meaning broadly understood. They align the realities of the engineering work they are tasked with to the aspirations and beliefs of their team members. [...] For your engineers, translating the why in a way they can understand and accept is a powerful tool for alignment and guiding decisions in the direction you want. [...] Translating outside of your team and upward to leadership (managing up) is oftentimes the most impactful translation of all." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"Systems architecture is the portion of any project over which the engineering team has the most control. This design is usually less of a collaboration between different functions and more clearly in the domain of engineers. As such, engineering managers have a high responsibility to own this process and its decisions. To produce the best decisions possible, you must have the right decision-building blocks: complete information to work from and a structured methodology to guide you." (Morgan Evans, "Engineering Manager's Handbook", 2023)

Book Review: Laurent Bossavit's The Leprechauns of Software Engineering (2015)

	Software Engineering should be the "establishment and use of sound engineering principles to obtain economically software that is reliable and works on real machines efficiently" [2]. Working for more than 20 years in the field I feel sometimes that its foundation is a strange mix of sound and questionable ideas that take the form of methodologies, principles, standards, myths, folklore, statistics and other similar concepts that form its backbone. I tend to look with critical eyes at the important numbers advanced in research and pseudo-scientific papers especially when they’re related to my job, this because I know that statistics are seldom what they appear to be - there are accidental and sometimes even intended errors made to support the facts. Unfortunately, the missing row data and often the information about the methodologies used in collecting and processing the respective data make numbers and/or graphics' understanding more challenging, not to mention the considerable amount of effort and time spent to uncover the evidence trail.
Fortunately, there are other professionals who went further down the path of bibliographical references and shared their findings in blogs, papers, books and other media content. It’s also the case of Laurent Bossavit, who in his book, "The Leprechauns of Software Engineering" (2015), looks behind some of the numbers that over time become part of the leprechaunish folklore of IT professionals, puts them into the historical context and provides in appendix the evidence trails for the reader to validate his findings. Over several chapters the author focuses mainly on the cost of defects, Boehm’s cone of uncertainty, the differences in productivity amount individual programmers (aka 10x claim), respectively the relation between poor requirements and defects. His most important finding is that the references used in most of the researched sources advancing the above numbers were secondary, while the actual sources provide no direct information of empirical data or the methodology for its collection. The way the numbers are advanced and used makes one question the validity of the measurements performed, respectively the character of the mistakes the authors made. Many of the cited papers hardly match the academic requirements of other scientific fields, being a mix of false claims, improperly conducted research and citations. Secondly, he argues that the small sample sizes used as basis for the experiments, the small population formed usually of students, respectively the way numbers were mixed without any reliable scientific character makes him (and the reader as well) question even more how the experiments were performed in the respective papers. With this, it is more likely that a bigger number of research based on these sources should raise further concerns. The reader can thus ask himself/herself how deep the domino effect goes inside of the Software Engineering field. In author’s opinion Software Engineering as social process "needs to be studied with tools that borrow as much from the social and cognitive sciences as they do from the mathematical theories of computation". How much is possible to extend the theories and models of the respective fields is an open topic. The bottom line, the field of Software Engineering needs better and scientific empirical experiments that are based on commonly agreed definitions, data collection and processing techniques, respectively higher standards for research publications. Without this, we’ll continue to compare apples with peaches and mix them in calculations so we can get some stories that support our leprechaunish theories. Overall, the book is a good read for software engineers as well as for other IT professionals. Even if it barely scratched the surface of software myths and folklore, there’s enough material for the readers who want to dive deeper. Previous Post <<||>> Next Post References: [1] Laurent Bossavit (2015) "The Leprechauns of Software Engineering" [2] Friedrich Bauer (1972) "Software Engineering", Information Processing

Software Engineering: Software Development (Just the Quotes)

"Far be it from me to suggest that all changes in customer objectives and requirements must, can, or should be incorporated in the design. Clearly a threshold has to be established, and it must get higher and higher as development proceeds, or no product ever appears." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"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, "Software Engineering Economics", 1981)

"Poor management can increase software costs more rapidly than any other factor. Particularly on large projects, each of the following mismanagement actions has often been responsible for doubling software development costs." (Barry Boehm, "Software Engineering Economics", 1981)

"The primary functions of a software process model are to determine the order of the stages involved in software development and evolution and to establish the transition criteria for progressing from one Stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus, a process model addresses the following software project questions: (1) What shall we do next? (2) How long shall we continue to do it?" (Barry Boehm, "A spiral model of software development and enhancement", IEEE, 1988)

"Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equivalent of a sound bite that describes the system's architecture). [A] step in [the] development process is to articulate this architectural framework, so that we might have a stable foundation upon which to evolve the system's function points." (Grady Booch, "Object-Oriented Design: with Applications", 1991)

"Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don't improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don't buy a new scale; change your diet. If you want to improve your software, don't test more; develop better." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction", 1993)

"If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process." (Barry Boehm, 1995)

"Successful software development is a team effort - not just the development team, but the larger team consisting of customer, management and developers. [...] Every software project needs to deliver business value. To be successful, the team needs to build the right things, in the right order, and to be sure that what they build actually works." (Ron Jeffries, "Extreme Programming Installed", 2001)

"Agile development methodologies promise higher customer satisfaction, lower defect rates, faster development times and a solution to rapidly changing requirements. Plan-driven approaches promise predictability, stability, and high assurance. However, both approaches have shortcomings that, if left unaddressed, can lead to project failure. The challenge is to balance the two approaches to take advantage of their strengths and compensate for their weaknesses." (Barry Boehm & Richard Turner, "Observations on balancing discipline and agility", Agile Development Conference, 2003)

"Computer programming is tremendous fun. Like music, it is a skill that derives from an unknown blend of innate talent and constant practice. Like drawing, it can be shaped to a variety of ends – commercial, artistic, and pure entertainment. Programmers have a well-deserved reputation for working long hours, but are rarely credited with being driven by creative fevers. Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination, but because their imagination reveals worlds that others cannot see." (Larry O'Brien & Bruce Eckel, "Thinking in C#", 2003)

"Design patterns give names to practical knowledge; they define a high-level vocabulary for understanding and solving business statements graphically. Design patterns are presented in a standard format; they're like recipes in a cookbook or dress patterns in a catalog. Above all, they are practical, first as instructional materials and then as development tools." (Alan Chmura & J Mark Heumann, "Logical Data Modeling: What it is and How to do it", 2005)

"Developing fewer features allows you to conserve development resources and spend more time refining those features that users really need. Fewer features mean fewer things to confuse users, less risk of user errors, less description and documentation, and therefore simpler Help content. Removing any one feature automatically increases the usability of the remaining ones." (Jakob Nielsen, "Prioritizing Web Usability", 2006)

"Communicating abstractions unambiguously - from programmer to machine, from programmer to programmer, and from program to user - is the single most challenging demand of software development." (Scott Rosenberg, "Dreaming in Code", 2007)

"[…] in software development, as in all things, plans get dodgier the farther into the future one looks. Any developer who has been around the block will admit that the cavalcade of methodologies over three decades of software history has left the field richer and given programmers useful new tools and ways of thinking about their work. But finding a developer or team that actually subscribes to a particular methodology isn’t easy." (Scott Rosenberg, "Dreaming in Code", 2007)

"The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exist." (Grady Booch et al, "Object-Oriented Analysis and Design with Applications", 2007) 

"The picture of digital progress that so many ardent boosters paint ignores the painful record of actual programmers’ epic struggles to bend brittle code into functional shape. That record is of one disaster after another, marking the field’s historical time line like craters. Anyone contemplating the start of a big software development project today has to contend with this unfathomably discouraging burden of experience. It mocks any newcomer with ambitious plans, as if to say, What makes you think you’re any different?" (Scott Rosenberg, "Dreaming in Code", 2007)

"Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. […] Features have a documentation cost. Every feature adds pages to the manual increasing training costs." (Douglas Crockford, "JavaScript: The Good Parts: The Good Parts", 2008)

"It is a myth that we can get systems 'right the first time'. Instead, we should implement only today’s stories, then refactor and expand the system to implement new stories tomorrow. This is the essence of iterative and incremental agility. Test-driven development, refactoring, and the clean code they produce make this work at the code level." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"The use of rapid prototyping methodologies is to reduce the production time by using working models of the final product early in a project tends to eliminate time-consuming revisions later on, and by completing design tasks concurrently, rather than sequentially throughout the project. The steps are crunched together to reduce the amount of time needed to develop training or a product. The design and development phases are done simultaneously and the formative evaluation is done throughout the process." (Irene Chen, "Instructional Design Methodologies", 2008)

"Agile approaches to software development consider design and implementation to be the central activities in the software process. They incorporate other activities, such as requirements elicitation and testing, into design and implementation. By contrast, a plan-driven approach to software engineering identifies separate stages in the software process with outputs associated with each stage." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Agile methods universally rely on an incremental approach to software specification, development, and delivery. They are best suited to application development where the system requirements usually change rapidly during the development process. They are intended to deliver working software quickly to customers, who can then propose new and changed requirements to be included in later iterations of the system. They aim to cut down on process bureaucracy by avoiding work that has dubious long-term value and eliminating documentation that will probably never be used." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Software development is a marathon, not a sprint. You can’t win the race by trying to run as fast as you can from the outset. You win by conserving your resources and pacing yourself. A marathon runner takes care of her body both before and during the race. Professional programmers conserve their energy and creativity with the same care." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011) 

"System engineering is concerned with all aspects of the development and evolution of complex systems where software plays a major role. System engineering is therefore concerned with hardware development, policy and process design and system deployment, as well as software engineering. System engineers are involved in specifying the system, defining its overall architecture, and then integrating the different parts to create the finished system. They are less concerned with the engineering of the system components (hardware, software, etc.)." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"A value stream is a series of activities required to deliver an outcome. The software development value stream may be described as: validate business case, analyze, design, build, test, deploy, learn from usage analytics and other feedback - rinse and repeat." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Development is a design process. Design processes are generally evaluated by the value they deliver rather than a conformance to plan. Therefore, it makes sense to move away from plan-driven projects and toward value-driven projects. […] The realization that the source code is part of the design, not the product, fundamentally rewires our understanding of software." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"DevOps recognizes the importance of culture. The acronym CAMS (culture, automation, measurement, and sharing) is used to encapsulate its key themes. Culture is acknowledged as all important in making development and IT operations work together effectively. But what is culture in this context? It is not so much about an informal dress code, flexible hours, or a free in-house cafeteria as it is about how decisions are taken, norms of behavior, protocols of communication, and the ways of navigating hierarchy and bureaucracy to get things done." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Feedback is what makes it iterative; otherwise, it is just mini-waterfall. Merely splitting use cases into stories does not make for iterative development if we wait until all stories are developed before we seek feedback. The point of splitting is to get feedback faster so that it can be incorporated into ongoing development. However, seeking stakeholder/user feedback for small batches of functionality (stories) is often not feasible with formal stage-gate processes. They were conceived with linear flows of large batches in mind." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"A key contribution of DevOps was to raise awareness of the problems lingering in how teams interacted (or not) across the delivery chain, causing delays, rework, failures, and a lack of understanding and empathy toward other teams. It also became clear that such issues were not only happening between application development and operations teams but in interactions with many other teams involved in software delivery, like QA, InfoSec, networking, and more." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

Software Engineering: eXtreme Programming (Definitions)

"A disciplined and deliberate agile development method that focuses on the critical activities required to build software." (Pramod J Sadalage & Scott W Ambler, "Refactoring Databases: Evolutionary Database Design", 2006)

"An agile process created by Kent Beck. XP articulates five values to guide you in your project: Communication, Simplicity, Feedback, Courage, and Respect." (Bruce MacIsaac & Per Kroll, "Agility and Discipline Made Easy: Practices from OpenUP and RUP", 2006)

"An agile software development approach championed by Kent Beck and others." (Bruce P Douglass, "Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development", 2009)

"A software engineering methodology that promotes agility and simplicity, typically involving pair programming and a cycle of frequent testing and feedback." (Mark S Merkow & Lakshmikanth Raghavan, "Secure and Resilient Software Development", 2010)

 "A development approach that focuses on building projects incrementally using frequent builds. It includes techniques such as coding to the specific problem rather than a general one, paired programming, and test-driven development." (Rod Stephens, "Start Here! Fundamentals of Microsoft® .NET Programming", 2011)

"A software engineering methodology used within agile software development whereby core practices are programming in pairs, doing extensive code review, unit testing of all code, and simplicity and clarity in code. See also Agile software development." (Requirements Engineering Qualifications Board, "Standard glossary of terms used in Requirements Engineering", 2011)

"An updated approach to Rapid Application Development using object-oriented techniques and a minimum of specifications." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A lightweight agile software engineering methodology used whereby a core practice is test-first programming." (Tilo Linz et al, "Software Testing Foundations, 4th Ed", 2014)

"A development model that takes typical programming practices (such as code reviews) to extremes (pair programming)." (Rod Stephens, "Beginning Software Engineering", 2015)

"An engineering methodology consisting of code-focused practices to ensure high quality of development." (Fayez Salma & Jorge M Gómez, "Challenges and Trends of Agile", 2021)

"A software engineering methodology used within agile software development whereby core practices are programming in pairs, doing extensive code review, unit testing of all code, and simplicity and clarity in code. See also agile software development." (IQBBA)

Software Engineering: Design Pattern (Definition)

"A design pattern is a reusable solution for a software design problem. Patterns are platform independent, the same pattern can be used in different environments." (Jens Dietrich, "From Business Rules to Application Code: Code Generation Patterns for Rule Defined Associations", 2009)

"A way of representing a contextualized solution to a design problem with sufficient precision and explanation that it is an effective guide to action, but allowing scope for creative adaptation to specific needs." (Peter Goodyear & Dai F Yang, "Patterns and Pattern Languages in Educational Design", 2009)

"Common solutions to common problems, particularly in software design." (Tony C Shan & Winnie W Hua, "Data Caching Patterns" [in "Encyclopedia of Information Communication Technology"] 2009)

"Defines and explains systematically a general design to a recurrent problem of design in object oriented system." (Fuensanta Medina-Domínguez et al, "Patterns in the Field of Software Engineering" [in "Encyclopedia of Information Science and Technology" 2nd Ed.], 2009)

"Describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that one can use this solution a million times over without ever doing it the same way twice." (Franca Garzotto & Symeon Retalis, "A Critical Perspective on Design Patterns for E-Learning", 2009)

"Design patterns are standard solutions to common problems in software design." (Ghita K Mostéfaoui, "Software Engineering for Mobile Multimedia: A Roadmap", 2009)

"Design patterns represent solutions to problems that arise when developing software within a particular context. Design patterns capture the static and dynamic structure and collaboration among key participants in software designs. Design patterns are generic design pieces that need to be instantiated before uses." (Jing Dong et al, "Design Patterns from Theory to Practice" [in "Encyclopedia of Information Science and Technology" 2nd Ed.], 2009)

"Expressing the gist of a solution so that it can be reused many times. Defining a pattern, or a pattern system, is a way to capture the design knowledge of a community, to share it and to leverage it for future developments." (Eddy Boot et al, "Supporting Decision Making in Using Design Languages for Learning Designs and Learning Objects", 2009)

"In software engineering, it is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. [...] Design patterns deal specifically with problems at the level of software design." (Salvatore Scifo, "Accessing Grid Metadata through a Web Interface", 2009)

"A design pattern is a general, proven, and beneficial solution to a common, reoccurring problem in software design. Built upon similar experiences, design patterns represent 'best-practices' about how to structure or build a software architecture." (Jörg Rech et al, "Knowledge Patterns" [in "Encyclopedia of Knowledge Management" 2nd Ed.], 2011)

"A semi-formal way of documenting a solution to a design problem in a particular field of expertise." (Manuel Ecker et al, "Game-Based Learning Design Patterns: An Approach to Support the Development of 'Better' Educational Games", 2011)

"A well-tried solution to a common problem that captures experience and good practice in a form that can be reused. It is an abstract representation than can be instantiated in a number of ways." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"General solution for a common problem that occurs when designing software. A design pattern is reusable, so that it might be applied in many systems that suffer of a common problem." (Márcio Ribeiro et al, "Recommending Mechanisms for Modularizing Mobile Software Variabilities", 2012)

"[...] a design pattern [...] describes a solution to a 'typical' software design problem. A pattern provides a general template for a solution that can be applied in many different situations. It describes the main elements of a solution in an abstract way that can be specialized for a specific problem at hand." (Michael T Goodrichet al, "Data Structures and Algorithms in Python", 2013)

"A design pattern is an abstract description of best practice that has worked successfully in different systems and environments, and it acts as a reusable solution that may be used in many situations. It is more a description or template on how to solve the problem within a particular context, rather than a finished solution." (Gerard O’Regan, "Concise Guide to Software Engineering: From Fundamentals to Application Methods", 2017)

"Design patterns consists of shared guidelines helping design problems. Design patterns commonly used in software engineering and is also used in ontological engineering to solve common problems." (Galip Kaya & Arif Altun, "Educational Ontology Development" [in "Encyclopedia of Information Science and Technology" 4th Ed.], 2018)

Software Engineering: DevOps (Definitions)

"An application delivery philosophy that stresses communication, collaboration, and integration between software developers and their information technology (IT) counterparts in operations. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services." (Pierre Pureur & Murat Erder, "Continuous Architecture", 2015)

DevOps is an approach based on lean and agile principles in which business owners and the development, operations, and quality assurance departments collaborate to deliver software in a continuous manner that enables the business to more quickly seize market opportunities and reduce the time to include customer feedback. Indeed, enterprise (Sanjeev Sharma & Bernie Coyne, "DevOps For Dummies" 2nd Ed, 2015)

"Is a method for software development and management that integrates the development and deployment cycles to achieve a more agile, continuous evolution of software-based products and services" (Diego R López & Pedro A. Aranda, "Network Functions Virtualization: Going beyond the Carrier Cloud", 2015)

"DevOps is a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a Solution." (Dean Leffingwell, "SAFe 4.5 Reference Guide: Scaled Agile Framework for Lean Enterprises" 2nd Ed., 2018)

"Short for development operations, an information technology environment in which development and operations are tightly tied together, yielding small incremental releases to gain user feedback." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"The practice of incorporating developers and members of operations and quality assurance (QA) staff into software development projects to align their incentives and enable frequent, efficient, and reliable releases of software products." (Shon Harris & Fernando Maymi, "CISSP All-in-One Exam Guide" 8th Ed., 2018)

"The tighter integration between the developers of applications and the IT department that tests and deploys them. DevOps is said to be the intersection of software engineering, quality assurance, and operations." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"A software engineering practice that aims at unifying software development (Dev) and software operation (Ops)." (Jun Bi et al, "Automatic Address Scheduling and Management for Broadband IP Networks", Emerging Automation Techniques for the Future Internet, 2019)

"Develop operations, or DevOps, is an agile methodology that merges the functions of software development and operations in the enterprise software development domain. This approach has been adopted in the networking world to facilitate a programmable approach to network operations. Often when applied to networking the term is changed to NetOps." (Patrick Moore, "Model-Centric Fulfillment Operations and Maintenance Automation", Emerging Automation Techniques for the Future Internet, 2019)

"Practices and technologies that promote tighter coupling of software development (Dev) and operations (Ops) - typically marked by more automation, continuous monitoring, shorter development cycles and higher deployment frequencies. A key driver for security policy automation. DevSecOps is a related term that refers to practices and technologies that aim to embed security in DevOps practices." (Myo Zarny et al, "Network Security Policy Automation: Enterprise Use Cases and Methodologies", 2019)

"Development and operations is an abbreviation for 'development' and 'operations'; is a software engineering methodology for managing software development (Dev) and technology operations (Ops). The main aim of DevOps is to enable automation and tracing for all phases of software implementation, from integration, testing, releasing to deployment and infrastructure management." (Antoine Trad & Damir Kalpić, "Using Applied Mathematical Models for Business Transformation", 2020)

"Development and operations (DevOps) has been adopted by prominent software and service companies (e.g., IBM) to support enhanced collaboration across the company and its value chain partners. In this way, DevOps facilitates uninterrupted delivery and coexistence between development and operation facilities, enhances the quality and performance of software applications, improving end-user experience, and help to simultaneous deployment of software across different platforms." (Kamalendu Pal & Bill Karakostas, "Software Testing Under Agile, Scrum, and DevOps", 2021)

"DevOps is a sprint-based approach that can catch coding flaws during the development of code due to security reviews, rework on previous sprint cycles, and testing." (David A Bird, "Hacker and Non-Attributed State Actors", Real-Time and Retrospective Analyses of Cyber Security, 2021)

"It is a set of practices emerging to bridge the gaps between operation and developer teams to achieve a better collaboration." (Mirna Muñoz, "Boosting the Competitiveness of Organizations With the Use of Software Engineering", 2021)

"It is a way to work were the software is rapidly developed and immediately deployed for operating in a computational productive environment. It is continuous delivery product development lifecycle. It must automate the development process. DevOps is both a culture and a set of technologies and tools used for automation." Laura C Rodriguez-Martinez et al, "Service-Oriented Computing Applications (SOCA) Development Methodologies: A Review of Agility-Rigor Balance", 2021)

"People from software development and operations work together to enhance the speed of delivery of new software features. It is a concept for bridging the gap between software development and software operations and integrating the logic of common responsibility for the complete software delivery lifecycle into one cross-functional team." (Anna Wiedemann et al, "Transforming Disciplined IT Functions: Guidelines for DevOps Integration", 2021)

"DevOps is a set of tools and processes that help automate IT operations." (Aniruddha Deswandikar,"Engineering Data Mesh in Azure Cloud", 2024)

"DevOps is a catch‑all term for the blending of roles between developers and operations engineers. As the barriers between roles such as database administrator, systems administrator, and software engineer have eroded, the term DevOps has emerged as a way of describing the intersection of responsibilities from all these camps, and their increasing interrelation in the lifecycle of a product. A crucial enabling aspect of this movement is the increased use of automation in building, deploying, and monitoring large applications." (NGINX) [source]

"DevOps is a collection of best practices and working methods for the software development process whose cumulative goal is to shorten the development life cycle and support practice such as continuous integration, continuous delivery and continuous deployment." (Sum Logic) [source]

"DevOps is a set of practices that works to automate and integrate the processes between software development and IT teams, so they can build, test, and release software faster and more reliably." Atlassian [source] 

"DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes." (Amazon) [source]

"DevOps refers to a broad range of practices related to the development and operation of software code in production in cloud data centers. DevOps is centered in Agile project management techniques and microservice support. DevOps approaches the entire software development lifecycle with automation based around version control standards." (VMWare) [source]

"The cultural movement that stresses communication, collaboration and integration between software developers and IT operations." (Global Knowledge)