Modern Software Engineering - Farley Dave  ## Metadata - Author: **Farley Dave** - Full Title: Modern Software Engineering - Category: #books - Tags: #programming ## Highlights - Software development is a process of discovery and exploration; therefore, to succeed at it, software engineers need to become experts at learning. (Location 224) - To become experts at managing complexity, we need the following: Modularity Cohesion Separation of Concerns Abstraction Loose Coupling (Location 251) - Testability Deployability Speed Controlling the variables (Location 256) - The idea of paradigm shift was created by physicist Thomas Kuhn. Most learning is a kind of accretion. We build up layers of understanding, with each layer foundationally under-pinned by the previous one. However, not all learning is like that. Sometimes we fundamentally change our perspective on something, and that allows us to learn new things, but that also means we must discard what went before. (Location 312) - The next big step was to move to “stored programs” and their encoding. This was the era of paper tape and punched cards. The first steps on the adoption of this storage media for programs was still pretty hardcore. Programs were written in machine code and stored on tape, or card, before being fed into the machines. (Location 472) - To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge. (Location 497) - At the time of writing, most modern consumer-level computers operate on a clock cycle of around 3GHz. That is 3 billion cycles per second. Modern computers are multicore and operate on instructions in parallel, so often they process more than one instruction per cycle, but let us ignore that and imagine, for simplicity, that each machine instruction that moves values between registers, adds them or references some in-cache piece of memory, takes a single clock cycle. That is 3 billion operations per second. If we do the math and calculate how many instructions a modern computer can crunch through in the absolute minimum time that a human being could perceive any external event, that number is 39,000,000 instructions! (Location 504) - Tags: #computer-science - The art of programming is the art of organizing complexity. (Location 555) - They will measure the performance of their software to detect leaks before they become a problem. (Location 576) - Design engineering is a deeply exploratory approach to gaining knowledge. (Location 628) - If we make our system more secure, it will be more difficult to use; if we make it more distributed, we will spend more time integrating the information that it gathers. If we add more people to speed up development, we will increase the communication overhead, coupling, and complexity, all of which will slow us down. (Location 632) - Serverless is important for several reasons, but principally because it encourages a more modular approach to design with a better separation of concerns, particularly with respect to data. (Location 648) - The glide ratio is one measure of the efficiency of a flying machine. The ratio is between distance traveled and height lost. For example, for every foot (or meter) that the plane descends in a (unpowered) glide, it will move forward 8.3 feet (or meters). See (Location 680) - The individual languages are less important than the programming paradigm to my mind. (Location 731) - Recovery Failure Time: How long to recover from a failure at a particular point in the process (Location 760) - Lead Time : A measure of the efficiency of the development process. How long for a single-line change to go from “idea” to “working software”? (Location 765) - Frequency: A measure of speed. How often are changes deployed into production? (Location 766) - Working iteratively Employing fast, high-quality feedback Working incrementally Being experimental Being empirical (Location 817) - in continuous delivery we work so that every small change, multiple times per day, is releasable. It should be finished to the degree that we can safely and reliably release our software into production at any point. (Location 908) - Each change is finished because it is releasable, so the only sensible measure of “finished” is that it delivers some value to its users. (Location 910) - We need to do just enough analysis, design, coding, testing, and releasing to get our ideas out into the hands of our customers and users so that we can see what really works. (Location 944) - Without feedback, there is no opportunity to learn. We can only guess, rather than make decisions based on reality. (Location 1087) - Tags: #feedback - Feedback allows us to establish a source of evidence for our decisions. Once we have such a source, the quality of our decisions is, inevitably, improved. It allows us to begin to separate myth from reality. (Location 1092) - If my tests are hard to write, that tells me something important about the quality of my code. (Location 1203) - There are two effective routes: either you can work to build monolithic systems and optimize them for deployability and testability, or you can modularize them into separate, individually “deployable units.” This second approach is one of the driving ideas behind the popularity of microservices. (Location 1256) - More lines of code doesn’t mean better code; it probably means worse code. (Location 1302) - Ports & Adapters pattern.5 At any interface point between two components of the system that we want to decouple, a port, we define a separate piece of code to translate inputs and outputs, the adapter. This allows us more freedom to change the code behind the adapters without forcing change on other components that interact with it through this port. (Location 1453) - Complex systems don’t spring fully formed from the mind of some genius creator; they are the fruits of working through problems, deepening our understanding, and exploring ideas and potential solutions through sometimes hard work. (Location 1478) - Richard Feynman once said, science is “a satisfactory philosophy of ignorance.” (Location 1490) - If I separated the concerns of “something useful” from “storage,” then I may factionally increase my line count in code. I may have to think a tiny bit harder about how to establish that separation, but I have opened the door to incremental working and incremental decision-making. (Location 1504) - My goal is code that I can grow incrementally to fulfill its function as that function becomes clearer to me over time. (Location 1514) - Working in ways that allow us the freedom to change our code and change our minds as our understanding deepens is fundamental to good engineering and is what incrementalism is built upon. (Location 1515) - Unfortunately, this is a much more complex problem than it looks. For some unusual tasks, parallel execution is the answer. However, as soon as there is any need to bring the information from those different threads of execution back together again, the picture changes. (Location 1642) - There are estimates that the whole of human knowledge doubles every 13 months in our civilization. (Location 1684) - Have no respect whatsoever for authority; forget who said it and instead look what he starts with, where he ends up, and ask yourself, ‘Is it reasonable?’ (Location 1698) - Making no other change than improving the speed of the feedback gave the teams the tools that they needed to fix the underlying instability. (Location 1730) - The result is that high-performing teams that employ techniques like TDD, continuous integration, and continuous delivery spend 44 percent more time on useful work. (Location 1808) - These days when I begin a software project, I will establish a check in the continuous delivery deployment pipeline, in the “commit stage,” that does exactly this kind of test and rejects any commit that contains a method longer that 20 or 30 lines of code. (Location 1893) - We have arguments over IDEs versus text editors or object-oriented programming versus functional programming. Yet none of these things comes close to being as important, as foundational, as ideas like modularity or separation of concerns to the quality of our output. (Location 1906) - Any programming language is only a tool. I have been privileged to work with a few world-class programmers. These people will write good code in a programming language that they have never used before. (Location 1933) - If our tests are difficult to write, it means that our design is poor. (Location 1946) - You can’t make a baby in a month with 9 women. (Location 2152) - When you have independent streams of information, the cost of bringing them together to form a coherent whole can be extremely high if there is any overlap. (Location 2157) - The best way to parallelize things is to do it in a way where there is no need to re-integrate (nine babies). (Location 2158) - When I speak of modularity, I really mean components of the system that genuinely hide information from other components (Location 2190) - The discipline of TDD encourages us to hit the sweet spot for cohesion. (Location 2330) - Cohesion is the counter to modularity and primarily makes sense when considered in combination with modularity. One of the most effective tools to help us strike a good working balance between cohesion and modularity is separation of concerns. (Location 2397) - Separation of concerns is defined as “a design principle for separating a computer program into distinct sections such that each section addresses a separate concern.” (Location 2401) - dependency injection can help us improve our designs, but an even more powerful, maybe an even more fundamental, tool to help to establish an effective separation of concerns is testability. (Location 2579) - Professional programming isn’t about translating instructions from a human language into a programming language. Machines can do that.5 Professional programming is about creating solutions to problems, and code is the tool that we use to capture our solutions. (Location 3321) - In my professional life, I see many large organizations hamstrung by organizational coupling. They find it almost impossible to release any change into production, because over the years they have ignored the costs of coupling, and now making the smallest change involves tens, or hundreds, of people to coordinate their work. (Location 3330) - Continuous delivery is built on the idea of optimizing the feedback loops in development to the extent that we have, in essence, continuous feedback on the quality of our work. (Location 3335) - In continuous delivery we want the freedom to create new features over a series of deployments. So at this point I am going to switch from talking about releasability, which implies some feature completeness and utility to users, to deployability, which means that the software is safe to release into production, even if some features are not yet ready for use and are hidden in some way. (Location 3563) - Modularity, cohesion, and separation of concerns enhance our ability to gather feedback and so facilitate experimentation. (Location 3659)