Download to read offline
![Acknowledgments [This content is
currently in development.]
This content is currently in development.](https://image.slidesharecdn.com/18115440-250518122524-f474d65c/75/Modern-Software-Engineering-Doing-What-Works-To-Build-Better-Software-Faster-David-Farley-24-2048.jpg)
![If we work carefully to isolate the part of the system that we are interested
in, we can evaluate it in exactly the same environment that it will be
exposed to in production. So our experimental simulation can much more
precisely and much more accurately represent the “real world” of our
systems than in any other discipline.
In his excellent talk called “Real Software Engineering,”3 Glenn
Vanderburg says that in other disciplines “Engineering means stuff that
works” and that almost the opposite has become true for software.
3 https://youtu.be/RhdlBHHimeM
Vanderburg goes on to explore why this is the case. He describes an
academic approach to software engineering that was so onerous that almost
no one who had practiced it would recommend it for future projects.
It was heavyweight and added no significant value to the process of
software development at all. In a telling phrase, Vanderburg says:
[Academic software engineering] only worked because sharp people, who cared, were
willing to circumvent the process.
That is not engineering by any sensible definition.
Vanderburg’s description of “engineering as the stuff that works” is
important. If the practices that we choose to identify as “engineering” don’t
allow us to make better software faster, then they don’t qualify as
engineering!
Software development, unlike all physical production processes, is wholly
an exercise in discovery, learning, and design. Our problem is one of
exploration, and so we, even more than the spaceship designers, should be
applying the techniques of exploration rather than the techniques of
production engineering. Ours is solely a discipline of design engineering.
So if our understanding of engineering is often confused, what is
engineering really about?
The First Software Engineer](https://image.slidesharecdn.com/18115440-250518122524-f474d65c/75/Modern-Software-Engineering-Doing-What-Works-To-Build-Better-Software-Faster-David-Farley-41-2048.jpg)
![Acknowledgments [This content is
currently in development.]
This content is currently in development.](https://crownmelresort.com/image.slidesharecdn.com/18115440-250518122524-f474d65c/75/Modern-Software-Engineering-Doing-What-Works-To-Build-Better-Software-Faster-David-Farley-24-2048.jpg)
![If we work carefully to isolate the part of the system that we are interested
in, we can evaluate it in exactly the same environment that it will be
exposed to in production. So our experimental simulation can much more
precisely and much more accurately represent the “real world” of our
systems than in any other discipline.
In his excellent talk called “Real Software Engineering,”3 Glenn
Vanderburg says that in other disciplines “Engineering means stuff that
works” and that almost the opposite has become true for software.
3 https://youtu.be/RhdlBHHimeM
Vanderburg goes on to explore why this is the case. He describes an
academic approach to software engineering that was so onerous that almost
no one who had practiced it would recommend it for future projects.
It was heavyweight and added no significant value to the process of
software development at all. In a telling phrase, Vanderburg says:
[Academic software engineering] only worked because sharp people, who cared, were
willing to circumvent the process.
That is not engineering by any sensible definition.
Vanderburg’s description of “engineering as the stuff that works” is
important. If the practices that we choose to identify as “engineering” don’t
allow us to make better software faster, then they don’t qualify as
engineering!
Software development, unlike all physical production processes, is wholly
an exercise in discovery, learning, and design. Our problem is one of
exploration, and so we, even more than the spaceship designers, should be
applying the techniques of exploration rather than the techniques of
production engineering. Ours is solely a discipline of design engineering.
So if our understanding of engineering is often confused, what is
engineering really about?
The First Software Engineer](https://crownmelresort.com/image.slidesharecdn.com/18115440-250518122524-f474d65c/75/Modern-Software-Engineering-Doing-What-Works-To-Build-Better-Software-Faster-David-Farley-41-2048.jpg)
Modern Software Engineering Doing What Works To Build Better Software Faster David Farley
- 1. Modern Software EngineeringDoing What Works To Build Better Software Faster David Farley download https://ebookbell.com/product/modern-software-engineering-doing- what-works-to-build-better-software-faster-david-farley-36230880 Explore and download more ebooks at ebookbell.com
- 2. Here are somerecommended products that we believe you will be interested in. You can click the link to download. Modern Software Engineering Doing What Works To Build Better Software Faster David Farley https://ebookbell.com/product/modern-software-engineering-doing-what- works-to-build-better-software-faster-david-farley-50148934 Modern Software Engineering Doing What Works To Build Better Software Faster David Farley https://ebookbell.com/product/modern-software-engineering-doing-what- works-to-build-better-software-faster-david-farley-36433182 Modern Software Engineering Concepts And Practices Advanced Approaches Ali H Dogru https://ebookbell.com/product/modern-software-engineering-concepts- and-practices-advanced-approaches-ali-h-dogru-4148630 Modern Software Engineering Hogly Rubios Library David Farley https://ebookbell.com/product/modern-software-engineering-hogly- rubios-library-david-farley-232598526
- 3. Engineering Software ProductsAn Introduction To Modern Software Engineering 1st Edition Ian Sommerville https://ebookbell.com/product/engineering-software-products-an- introduction-to-modern-software-engineering-1st-edition-ian- sommerville-22682542 Engineering Software Products An Introduction To Modern Software Engineering Global Edition Ian Sommerville https://ebookbell.com/product/engineering-software-products-an- introduction-to-modern-software-engineering-global-edition-ian- sommerville-33960916 The Essentials Of Modern Software Engineering Free The Practices From The Method Prisons Ivar Jacobson https://ebookbell.com/product/the-essentials-of-modern-software- engineering-free-the-practices-from-the-method-prisons-ivar- jacobson-10664420 Software Engineering Education In The Modern Age Software Education And Training Sessions At The International Conference On Software Engineering Icse 2005 St Louis Mo Usa May 1521 2005 Revised Lectures 1st Edition Hans Van Vliet Auth https://ebookbell.com/product/software-engineering-education-in-the- modern-age-software-education-and-training-sessions-at-the- international-conference-on-software-engineering-icse-2005-st-louis- mo-usa-may-1521-2005-revised-lectures-1st-edition-hans-van-vliet- auth-1549570 Software Engineering Modern Approaches 2nd Edition Eric J Braude https://ebookbell.com/product/software-engineering-modern- approaches-2nd-edition-eric-j-braude-2100010
- 6. Modern Software Engineering DoingWhat Works to Build Better Software Faster David Farley
- 7. Contents Foreword Preface Acknowledgments About the Author PartI: What Is Software Engineering? 1. Introduction 2. What Is Engineering? 3. Fundamentals of an Engineering Approach Part II: Optimize for Learning 4. Working Iteratively 5. Feedback 6. Incrementalism 7. Empiricism 8. Experimental Part III: Optimize for Managing Complexity 9. Modularity 10. Cohesion
- 8. 11. Separation ofConcerns 12. Information Hiding and Abstraction 13. Managing Coupling Part IV: Tools to Support Engineering in Software 14. Tools of an Engineering Discipline 15. The Modern Software Engineer
- 9. Table of Contents Foreword Preface ADefinition of Software Engineering? What Is in This Book? Acknowledgments About the Author Part I: What Is Software Engineering? 1. Introduction Engineering—The Practical Application of Science What Is Software Engineering? Reclaiming “Software Engineering” The Birth of Software Engineering Shifting the Paradigm Summary 2. What Is Engineering? Production Is Not Our Problem Design Engineering, Not Production Engineering A Working Definition of Engineering Engineering != Code Why Does Engineering Matter? The Limits of “Craft”
- 10. Precision and Scalability ManagingComplexity Repeatability and Accuracy of Measurement Engineering, Creativity, and Craft Why What We Do Is Not Software Engineering Trade-Offs The Illusion of Progress The Journey from Craft to Engineering Craft Is Not Enough Time for a Rethink? Summary 3. Fundamentals of an Engineering Approach An Industry of Change? The Importance of Measurement Applying Stability and Throughput The Foundations of a Software Engineering Discipline Experts at Learning Experts at Managing Complexity Summary Part II: Optimize for Learning 4. Working Iteratively Practical Advantages of Working Iteratively Iteration as a Defensive Design Strategy The Lure of the Plan Practicalities of Working Iteratively Summary
- 11. 5. Feedback A PracticalExample of the Importance of Feedback Feedback in Coding Feedback in Integration Feedback in Design Feedback in Architecture Prefer Early Feedback Feedback in Product Design Feedback in Organization and Culture Summary 6. Incrementalism Importance of Modularity Organizational Incrementalism Tools of Incrementalism Limiting the Impact of Change Incremental Design Summary 7. Empiricism Grounded in Reality Separating Empirical from Experimental “I Know That Bug!” Avoiding Self-Deception Inventing a Reality to Suit Our Argument Guided by Reality Summary 8. Experimental What Does “Being Experimental” Mean?
- 12. Feedback Hypothesis Measurement Controlling the Variables AutomatedTesting as Experiments Putting the Experimental Results of Testing into Context Scope of an Experiment Summary Part III: Optimize for Managing Complexity 9. Modularity Hallmarks of Modularity Undervaluing the Importance of Good Design The Importance of Testability Designing for Testability Improves Modularity Services and Modularity Deployability and Modularity Modularity at Different Scales Modularity in Human Systems Summary 10. Cohesion Modularity and Cohesion: Fundamentals of Design A Basic Reduction in Cohesion Context Matters High-Performance Software Link to Coupling Driving High Cohesion with TDD
- 13. How to AchieveCohesive Software Costs of Poor Cohesion Cohesion in Human Systems Summary 11. Separation of Concerns Dependency Injection Separating Essential and Accidental Complexity Importance of DDD Testability Ports & Adapters When to Adopt Ports & Adapters What Is an API? Using TDD to Drive Separation of Concerns Summary 12. Information Hiding and Abstraction Abstraction or Information Hiding What Causes “Big Balls of Mud”? Organizational and Cultural Problems Technical Problems and Problems of Design Fear of Over-Engineering Improving Abstraction Through Testing Power of Abstraction Leaky Abstractions Picking Appropriate Abstractions Abstractions from the Problem Domain Abstract Accidental Complexity Isolate Third-Party Systems and Code
- 14. Always Prefer toHide Information Summary 13. Managing Coupling Cost of Coupling Scaling Up Microservices Decoupling May Mean More Code Loose Coupling Isn’t the Only Kind That Matters Prefer Loose Coupling How Does This Differ from Separation of Concerns? DRY Is too Simplistic Async as a Tool for Loose Coupling Designing for Loose Coupling Loose Coupling in Human Systems Summary Part IV: Tools to Support Engineering in Software 14. Tools of an Engineering Discipline What Is Software Development? Testability as a Tool Measurement Points Problems with Achieving Testability How to Improve Testability Deployability Speed Controlling the Variables Continuous Delivery
- 15. General Tools toSupport Engineering Summary 15. The Modern Software Engineer Engineering as a Human Process Digitally Disruptive Organizations Outcomes vs. Mechanisms Durable and Generally Applicable Foundations of an Engineering Discipline Summary
- 16. Foreword I studied computerscience at university, and of course I completed several modules called “software engineering” or variations on the name. I was not new to programming when I started my degree and had already implemented a fully working inventory system for my high school’s Career’s Library. I remember being extremely confused by “software engineering.” It all seemed designed to get in the way of actually writing code and delivering an application. When I graduated in the early years of this century, I worked in the IT department for a large car company. As you’d expect, they were big on software engineering. It’s here I saw my first (but certainly not my last!) Gantt chart, and it’s where I experienced waterfall development. That is, I saw software teams spending significant amounts of time and effort in the requirements gathering and design stages and much less time in implementation (coding), which of course overran into testing time and then the testing...well, there wasn’t much time left for that. It seemed like what we were told was “software engineering” was actually getting in the way of creating quality applications that were useful to our customers. Like many developers, I felt there must be a better way. I read about Extreme Programming and Scrum. I wanted to work in an agile team and moved jobs a few times trying to find one. Plenty said they were agile, but often this boiled down to putting requirements or tasks on index cards, sticking them on the wall, calling a week a sprint, and then demanding the development team deliver “x” many cards in each sprint to meet some arbitrary deadline. Getting rid of the traditional “software engineering” approach didn’t seem to work either. Ten years into my career as a developer, I interviewed to work for a financial exchange in London. The head of software told me they did Extreme Programming, including TDD and pair programming. He told me
- 17. they were doingsomething called continuous delivery, which was like continuous integration but all the way into production. I’d been working for big investment banks where deployment took a minimum of three hours and was “automated” by the means of a 12-page document of manual steps to follow and commands to type. Continuous delivery seemed like a lovely idea but surely was not possible. The head of software was Dave Farley, and he was in the process of writing his Continuous Delivery book when I joined the company. I worked with him there for four life-changing, career-making years. We really did do pair programming, TDD, and continuous delivery. I also learned about behavior-driven development, automated acceptance testing, domain-driven design, separation of concerns, anti-corruption layers, mechanical sympathy, and levels of indirection. I learned about how to create high-performance, low-latency applications in Java. I finally understood what big O notation really meant and how it applied to real-world coding. In short, all that stuff I had learned at university and read in books was actually used. It was applied in a way that made sense, that worked, and that delivered an extremely high-quality, high-performance application that offered something that was not previously available. More than that, we were happy in our jobs and satisfied as developers. We didn’t work overtime, we didn’t have squeeze times close to releases, the code did not become more tangled and unmaintainable over those years, and we consistently and regularly delivered new features and “business value.” How did we achieve this? By following the practices Dave outlines in this book. It wasn’t formalized like this, and Dave has clearly brought in his experiences from many other organizations to narrow down on the specific concepts that are applicable for a wider range of teams and business domains. What works for two or three co-located teams on a high-performance financial exchange isn’t going to be exactly the same thing that works for a large enterprise project in a manufacturing firm or for a fast-moving startup. In my current role as a developer advocate, I speak to hundreds of developers from all sorts of companies and business domains, and I hear
- 18. about their painpoints (many of them, even now, are not dissimilar to my own experiences 20 years ago) and success stories. The concepts Dave has covered in this book are general enough to work in all these environments and specific enough to be practically helpful. Funnily enough, it was after I left Dave’s team that I started being uncomfortable with the title software engineer. I didn’t think that what we do as developers is engineering; I didn’t think that it was engineering that had made that team successful. I thought engineering was too structured a discipline for what we do when we’re developing complex systems. I like the idea of it being a “craft,” as that encapsulates the idea of both creativity and productivity, even if it doesn’t place enough emphasis on the teamwork that’s needed for working on software problems at scale. Reading this book has changed my mind. Dave clearly explains why we have misconceptions of what “real” engineering is. He shows how engineering is a science-based discipline, but it does not have to be rigid. He walks through how scientific principles and engineering techniques apply to software development and talks about why the production-based techniques we thought were engineering are not appropriate to software development. What I love about what Dave has done with this book is to take concepts that might seem abstract and difficult to apply to the real code we have to work with in our jobs and shown how to use them as tools to think about our specific problems. The book embraces the messy reality of developing code, or should I say, software engineering: there is no single correct answer. Things will change. What was correct at one point in time is sometimes very wrong even a short time later. The first half of the book (“Optimize for Learning”) offers practical solutions for not only surviving this reality but thriving in it. The second half (“Optimize for Managing Complexity”) takes topics that might be considered abstract or academic by some and shows how to apply them to design better (e.g., more robust or more maintainable or other characteristics of “better”) code.
- 19. Here, design absolutelydoes not mean pages and pages of design documents or UML diagrams but may be as simple as “thinking about the code before or during writing it.” (One of the things I noticed when I pair programmed with Dave was how little time he spends actually typing the code. Turns out, thinking about what we write before we write it can actually save us a lot of time and effort.) This second section doesn’t avoid, or try to explain away, any contradictions in using the practices together or potential confusion that can be caused by a single one (e.g., exactly how loosely coupled should a system be?). Instead, because he takes the time to talk about the trade-offs and common areas of confusion, I found myself understanding for the first time that it is precisely the balance and the tension between these things that creates “better” systems. It’s about understanding that these things are guidelines, understanding their costs and benefits, and thinking of them as lenses to use to look at the code/design/architecture, and occasionally dials to twiddle, rather than binary, black-and-white, right-or-wrong rules. Reading this book made me understand why we were so successful, and satisfied, as “software engineers” during that time I worked with Dave. I hope that by reading this book, you benefit from Dave’s experience and advice, without having to hire a Dave Farley for your team. Happy engineering! —Trisha Gee, developer advocate and Java champion
- 20. Preface This book putsthe engineering back into software engineering. In it, I describe a practical approach to software development that applies a consciously rational, scientific style of thinking to solving problems. These ideas stem from applying what we have learned about software development over the last few decades consistently. My ambition for this book is to convince you that engineering is perhaps not what you think it is and that it is completely appropriate and effective when applied to software development. I will then proceed to describe the foundations of such an engineering approach to software and how and why it works. This is not about the latest fads in process or technology, but rather proven, practical approaches where we have the data that shows us what works and what doesn’t. Working iteratively in small steps works better than not. Organizing our work into a series of small informal experiments and gathering feedback to inform our learning allows us to proceed more deliberately and to explore the problem and solution spaces that we inhabit. Compartmentalizing our work so that each part is focused, clear, and understandable allows us to evolve our systems safely and deliberately even when we don’t understand the destination before we begin. This approach provides us with guidance on where to focus and what to focus on, even when we don’t know the answers. It improves our chances of success, whatever the nature of the challenge that we are presented with. In this book, I define a model for how we organize ourselves to create great software and how we can do that efficiently, and at any scale, for genuinely complex systems, as well as for simpler ones. There have always been groups of people who have done excellent work. We have benefitted from innovative pioneers who have shown us what is possible. In recent years, though, our industry has learned how to better
- 21. explain what reallyworks. We now better understand what ideas are more generic and so can be applied more widely, and we have data to back up this learning. We can more reliably build software better and faster, and we have data to back that up too. We can solve world-class, difficult problems, and we have experience of many successful projects, and companies, to back those claims too. This approach assembles a collection of important foundational ideas and builds on the work that went before. At one level there is nothing that is new here in terms of novel practices, but the approach that I describe assembles important ideas and practices into a coherent whole and gives us principles on which a software engineering discipline may be built. This is not a random collection of disparate ideas. These ideas are intimately entwined and mutually reinforcing. When they come together and are applied consistently to how we think about, organize, and undertake our work, they have a significant impact on the efficiency and the quality of that work. This is a fundamentally different way of thinking about what it is that we do, even though each idea in isolation may be familiar. When these things come together and are applied as guiding principles for decision- making in software, it represents a new paradigm for development. We are learning what software engineering really means, and it is not always what we expected. Engineering is about adopting a scientific, rationalist approach to solving practical problems within economic constraints, but that doesn’t mean that such an approach is either theoretical or bureaucratic. Almost by definition, engineering is pragmatic. Past attempts at defining software engineering have made the mistake of being too proscriptive, defining specific tools or technologies. Software engineering is more than the code that we write and the tools that we use. Software engineering is not production engineering in any form; that is not our problem. If when I say engineering it makes you think bureaucracy, please read this book and think again. Software engineering is not the same thing as computer science, though we often confuse the two. We need both software engineers and computer
- 22. scientists. This bookis about the discipline, process, and ideas that we need to apply to reliably and repeatably create better software. To be worthy of the name, we would expect an engineering discipline for software to help us to solve the problems that face us with higher quality and more efficiently. Such an engineering approach would also help us to solve problems that we haven’t thought of yet, using technologies that haven’t been invented yet. The ideas of such a discipline would be general, durable, and pervasive. This book is an attempt to define a collection of such closely related, interlinked ideas. My aim is to assemble them into something coherent that we can treat as an approach that informs nearly all of the decisions that we make as software developers and software development teams. Software engineering as a concept, if it is to have any meaning at all, must provide us with an advantage, not merely an opportunity to adopt new tools. All ideas aren’t equal. There are good ideas, and there are bad ideas, so how can we tell the difference? What principles could we apply that will allow us to evaluate any new idea in software and software development and decide if it was likely to be good or bad? Anything that can justifiably be classified as an engineering approach to solving problems in software will be generally applicable and foundational in scope. This book is about those ideas. What criteria should you use to choose your tools? How should you organize your work? How should you organize the systems that you build and the code that you write to increase your chances of success in their creation? A Definition of Software Engineering? I make the claim in this book that we should think of software engineering in these terms: Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software. My aim is an ambitious one. I want to propose an outline, a structure, an approach that we could consider to be a genuine engineering discipline for
- 23. software. At theroot this is based in three key ideas. • Science and its practical application “engineering” are vital tools in making effective progress in technical disciplines. • Our discipline is fundamentally one of learning and discovery, so we need to become experts at learning to succeed, and science and engineering are how we learn most effectively. • Finally, the systems that we build are often complex and are increasingly so. Meaning, to cope with their development, we need to become experts at managing that complexity. What Is in This Book? We begin by looking at what engineering really means in the context of software in Part I, “What Is Software Engineering?” This is about the principles and philosophy of engineering and how we can apply these ideas to software. This is a technical philosophy for software development. Part II, “Optimize for Learning,” looks at how we organize our work to allow us to make progress in small steps. How do we evaluate if we are making good progress or merely creating tomorrow’s legacy system today? Part III, “Optimize for Managing Complexity,” explores the principles and techniques necessary for managing complexity. This explores each of these principles in more depth and their meaning and applicability in the creation of high-quality software, whatever its nature. The final section, Part IV, “Tools to Support Engineering in Software,” describes the ideas and approaches to work that maximize our opportunities to learn and facilitate our ability to make progress in small steps and to manage the complexity of our systems as they grow. Sprinkled throughout this book, as sidebars, are reflections on the history and philosophy of software engineering and how thinking has progressed. These inserts provide helpful context to many of the ideas in this book.
- 24. Acknowledgments [This contentis currently in development.] This content is currently in development.
- 25. About the Author DavidFarley is a pioneer of continuous delivery, thought leader, and expert practitioner in continuous delivery, DevOps, TDD, and software development in general. Dave has been a programmer, software engineer, systems architect, and leader of successful teams for many years, from the early days of modern computing, taking those fundamental principles of how computers and software work and shaping groundbreaking, innovative approaches that have changed how we approach modern software development. Dave has challenged conventional thinking and led teams to build world-class software. Dave is co-author of the Jolt award-winning book Continuous Delivery, is a popular conference speaker, and runs a YouTube channel with more than 80,000 subscribers on the topic of software engineering. Dave built one of the world’s fastest financial exchanges, is a pioneer of BDD, an author of the Reactive Manifesto, and a winner of the Duke award for open source software with the LMAX Disruptor. Dave is passionate about helping development teams around the world improve the design, quality, and reliability of their software by sharing his expertise through his consultancy, YouTube channel, and training courses. Twitter: @davefarley77 YouTube Channel: https://bit.ly/CDonYT Blog: http://www.davefarley.net Company Website: https://www.continuous-delivery.co.uk
- 26. Part I: WhatIs Software Engineering?
- 27. 1. Introduction Engineering—The PracticalApplication of Science Software development is a process of discovery and exploration; therefore, to succeed at it, software engineers need to become experts at learning. Humanity’s best approach to learning is science, so we need to adopt the techniques and strategies of science and apply them to our problems. This is often misunderstood to mean that we need to become physicists measuring things to unreasonable, in the context of software, levels of precision. Engineering is more pragmatic than that. What I mean when I say we should apply the techniques and strategies of science is that we should apply some pretty basic, but nevertheless extremely important, ideas. The scientific method that most of us learned about in school is described by Wikipedia as: • Characterize: Make an observation of the current state. • Hypothesize: Create a description, a theory that may explain your observation. • Predict: Make a prediction based on your hypothesis. • Experiment: Test your prediction. When we organize our thinking this way and start to make progress on the basis of many small informal experiments, we begin to limit our risk of jumping to inappropriate conclusions and so end up doing a better job. If we start to think in terms of controlling the variables in our experiments so that we can achieve more consistency and reliability in our results, this leads us in the direction of more deterministic systems and code. If we start to think in terms of being skeptical about our ideas and explore how we
- 28. could falsify them,we can identify, and then eliminate, bad ideas more quickly and so make progress much faster. This book is deeply grounded in a practical, pragmatic approach to solving problems in software, based on an informal adoption of basic scientific principles, in other words, engineering! What Is Software Engineering? My working definition for software engineering that underpins the ideas in this book is this: Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software. The adoption of an engineering approach to software development is important for two main reasons. First, software development is always an exercise in discovery and learning, and second, if our aim is to be “efficient” and “economic,” then our ability to learn must be sustainable. This means that we must manage the complexity of the systems that we create in ways that maintain our ability to learn new things and adapt to them. So, we must become experts at learning and experts at managing complexity. There are five techniques that form the roots of this focus on learning. Specifically, to become experts at learning, we need the following: • Iteration • Feedback • Incrementalism • Experimentation • Empiricism This is an evolutionary approach to the creation of complex systems. Complex systems don’t spring fully formed from our imaginations. They are the product of many small steps, where we try out our ideas and react to
- 29. success and failurealong the way. These are the tools that allow us to accomplish that exploration and discovery. Working this way imposes constraints on how we can safely proceed. We need to be able to work in ways that facilitate the journey of exploration that is at the heart of every software project. So as well as having a laser-focus on learning, we also need to work in ways that allow us to make progress when the answers, and sometimes even the direction, is uncertain. For that we need to become experts at managing complexity. Whatever the nature of the problems that we solve or the technologies that we use to solve them, addressing the complexity of the problems that face us and the solutions that we apply to them is a central differentiator between bad systems and good. To become experts at managing complexity, we need the following: • Modularity • Cohesion • Separation of Concerns • Abstraction • Loose Coupling It is easy to look at these ideas and dismiss them as familiar. Yes, you are almost certainly familiar with all of them. The aim of this book is to organize them and place them into a coherent approach to developing software systems that helps you to take best advantage of their potential. This book describes how to use these ten ideas as tools to steer software development. It then goes on to describe a series of ideas that act as practical tools to drive an effective strategy for any software development. These ideas include the following: • Testability • Deployability • Speed • Controlling the variables
- 30. • Continuous delivery Whenwe apply this thinking, the results are profound. We create software of higher quality, we produce work more quickly, and the people working on the teams that adopt these principles report that they enjoy their work more, feel less stress, and have a better work-life balance.1 1 Based on findings from the “State of DevOps” reports as well as reports from Microsoft and Google These are extravagant claims, but again they are backed by the data. Reclaiming “Software Engineering” I struggled over the title of this book, not because I didn’t know what I wanted to call it, but because our industry has so redefined what engineering means in the context of software that the term has become devalued. In software it is often seen as either simply a synonym for “code” or something that puts people off as being overly bureaucratic and procedural. For true engineering, nothing could be further from the truth. In other disciplines, engineering simply means the “stuff that works.” It is the process and practice that you apply to increase your chances of doing a good job. If our “software engineering” practices don’t allow us to build better software faster, then they aren’t really engineering, and we should change them! That is the fundamental idea at the heart of this book, and its aim is to describe an intellectually consistent model that pulls together some foundational principles that sit at the roots of all great software development. There is never any guarantee of success, but by adopting these mental tools and organizing principles and applying them to your work, you will certainly increase your chances of success. How to Make Progress
- 31. Software development isa complex, sophisticated activity. It is, in some ways, one of the more complex activities that we, as a species, undertake. It is ridiculous to assume that every individual or even every team can, and should, invent how to approach it, from scratch, every time we begin a new piece of work. We have learned, and continue to learn, things that work and things that don’t. So how can we, as an industry and as teams, make progress and build on the shoulders of giants, as Isaac Newton once said, if everyone has a veto on everything? We need some agreed principles and some discipline that guides our activities. The danger in this line of thinking is that, if misapplied, it can lead to draconian, overly directive, “decision from authority”–style thinking. We will fall back on previous bad ideas, where the job of managers and leaders is assumed to be to tell everyone else what to do and how to do it. The big problem with being “proscriptive” or overly “directive” is, what do we do if some of our ideas are wrong or incomplete? They inevitably will be, so how can we challenge and refute old, but well-established, bad ideas and evaluate novel, potentially great, untried ideas? We have a very strong example of how to solve these problems. It’s an approach that allows us the intellectual freedom to challenge and refute dogma and to differentiate between fashion, plain-old bad ideas and great ones, whatever their source. It allows us to replace the bad ideas with better ideas and to improve on the good ideas. Fundamentally we need some structure that allows us to grow and to evolve improved approaches, strategies, processes, technologies, and solutions. We call this good example science! When we apply this kind of thinking to solving practical problems, we call it engineering! This book is about what it means to apply scientific-style reasoning to our discipline and so achieve something that we can genuinely and accurately refer to as software engineering. The Birth of Software Engineering
- 32. Software engineering asa concept was created at the end of the 1960s. The term was first used by Margaret Hamilton who later became the director of the Software Engineering Division of the MIT Instrumentation Lab. Margaret was leading the effort to develop the flight-control software for the Apollo space program. During the same period, the North Atlantic Treaty Organization (NATO) convened a conference in Garmisch-Partenkirchen, Germany, to try to define the term. This was the first software engineering conference. The earliest computers had been programmed by flipping switches, or even hard-coded as part of their design. It quickly became clear to the pioneers that this was slow and inflexible, and the idea of the “stored program” was born. This is the idea that, for the first time, made a clear distinction between software and hardware. By the late 1960s, computer programs had become complex enough to make them difficult to create and maintain in their own right. They were involved in solving more complex problems and were rapidly becoming the enabling step that allowed certain classes of problems to be solved at all. There was perceived to be a significant gap between the rate at which progress was being made in hardware compared to the rate at which it was being made in software. This was referred to, at the time, as the software crisis. The NATO conference was convened, in part, in response to this crisis. Reading the notes from the conference today, there are many ideas that are clearly durable. They have stood the test of time and are as true today as they were in 1968. That should be interesting to us, if we aspire to identify some fundamental characteristics that define our discipline. A few years later, looking back, Turing award–winner Fred Brooks compared the progress in software with that in hardware: There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity.2 2 Source: Fred Brooks’ 1986 paper called “No Silver Bullet.” See https://bit.ly/2UalM4T.
- 33. Brooks was sayingthis in comparison with the famous Moore’s law,3 which hardware development had been tracking for many years. 3 In 1965, Gordon Moore predicted that transistor densities (not performance) would double every year, later revised to every two years, for the next decade (to 1975). This prediction became a target for semiconductor producers and significantly exceeded Moore’s expectations, being met for several more decades. Some observers believe that we are reaching the end of this explosive growth in capacity, because of the limitations of the current approaches and the approach of quantum effects, but at the time of writing, high-density semiconductor development continues to track Moore’s law. Source: Accelerate: The Science of Lean Software and DevOps by Nicole Fosgren, Jez Humble, and Gene Kim (2018) This is an interesting observation and one that, I think, would surprise many people, but in essence it has always been true. Brooks goes on to state that this is not so much a problem of software development; it is much more an observation on the unique, staggering improvement in hardware performance: We must observe that the anomaly is not that software progress is so slow but that computer hardware progress is so fast. No other technology since civilization began has seen six orders of magnitude price-performance gain in 30 years. He wrote this in 1986, what we would today think of as the dawn of the computer age. Progress in hardware since then has continued at this pace, and the computers that seemed so powerful to Brooks look like toys compared to the capacity and performance of modern systems. And yet...his observation on the rate of improvement in software development remains true. Shifting the Paradigm 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.
- 34. In the 18thcentury, reputable biologists (they weren’t called that then) believed that some animals spontaneously generated themselves. Darwin came along in the middle of the 19th century and described the process of natural selection, and this over-turned the idea of spontaneous generation completely. This change in thinking ultimately led to our modern understanding of genetics and our ability to understand life at a more fundamental level, create technologies that allow us to manipulate these genes, and so create COVID-19 vaccines and genetic therapies. Similarly, Kepler, Copernicus, and Galileo challenged the then conventional wisdom that Earth was at the center of the universe. They instead proposed a heliocentric model for the solar system. This ultimately led to Newton creating laws of gravitation and Einstein creating general relativity, and it allowed us to travel in space and create technologies like GPS. The idea of paradigm shift implicitly includes the idea that when we make such a shift, we will, as part of that process, discard some other ideas that we now know are no longer correct. The implications of treating software development as a genuine engineering discipline, rooted in the philosophy of the scientific method and scientific rationalism, are profound. It is profound not only in its impact and effectiveness, described so eloquently in the Accelerate Book,4 but also in the essential need to discard the ideas that this approach supersedes. 4 The people behind the “State of DevOps” reports, DORA, described the predictive model that they have created from their research. This gives us an approach to learning more effectively and discarding bad ideas more efficiently. I believe that the approach to software development that I describe in this book represents such a paradigm shift. It provides us with a new perspective on what it is that we do and how we do it. Summary
- 35. Applying this kindof engineering thinking to software does not need to be heavyweight or overly complex. The paradigm shift in thinking differently about what it is that we do, and how we do it, when we create software should help us to see the wood for the trees and make this simpler, more reliable, and more efficient. This is not about more bureaucracy; it is about enhancing our ability to create high-quality software more sustainably and more reliably.
- 36. 2. What IsEngineering? We talk a lot about change in our industry, we get excited about new technologies and new products, but do these changes really I have been talking to people about software engineering for some years now. As a result I regularly get involved in a surprising number of conversations about bridge building. They usually start with the phrase “Yes, but software isn’t bridge building” as though this was some kind of revelation. Of course, software engineering is not the same as bridge building, but what most software developers think of as bridge building isn’t like real bridge building, either. This conversation is really a form of confusion between production engineering and design engineering. Production engineering is a complex problem when the discipline involved is dealing with physical things. You need to get those physical things created to certain levels of precision and quality. You need your widgets delivered to some specific location in space, at a particular time, to a defined budget and so on. You need to adapt theoretical ideas to practical reality as your models and designs are found to be lacking. Digital assets are completely different. Although there are some analogs to these problems, for digital artifacts these problems either don’t really exist or can be made trivially simple. The cost of production of digital assets of any kind is essentially free, or at least should be. Production Is Not Our Problem For most human endeavor, the production of “things” is the hard part. It may take effort and ingenuity to design a car, an airliner, or a mobile phone, but taking that initial prototype design and idea into mass production is immensely more expensive and complicated.
- 37. This is particularlytrue if we aim to do it with any kind of efficiency. As a result of these difficulties, we, products of the industrial age and industrial age thinking, automatically, almost unthinkingly, worry about this aspect, the production, of any significant task. The result of this, in software, has been that we have fairly consistently tried to apply “production-style thinking” to our industry. Waterfall1 rocesses are production lines for software. They are the tools of mass production. They are not the tools of discovery, learning, and experimentation that are, or at least should be, at the heart of our profession. 1 Waterfall, as applied to software development, is a staged, sequential approach to organizing work by breaking it down into a series of distinct phases with well-defined handovers between each phase. The idea is that you tackle each phase in turn, rather than iterate. Unless we are foolish in our software development choices, for us, production consists of triggering the build! It is automatic, push-button, immensely scalable and so cheap that it is best considered free. We can still make mistakes and get it wrong, but these are problems that are understood and well addressed by tools and technology. “Production” is not our problem. This makes our discipline unusual. It also makes it subject to easy misunderstanding and misapplied thinking, and practices, because this ease of production is so unusual. Design Engineering, Not Production Engineering Even in the real world, what most people think of as “bridge building” is different if the bridge-builders are building the first of a new kind of bridge. In this circumstance you have two problems: one that is relevant to software development and one that is not. First, the one that is not—when building even the first of a new kind of bridge, because it is physical, you have all of the production problems, and many more, that I mentioned. From a software perspective, these can be ignored. The second, in the case of bridge-building, is that in addition to those production problems, if you are building the first of a new kind of bridge, the second really difficult part is the design of your new bridge.
- 38. This is difficultbecause you can’t iterate quickly when your product is something physical. When building physical things, they are difficult to change. As a result, engineers in other disciplines adopt modeling techniques. They may choose to build small physical models, and these days probably computer simulations of their design or mathematical models of various kinds. In this respect, we software developers have an enormous advantage. A bridge-builder may create a computer simulation of their proposed design, but this will only be an approximation of the real thing. Their simulation, their model, will be inaccurate. The models that we create as software, our computer simulations of a problem, are our product. We don’t need to worry if our models match reality; our models are the reality of our system, so we can verify them. We don’t need to worry about the cost of changing them. They are software, and so dramatically easier to change, at least when compared to a bridge. Ours is a technical discipline. We like to think of ourselves in this context, and my guess is that the majority of people who think of themselves as professional software developers probably have had some science in their education. Despite this, little software development is practiced with scientific rationalism in mind. In part, this is because we took some missteps in our history. In part this is because we assume that science is hard, expensive, and impossible to achieve within the scope of normal software development schedules. Part of the mistake here is to assume some level of idealistic precision that is impossible in any field, let alone the field of software development. We have made the mistake of seeking mathematical precision, which is not the same thing as engineering! Engineering as Math During the late 1980s and early 1990s there was a lot of talk about more programming-structural ideas. The thinking about the meaning of
- 39. software engineering movedon to examine the ways in which we work to generate the code. Specifically, how could we work in ways that are more effective at identifying and eliminating problems in our designs and implementations? Formal methods became a popular idea. Most university courses, at the time, would teach formal methods. A formal method is an approach to building software systems that has, built into it, a mathematical validation of the code written. The idea is that the code is proven to be correct. The big problem with this is that while it is hard to write code for a complex system, it is even harder to write code that defines the behavior of a complex system and that also proves itself to be correct. Formal methods are an appealing idea, but pragmatically they haven’t gained widespread adoption in general software development practice because at the point of production, they make the code harder to produce, not less. A more philosophical argument is a little different, though. Software is unusual stuff; it clearly appeals to people who often also enjoy mathematical thinking. So the appeal of taking a mathematical approach to software is obvious, but also somewhat limiting. Consider a real-world analogy. Modern engineers will use all the tools at their disposal to develop a new system. They will create models and simulations and crunch the numbers to figure out if their system will work. Their work is heavily informed by mathematics, but then they will try it out for real. In other engineering disciplines, math is certainly an important tool, but it doesn’t replace the need to test and to learn empirically from real- world experience. There is too much variance in the real world to completely predict an outcome. If math alone was enough to design an airplane, then that is what aerospace companies would do, because it would be cheaper than building real prototypes, but they don’t do that. Instead, they use math extensively to inform their thinking, and then they check their thinking by testing a real device. Software is not quite the same as an airplane or a space rocket. Software is digital and runs on mostly deterministic devices called computers. So for some narrow contexts, if the problem is simple
- 40. enough, constrained enough,deterministic enough, and the variability low enough, then formal methods can prove a case. The problem here is the degree to which the system as a whole is deterministic. If the system is concurrent anywhere, interacts with the “real world” (people) anywhere, or is just working in a sufficiently complex domain, then the “provability” quickly explodes to become impractical. So, instead, we take the same course as our aerospace colleagues, apply mathematical thinking where we can, and take a data-driven, pragmatic, empirical, experimental approach to learning, allowing us to adapt our systems as we grow them incrementally. As I write this book, SpaceX is busy blowing up rockets while it works to perfect Starship.2 It has certainly built mathematical models of nearly every aspect of the design of its rockets, its engines, the fuel delivery systems, launch infrastructure, and everything else, but then it tests them. 2 At the time of writing, SpaceX is developing a new fully reusable spacecraft. SpaceX’s intent is to create a system that will allow people to journey to and live on Mars as well as explore other parts of the solar system. It has adopted an intentionally fast, iterative style of engineering to rapidly create and evaluate a series of fast-to-produce prototypes. This is design engineering in extreme form at the limits of engineering knowledge and presents a fascinating example of what it takes to create something new. Even something seemingly simple, like switching from 4mm stainless steel to 3mm stainless steel, may sound like a pretty controlled change. SpaceX has access to detailed data on the tensile strength of the metal. It has experience and data collected from tests that show exactly how strong pressure vessels constructed from the 4mm steel are. Yet still, after SpaceX crunched the numbers, it built experimental prototypes to evaluate the difference. It pressurized these test pieces to destruction to see if the calculations were accurate and to gain deeper insight. SpaceX collected data and validated its models because these models will certainly be wrong in some maybe esoteric, difficult-to-predict way. The remarkable advantage that we have over all other engineering disciplines means that the models that we create in software are the executable result of our work, so when we test them, we are testing our products, not our best guess of the reality of our products.
- 41. If we workcarefully to isolate the part of the system that we are interested in, we can evaluate it in exactly the same environment that it will be exposed to in production. So our experimental simulation can much more precisely and much more accurately represent the “real world” of our systems than in any other discipline. In his excellent talk called “Real Software Engineering,”3 Glenn Vanderburg says that in other disciplines “Engineering means stuff that works” and that almost the opposite has become true for software. 3 https://youtu.be/RhdlBHHimeM Vanderburg goes on to explore why this is the case. He describes an academic approach to software engineering that was so onerous that almost no one who had practiced it would recommend it for future projects. It was heavyweight and added no significant value to the process of software development at all. In a telling phrase, Vanderburg says: [Academic software engineering] only worked because sharp people, who cared, were willing to circumvent the process. That is not engineering by any sensible definition. Vanderburg’s description of “engineering as the stuff that works” is important. If the practices that we choose to identify as “engineering” don’t allow us to make better software faster, then they don’t qualify as engineering! Software development, unlike all physical production processes, is wholly an exercise in discovery, learning, and design. Our problem is one of exploration, and so we, even more than the spaceship designers, should be applying the techniques of exploration rather than the techniques of production engineering. Ours is solely a discipline of design engineering. So if our understanding of engineering is often confused, what is engineering really about? The First Software Engineer
- 42. During the periodwhen Margaret Hamilton was the leading the development of the Apollo flight control systems, there were no “rules of the game” to follow. She said, “We evolved our ‘software engineering’ rules with each new relevant discovery, while top management rules from NASA went from “’complete freedom’” to “’bureaucratic overkill.’” There was very little experience of such complex projects to call on at this time. So the team was often breaking new ground. The challenges facing Hamilton and her team were profound, and there was no looking up the answers on Stack Overflow in the 1960s. Hamilton described some of the challenges: “The space mission software had to be man-rated. Not only did it have to work, it had to work the first time. Not only did the software itself have to be ultra- reliable, it needed to be able to perform error detection and recovery in real time. Our languages dared us to make the most subtle of errors. We were on our own to come up with rules for building software. What we learned from the errors was full of surprises.” At the same time, software in general was looked down on as a kind of “poor relation” compared to other, more “grown-up” forms of engineering. One of the reasons that Hamilton coined the term software engineering was to try to get people in other disciplines to take the software more seriously. One of the driving forces behind Hamilton’s approach was the focus on how things fail—the ways in which we get things wrong. “There was a fascination on my part with errors, a never ending pass-time of mine was what made a particular error, or class of errors, happen and how to prevent it in the future.” This focus was grounded in a scientifically rational approach to problem solving. The assumption was not that you could plan and get it right first time, rather that you treated all ideas, solutions, and designs with skepticism until you ran out of ideas about how things could go wrong. Occasionally, reality is still going to surprise you, but this is engineering empiricism at work. The other engineering principle that is embodied in Hamilton’s early work is the idea of “failing safely.” The assumption is that we can never code for every scenario, so how do we code in ways that allow our
- 43. systems to copewith the unexpected and still make progress? Famously it was Hamilton’s, unasked for, implementation of this idea that saved the Apollo 11 mission and allowed the Lunar Module Eagle to successfully land on the moon, despite the computer becoming overloaded during the descent. As Neil Armstrong and Buzz Aldrin descended in the Lunar Excursion Module (LEM) toward the moon, there was an exchange between the astronauts and mission control. As the LEM neared the surface of the moon, the computer reported 1201 and 1202 alarms. The astronauts asked whether they should proceed or abort the mission. NASA hesitated until one of the engineers shouted “Go!” because he understood what had happened to the software. “On Apollo 11, each time a 1201 or 1202 alarm appeared, the computer rebooted, restarted the important stuff, like steering the descent engine and running the DSKY to let the crew know what was going on, but did not restart all the erroneously-scheduled rendezvous radar jobs. The NASA guys in the MOCR knew—because MIT had extensively tested the restart capability—that the mission could go forward.”4 This “fail safe” behavior was coded into the system, without any specific prediction of when or how it would be useful. So Hamilton and her team introduced two key attributes of a more engineering-led style of thinking, with empirical learning and discovery and the habit of imagining how things could possibly go wrong. Source: “Peter Adler,” https://go.nasa.gov/1AKbDei A Working Definition of Engineering Most dictionary definitions of the word engineering include common words and phrases: “application of math,” “empirical evidence,” “scientific reasoning,” “within economic constraints.” I propose the following working definition: Engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems.
- 44. All of thewords here matter. Engineering is applied science. It is practical, using empirical means to learn and advance understanding and solutions toward the resolution of a problem. The solutions that engineering creates are not abstract ivory-tower things; they are practical and applicable to the problem and the context. They are efficient, and they are created with an understanding of, and constrained by, the economics of the situation. Engineering != Code Another common misperception of what engineering means when it comes to software development is that engineering is only the output—the code or perhaps its design. This is too narrow an interpretation. What does engineering mean to SpaceX? It is not the rockets; they are the products of engineering. Engineering is the process of creating them. There is certainly engineering in the rockets, and they are certainly “engineered structures,” but we don’t see only the act of welding the metal as engineering, unless we have a weirdly narrow view of the topic. If my definition works, then engineering is about applying scientific rationalism to solving problems. It is the “solving of the problems” where the engineering really comes to play, not the just solutions themselves. It is the processes, tools, and techniques. It is the ideas, philosophy, and approach that together make up an engineering discipline. I had an unusual experience while writing this book: I published a video about the failure of a game on my YouTube channel, which was dramatically more popular than most of my videos. The most common negative feedback I got, in saying that this was a “failure of software engineering,” was that I was blaming programmers and not their managers. I meant that it was a failure in the whole approach to producing software. The planning was bad, the culture was bad, the code was bad (lots of bugs apparently). So, for this book, when I talk about engineering, unless I qualify it specifically, I mean everything that it takes to make software. Process,
- 45. tools, culture—all arepart of the whole. The Evolution of Programming Languages Early efforts in software engineering were focused primarily on creating better languages in which to program things. The first computers made little or no separation between hardware and software. They were programmed by plugging wires into patch boards or flipping switches. Interestingly, this job was often given to “computers,” often women, who had previously done the computation (math) before the computer (as a machine) arrived. This underplays their role, though. The “program” at this point, specified by someone “more important” in the organization, was often of the form “we’d like to solve this mathematical problem.” The organization of the work, and later the specifics of how to translate that into appropriate machine-settings, was left to these human “computers.” These were the real pioneers of our discipline! We would use a different language to describe these activities today. We would describe the description passed to the people doing the work as requirements, the act of forming a plan to solve the problem as programming, and the“ computers” as the first real programmers of these early electronic computer systems. 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. High-level languages that could capture ideas at a higher level of abstraction were the next major advance. This allowed programmers to make progress much more quickly. By the early 1980s, nearly all the foundational concepts in language design had been covered. That doesn’t mean there was no progress after this, but most of the big ideas had been covered. Nevertheless, software development’s focus on language as a core idea in our discipline has continued.
- 46. There were severalsignificant steps that certainly affected the productivity of programmers, but probably only one step gave, or came close to giving, Fred Brooks 10x improvement. That was the step from machine code to high-level languages. Other steps along this evolutionary path were significant, such as procedural programming, object orientation, and functional programming, but all of these ideas have been around for a very long time. Our industry’s obsession with languages and tools has been damaging to our profession. This doesn’t mean that there are no advances to be had in language design, but most work in language design seems to concentrate on the wrong kinds of things, such as syntactic advances rather that structural advances. In the early days, certainly, we needed to learn and explore what is possible and what made sense. Since then, though, a lot of effort has been expended for relatively little progress. When Fred Brooks said there were no 10x improvements, the rest of his paper was focused on what we could do to overcome this limitation: “The first step toward the management of disease was replacement of demon theories, and humors theories, by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical solutions. “...the system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit-by-bit it is fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below.” These ideas were based on deeper, more profound ideas than trivial details of language implementation. These were issues more to do with the philosophy of our discipline and the application of some foundational principles that hold true whatever the nature of the technology. Why Does Engineering Matter?
- 47. Another way tothink of this is to consider how we go about the production of the things that help us. For the vast majority of human history, everything that we created was the product of craft. Craft is an effective approach to creating things, but it has its limits. Craft is very good at creating “one-off” items. In a craft-based production system, each item will, inevitably, be unique. In its purest sense this is true of any production system, but in craft-based approaches this is more true because the precision, and so the repeatability, of the production process is generally low. This means that the amount of variance between individually crafted artifacts is higher. Even the most masterful of craftspeople will create items with only human levels of precision and tolerance. This seriously impacts the ability of craft-based systems to reproduce things reliably. Grace Hopper said: To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge. The Limits of “Craft” We often have an emotional reaction to craft-based production. As human beings we like the variance; we like the feeling that our treasured, hand- crafted thing embodies the skill, love, and care of the craftsperson who created it. However, at the root, craft-based production is fundamentally low-quality. A human being, however talented, is not as accurate as a machine. We can build machines that can manipulate individual atoms, even subatomic particles, but a human being is extraordinarily talented if they can produce something, manually, with the accuracy of 1/10 of a millimeter.5 5 Atoms vary in size but are usually measured in tens of picometers (1 x 10^-12m). So, the best of human handcraft is 10 million times less accurate than a good machine. How does this precision matter in software? Let us think about what happens when our programs are executed. A human being can perceive
- 48. change, any change,at the limit of approximately 13 milliseconds. To process an image or to react to something takes hundreds of milliseconds.6 6 “How Fast is Real-time? Human Perception and Technology,” https://bit.ly/2Lb7pL1 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! If we limit the quality of our work to human-scale perception and accuracy, we are, at the very best, sampling what is going on at a rate of 1:(39 million). So, what are our chances of us missing something? Precision and Scalability This difference between craft and engineering highlights two aspects of engineering that are important in the context of software: precision and scalability. Precision is obvious: we can manipulate things at a much higher resolution of detail, through the application of engineering techniques, than by hand. Scalability is perhaps less immediately obvious but is even more important. An engineering approach is not limited in the same way that a craft-based approach is. The limits of any approach that relies on human capability is, ultimately, limited by human capability. If I dedicate myself to achieving something extraordinary, I may learn to paint a line, file a piece of metal, or stitch leather car seats to within tiny fractions of a millimeter, but however hard I try, however gifted I may be, there are hard limits to how accurate human muscles and senses can be.
- 49. An engineer, though,can create a machine to make something smaller and more precise. We can build machines (tools) to make smaller machines. This technique is scalable all the way down to the limits of quantum physics and all the way up to the limits of cosmology. There is nothing, at least in theory, to prevent us, via the application of engineering, to manipulate atoms and electrons (as we already do) or stars and blackholes (as we may do one day). To put this more clearly into the context of software, if we are very skilled and train very hard, we could perhaps enter text and click buttons quickly enough to test our software at a rate where we could imagine being able to carry out a test of our software in a few minutes. Let’s imagine for the sake of comparison that we can carry out one test of our software every minute (not a pace that I can imagine myself being able to sustain for very long). If we can run a test per minute, we are under-testing compared to a computer by hundreds of thousands, probably millions, of times. I have built systems that ran around 30,000 test cases in about 2 minutes. We could have scaled that up considerably further, but had no reason to do so. Google claims to run 150 million test executions per day. That works out to 104,166 tests per minute.7 7 “The State of Continuous Integration Testing at Google,” https://bit.ly/3eLbAgB Not only can we use our computers to test hundreds of thousands of times more quickly than a human being, we can sustain that pace for as long as we have electricity for our computers. That is scalable! Managing Complexity There is another way in which engineering scales, where craft does not. Engineering thinking tends to lead us to compartmentalize problems. Before the American Civil War in the 1860s, if you wanted a gun, you went to a gunsmith. The gunsmith was a craftsman, and he was usually a man! The gunsmith would create a whole gun for you. He would understand every aspect of that gun, and it would be unique to you. He would probably give you a mold for your bullets, because your bullets would be different from everyone else’s and specific to your gun. If your gun had screws, each
- 50. one was almostcertainly different from all of the others, because it would have been hand-made. The American Civil War was unique in its day. It was the first war where arms were mass-produced. There is a story of the man who wanted to sell rifles to the northern states. He was an innovator and, it seems, a bit of a showman. He went to Congress to make his case to get the contract to make the rifles for the armies of the northern states. He took with him a sack full of rifle components. As part of his presentation to the Congressmen, he emptied the bag of components onto the floor of Congress and asked the Congressmen to select components from the pile. From these components he assembled a rifle, and so won the contract, and invented mass production. This was the first time that this kind of standardization was possible. A lot of things had to happen to make it possible; machines (tools) had to be engineered to make components that were repeatably identical to one another, within some defined tolerance. The design had to be modular so that the components could be assembled, and so on. The result was devastating. The American Civil War was, in essence, the first modern war. Hundreds of thousands of people were killed because of the mass production of armaments. These arms were cheaper, easier to maintain and repair, and more accurate than those that had gone before. This all was because they were engineered with more precision, but also because there were lots more of them. The process of production could be de-skilled and scaled up. Instead of needing an expert master craftsperson for each weapon, the machinery in the factory could allow less-skilled people to create rifles of comparable precision to a master. Later, as tooling, production techniques, and engineering understanding and discipline increased, these mass-produced weapons exceeded the quality, as well as the productivity, of even the greatest master craftsmen, and at a price that anyone could afford. A simplistic view may interpret this as a “need to standardize,” or a need to adopt “mass production for software,” but this is, once again, confusing the
- 51. fundamental nature ourproblem. This is not about production—it is about design. If we design a gun that is modular and componentized in the way that the arms manufacturers of the American Civil War did, then we can design parts of that gun more independently. Viewing this from a design perspective rather than from a production engineering or manufacturing perspective, we have improved our management of the complexity of building guns. Before this step, the gunsmith master-craftsmen would need to think of the whole gun if they wanted to change some aspect of its design. By componentizing the design, the Civil War manufacturers could explore changes incrementally to improve the quality of their products step-by-step. Edsger Dijkstra said: The art of programming is the art of organizing complexity. Repeatability and Accuracy of Measurement The other aspect of engineering that is commonly seen, and is sometimes used to reject engineering as an idea applicable to software, is that of repeatability. If we can build a machine to reliably and accurately reproduce a nut and bolt, we can churn them out, and all of the copies of bolts will work with any of the copies of nuts that are produced. This is a production problem and so not really applicable to software. However, the more fundamental idea that underpins this kind of capability is applicable to software. To make nuts and bolts, or anything else, that needs to reliably work together, we need to be able to measure things with a certain level of precision. Accuracy in measurement is an enabling aspect of engineering in any discipline. Let us for a moment imagine a complex software system. After a few weeks of operation, let’s say two, the system fails. The system is restarted, and two weeks later it fails again in much the same way; there is a pattern. How
- 52. would a craft-focusedteam cope with this compared to an engineering- focused team? The crafty team will probably decide that what they need is to test the software more thoroughly. Because they are thinking in craft terms, what they want is to clearly observe the failure. This isn’t stupid; it makes sense in this context, but how to do it? The commonest solution that I have seen to this kind of problem is to create something called a soak test. The soak test will run for a bit longer than the normal time between failure, let’s say three weeks for our example. Sometimes people will try to speed up time so that the soak will simulate the problem period in a shorter time, but usually not. The test runs, the system fails the test after two weeks, and the bug is, eventually, identified and fixed. Is there any alternative to this strategy? Well, yes! Soak tests detect resource leaks of one form or another. There are two ways to detect leaks; you can wait for the leak to become obvious, or you can increase the precision of your measurement so you catch the leak early before it becomes catastrophic. I had a leak in my kitchen recently. It was in a pipe, buried in concrete. We detected the leak once it had soaked the concrete sufficiently for water to start to puddle on the surface. This is the “obvious” detection strategy. We got a professional in to help us fix the leak. He brought a tool, an engineered solution. It was a highly sensitive microphone that “listened” for the sound of the leak underground. Using this tool, he could detect the faint hiss of leaking water buried in concrete with sufficient, super-human, precision to allow him to identify the location within a few inches and so dig a small trench to get at the defective piece of pipe. So back to our example: the engineering-focused team will use accurate measurement, rather than waiting for something bad to happen. They will measure the performance of their software to detect leaks before they become a problem!
- 53. This approach hasmultiple benefits; it means that catastrophic failure, in production, is largely avoided, but it also means that they can get an indication of a problem and valuable feedback on the health of their system much, much sooner. Instead of running a soak tests for weeks, the engineering-focused team can detect leaks during regular testing of the system and get a result in a matter of minutes. David Parnas said: Software engineering is often treated as a branch of computer science. This is akin to regarding chemical engineering as a branch of chemistry. We need both chemists and chemical engineers, but they are different. Engineering, Creativity, and Craft To think about engineering in general and software engineering specifically, I have been exploring some of these ideas for a few years. I have spoken on this topic at software conferences and occasionally written on this topic in blog posts. I sometimes get feedback from people who are adherents to the ideas of software craftsmanship. This feedback is usually of the form “You are missing something important in dismissing craftsmanship.” The ideas of software craftsmanship were important. They represented an important step away from the big-ceremony, production-centered approaches to software development that preceded them. It is not my contention that software craftsmanship is wrong, but rather that it is not enough. In part, these debates begin from an incorrect premise, one that I have already mentioned. Many of these software craftspeople make the common mistake of assuming that all engineering is about solving production problems. I have already covered that issue; if our problem is “design engineering,” then this is a very different, much more exploratory, creative, discipline compared to “production engineering.” In addition, though, my software craftspeople interlocutors are also concerned about the dangers of throwing away the gains that software craftsmanship has brought, namely, a focus on the following: • Skill
- 54. • Creativity • Freedomto innovate • Apprentice schemes These things are important to any effective, professional approach to software development. However, they are not limited to craft-based approaches. Software craftsmanship movement was an important step in improving software development by refocusing on things that were important, with the things in the previous list being some of those important things. These ideas had become lost, or at least subsumed, by attempts through the 1980s and 1990s to force-fit some kind of command-and-control, production-centered approach onto software development. This was a terrible idea because although waterfall-style processes and thinking have a place in problems where the steps are well-understood, repeatable, and predictable, this bears little or no relationship to the reality of software development. Software craftsmanship was a much better fit for the type of problem that software development really is. The problem with craft-based solutions to problems is that they are not scalable in the way that engineering-based solutions are. Craft can produce good things, but only within certain bounds. Engineering discipline in virtually all human endeavors increases quality, reduces costs, and generally provides more robust, resilient, and flexible solutions. It is a big mistake to associate ideas like skill, creativity, and innovation only with craft. Engineers in general, but certainly design engineers, exhibit all of these qualities in abundance all of the time. These attributes are central to the process of design engineering. So taking an engineering approach to solving problems does not, in any way, reduce the importance of skill, creativity, and innovation. If anything, it amplifies the need for these attributes.
- 55. Another Random ScribdDocument with Unrelated Content
- 56. Article 3. Ahmed Mokhtarpar une suite de l'affection qu'il a et conservera pour les Français et par une suite encore des conditions du présent traité, jure et promet de n'avoir jamais directement ou indirectement aucune communication avec les
- 57. Anglais; il jurede plus et promet d'employer tous les moyens praticables pour intercepter et supprimer complètement le commerce que les Anglais pourraient faire avec Portendik, soit avec ses propres sujets, soit avec toute autre nation ou particuliers qui passeraient pour cet objet dans son pays. Cette promesse de la part d'Ahmed Mokhtar, portant non seulement sur la traite de la gomme, mais encore sur toute autre traite, dont il entend, veut et promet d'exclure les Anglais. Article 4. En conséquence de l'obligation portée dans le précédent article, et en retour des bonnes dispositions d'Ahmed Mokhtar. Le Sr Durand, Directeur général de la Compagnie, s'engage pour elle, et promet de lui donner une gratification, en sus de la coutume, toutes les fois qu'il arrêtera ou fera arrêter de la gomme dans le chemin de Portendik, et la fera conduire à Podor, de manière que la Compagnie puisse être assurée qu'il n'en sera point vendu à Portendik. Article 5. Ahmed Mokhtar promet et s'engage de faire tous ses efforts pour procurer annuellement à la Compagnie la traite de gomme la plus abondante possible. Article 6. Ahmed Mokhtar, considéré comme l'arbitre du prix de la gomme et de la mesure du kantar, promet encore et s'oblige de régler annuellement le payement dudit kantar au plus bas prix possible, et de fixer sa mesure conformément au kantar dont la précédente Compagnie était en usage de se servir. Article 7. Dans tous les temps et dans toutes les circonstances, Ahmed Mokhtar promet et s'oblige de favoriser en tout les opérations de la Compagnie, et particulièrement la traite de la gomme; il promet encore de la servir de son
- 58. influence et deses bons offices auprès des marchands maures et tous autres qui auraient à traiter avec elle. Article 8. En retour des dispositions d'Ahmed Mokhtar, le Sr Durand au nom de la Compagnie, promet et s'engage de le traiter toujours comme un ami distingué, et de lui accorder la plus grande faveur.
- 59. Article 9. Le commerceayant introduit l'usage de payer une coutume à Ahmed Mokhtar, pour traiter la gomme, les captifs, le morfil et autres objets généralement quelconques, dans son pays, et cette coutume ayant varié suivant
- 60. les circonstances, ellevient d'être fixée, tant pour la gomme, captifs, morfil et autres objets de traite, d'une manière positive et permanente, par l'article suivant: Article 10. Toutes les fois que la coutume fera traiter de la gomme, le Sr Durand, Directeur général de la Compagnie s'oblige pour elle de payer annuellement à Ahmed Mokhtar. 400 pièces de guinée. 100 fusils fins à un coup. 200 barils de poudre de 2 livres. 100 pièces de platille. 100 miroirs de traite. 20 paires de pistolets à un coup. 80 barres de fer de 8 pieds. 1.000 balles. 3.000 pierres à feu. 120 mains de papier. 150 tabatières pleines de girofle. 150 cadenas. 150 peignes de buis. 150 paires de ciseaux. 150 jambettes. 2 pièces de mousseline. 1 pièce d'écarlate. 50 piastres en argent. 1 filière d'ambre no 2. 1 filière de corail no 2. 2 fusils fins à 2 coups. 2 paires de pistolets à 2 coups. 1 chaudron de cuivre. 1 moustiquaire. 1 matelas de crin. 1 pièce de guinée tous les 8 kantars-mesures et conduits à bord.
- 61. De plus onlui payera pour des soupers, pendant la traite, 2 pièces de guinée tous les huit jours. 100 pintes de mélasse une fois payées. 10 pains de sucre une fois payés.
- 62. Pour Sidi Ély,frère du Roi. 14 pièces de guinée. 1 fusil fin à 2 coups. 1 paire de pistolets fins à 2 coups. 2 fusils fins à un coup. 4 pièces de platille. 4 miroirs. 8 coudées d'écarlate. 6 tabatières pleines de girofle. 6 cadenas. 6 paires de ciseaux. 6 peignes de buis. 6 jambettes. A la femme du Roi. 8 pièces de guinée. 4 pièces de platille. 4 tabatières pleines de girofle. 4 cadenas. 4 paires de ciseaux. 4 peignes de buis. 4 jambettes. 4 miroirs. 8 coudées d'écarlate. A Fatma, sœur aînée du Roi. 4 pièces de guinée. 4 coudées d'écarlate. 4 pièces de platille. 4 paires de ciseaux. 4 tabatières pleines de girofle. 4 cadenas. 4 peignes de buis. 4 jambettes. 2 miroirs.
- 63. Aux quatre jeunessœurs d'Ahmed Mokhtar et à sa fille. A chacune, 2 pièces de guinée. 2 pièces de platille.
- 64. 2 miroirs. 2 cadenas. 2tabatières pleines de girofle. 2 jambettes. 2 peignes de buis. 2 paires de ciseaux. Au premier ministre. 5 pièces de guinée. 4 pièces de platille. 4 fusils fins à un coup. 4 cadenas. 4 miroirs. 4 jambettes. 4 paires de ciseaux. 4 peignes de buis. 4 tabatières pleines de girofle. Pour les soupers de Sidi Ély et des marabouts qu'il loge chez lui. 1 mouton. 2 bouteilles de mélasse par jour pendant la traite. Pour sa suite: 1 mouton. 2 bouteilles de mélasse. Tous les objets ci-dessus détaillés, tant pour le Roi que pour les autres, seront payés; savoir: Un tiers au commencement de la traite, un tiers au milieu, et l'autre à la fin. Article 11. Lorsque la Compagnie enverra ses bâtiments, à l'époque réglée pour la traite de la gomme, à Podor ou tout autre pays d'Ahmed Mokhtar, si ces mêmes bâtiments n'étaient pas d'une capacité suffisante pour recevoir toute la gomme qui se présenterait, le Directeur la fera enlever successivement par ses
- 65. embarcations particulières quila conduiront dans ces établissements, soit à Podor, soit ailleurs, de manière qu'elle aura la faculté de traiter en tout temps toutes les parties de gomme qu'on transportera dans les différentes escales de traite du pays d'Ahmed Mokhtar.
- 66. Article 12. Au moyendes conventions arrêtées et convenues dans l'article 10 du présent traité, Ahmed Mokhtar n'aura plus rien à prétendre, et renonce dès à présent, pour toujours, à toute autre demande qui sera étrangère à ce qui vient d'être réglé. Article 13. Demeure convenu que le comptoir de Podor et tous autres qui pourraient être établis ne seront tenus à aucun payement, et qu'ils auront la faculté de traiter annuellement tous les objets qui se présenteront; il en sera de même pour les bâtiments que la Compagnie pourrait expédier dans le courant de l'année pour la traite des captifs, morfil et autres productions du pays d'Ahmed Mokhtar, le tout en considération de la coutume arrêtée par l'article 10. Article 14. Les parties contractantes de part et d'autre promettent d'observer sincèrement, fidèlement et de bonne foi, tous les articles contenus et établis dans le précédent traité, sans faire ni souffrir qu'il y soit fait de contravention directe on indirecte; mais au contraire, elles se garantissent généralement et réciproquement toutes ses clauses.
- 68. Note de l'auteur.—Ala suite de son «voyage au Sénégal», Durand a fait paraître un troisième tome, qu'il appelle «Atlas» et où sont contenus les traités passés par lui avec les Maures, et 44 planches dont les 16 premières sont des cartes et des plans et les autres des gravures fort originales de scènes maures et sénégalaises. De ces planches, seule, la 32e , fort curieuse et des plus fantaisistes, mérite une mention. Elle représente «M. Durand recevant à son bord et donnant à dîner au roi Hamet-Moctard et à sa famille». Dans les trois traités passés par Durand figure celui de l'émir des Brakna que nous donnons plus haut. Nous l'avons reproduit quand même ici, afin que la collection des traités passés par la France avec les Brakna fût trouvée ici au complet, et qu'au surplus l'Atlas de Durand est à peu près introuvable. Une note de l'Atlas relate: «Ces traités sont en français et en arabe, ils sont précédés d'un avertissement du citoyen Silvestre de Sacy, professeur d'arabe à la Bibliothèque nationale, qui a bien voulu se charger de revoir le texte, d'en suivre l'impression à l'imprimerie de la République, et qui y a joint des notes aussi savantes qu'indispensables pour l'intelligence de l'arabe.» Nous nous permettrons ici de combler les lacunes que signale l'illustre orientaliste dans son avertissement et dans ses notes. Parmi les mots dont il n'a pu reconnaître l'origine il cite «baka», couteau: c'est le vocable «paka» ouolof; de même «sit», miroir: c'est le ouolof «sito». «Idjin», le vin, c'est sans doute le mot anglais «gin». Le «bour Koursi» et non «Kirsen» c'est le «maître du trône». Le «Kariba» est une déformation de «barika», barrique, baril. Les autres fautes, signalées par lui dans le texte arabe, sont des erreurs de copiste. Elles n'existent pas dans le texte original de nos Archives de Dakar. De plus, le texte du traité, publié par Durand, porte un article quinzième et dernier, qui semble bien avoir été ajouté après coup et par lui-même, car il n'existe pas dans le texte officiel et au surplus était du plus grand intérêt pour sa Compagnie. Le voici: «Art. 15.—En cas de contestations sur l'exécution ou l'interprétation d'un ou de plusieurs articles du présent traité, les parties contractantes s'en remettent volontairement et sans retour à la décision de M. le Gouverneur du Sénégal, et promettent de s'en tenir à son jugement.»
- 69. ANNEXE II Délibération ausujet des préparatifs de guerre du chef de la tribu des Braknas. 14 ventôse, an 7 (1799). LIBERTÉ ÉGALITÉ Aujourd'hui quatorzième jour du mois de ventôse de l'an VII de la République Française une et indivisible. Des envoyés de Amar Comba, chef de la tribu des Maures Trarzas, se sont présentés devant le Commandant et les principaux habitants du Sénégal, assemblés en la maison du gouvernement, et ont dit qu'ils venaient au nom et de la part de Amar Comba instruire le Gouvernement français que Ahmed Mokhtar chef des Maures Braknas se préparait à faire la guerre au Sénégal, qu'il avait député son fils Agris à Amar Comba pour lui communiquer sa résolution et le presser de se joindre à lui, mais que Amar Comba s'était refusé à ses sollicitations, et avait répondu qu'il voulait toujours entretenir la bonne intelligence et l'amitié qui existait entre lui et les Français; que, d'après ce refus, Ahmed Mokhtar avait rompu toute liaison avec les Trarzas, et paraissait se disposer à armer contre eux, ainsi que contre le Sénégal. En conséquence de ce rapport, le Commandant du Sénégal a déclaré qu'il ferait mettre dès ce moment à exécution le décret de la Convention nationale du 29 mars 1793, an 2e de la République, relatif à Ahmed Mokhtar, qui interdit toute relation avec lui, suspend le payement de ces coutumes, et prescrit les dispositions nécessaires à cet effet; décret auquel il avait été sursis d'après les démarches de Ahmed Mokhtar et les assurances qu'il avait donné pour l'avenir. En même temps, le Commandant du Sénégal arrête que Amar Comba, chef de la tribu des Maures Trarzas, sera remercié au nom du Gouvernement de l'avis amical qu'il a donné à cette colonie, et qu'il lui sera fait en reconnaissance un présent extraordinaire. Fait en la maison du gouvernement de l'Ile du Sénégal, les jours, mois et an ci-dessus. Signé: Blanchot, Cormié, Pre Dubois, Malalle, Blondin fils, Paul Bénis, Flamand, Fs Pellegrin, H. Pellegrin et Charboniez, greffier.
- 70. ANNEXE III Traité passéentre le Lieutenant-Gouverneur Maxwell et Sidy Ély, chef d'une tribu des Bracknas. 7 juin 1810. Soit notoire à tous ceux à qui il appartiendra ou peut appartenir, que moi Lieutenant-Colonel Ch. W. Maxwell, gouverneur de S. M. Britannique pour les établissements du Sénégal, Gorée et dépendances, d'une part; Et moi Sidy Ély chef d'une tribu des Braknas, d'autre part; Considérant que depuis quelque temps la traite de gomme dans la rivière a été interrompue et désirant de prévenir à l'avenir toutes querelles et mésintelligences et établir des règlements sûrs et positifs pour le bien général de toute la traite: nous sommes convenus solennellement des arrangements suivants: c'est-à-dire: Article premier. Aussitôt l'arrivée d'un bâtiment ou canot quelconque aux escales des Braknas, le roi Sidy Ély prendra des arrangements par écrit avec le Capitaine ou subrécargue, pour les coutumes qui doivent lui être payées, dans lesquels arrangements il sera exactement spécifié les qualités et différentes qualités des marchandises convenues pour lesdites coutumes; il en sera dressé deux copies, dont une sera remise au Capitaine ou subrécargue et l'autre au Roi, ou à toute autre personne autorisée par lui, comme il sera spécifié ci-dessous. Article 2. Le Roi, en son absence, autorisera son premier ministre, qui sera chargé par lui de régler lesdites coutumes avec les capitaines et subrécargues suivant les conditions spécifiées dans l'article premier. Le Roi promet solennellement de remplir et se conformer en tout aux arrangements et conventions qui seront passés par son ministre.
- 71. Article 3. Les coutumesainsi fixées seront payées au Roi ou à son chargé de pouvoir, comme il est spécifié dans l'article 2 dans les proportions suivantes, c'est-à-dire: un tiers lorsque le bâtiment aura mesuré sa première barrique de gomme, un tiers lorsqu'il sera à moitié chargé et l'autre tiers lorsqu'il aura fini sa traite. Un reçu sera donné par le Roi ou par son député, au Capitaine ou subrécargue, lors du payement du dernier tiers des coutumes convenues. Article 4. Le Lieutenant-Gouverneur promet et s'engage de faire respecter les engagements et de faire payer les coutumes ainsi contractées d'après les articles ci-dessus mentionnés, et facilitera de tout son pouvoir la traite de gomme aux escales des Bracknas. Finalement les deux parties promettent et s'engagent mutuellement de remplir et exécuter fidèlement les engagements qu'elles ont contractés par ces présents. Fait et passé au Sénégal, le 7 juin 1810. Signé; Sidy Ély, Ch. W. Maxwell, Lieutenant-Gouverneur, Ch. Porquet, maire, et Ed.-O. Hara. Sénégal 13 June 1810, By order of the Lt Gouvr Heddle. ANNEXE IV Traité avec Ahmed Dou, roi de la tribu des Bracknas, et M. Julien Schmaltz, commandant pour le roi et administrateur du Sénégal et dépendances. 20 mai 1819.
- 72. A la gloiredu Tout-Puissant, créateur du ciel et de la terre, père éternel de tous les êtres vivants. Au nom et sous les auspices de S. M. T. C. le Roi de France et de Navarre. J. Schmaltz, Chevr de l'ordre Royl milre de Saint-Louis et de l'ordre Royl de la Lég. d'hon., Colonel, Commandant pour le Roi et Administrateur du Sénégal et dépendances, d'une part; Ahmedou, Roi de la tribu du Brackna, d'autre part; Réunis à l'escale du Coq et confèrent sur les intérêts généraux tant des établissements français du Sénégal que des maures et divers peuples indigènes qui habitent les bords du fleuve; Prenant en considération, d'une part, la conduite juste et irréprochable tenue par Ahmedou envers les traitants de Saint-Louis, depuis qu'il a succédé à Sidi Ély, son père, et la confiance qu'une telle manière d'agir doit inspirer pour la suite; de l'autre, le grand intérêt que ledit Ahmedou a de se conserver toujours et quoi qu'il puisse arriver, en bonne intelligence avec les établissements français du Sénégal et les immenses avantages qui résulteraient infailliblement pour lui, son pays et ses sujets, si le système de colonisation projeté sur la rive gauche du fleuve était en même temps exécuté sur le territoire considérable et populeux qu'il possède sur la rive droite. Et désirant établir entre eux une union inaltérable, une paix et une amitié constante et ouvrir aussitôt qu'il se pourra des nouvelles relations tendant à augmenter les ressources et la prospérité, tant de la France que du pays occupé par les Bracknas, sont convenus des articles suivants: Article premier. Ahmedou, Roi de la tribu des Bracknas, promet et s'engage de favoriser par tous les moyens qui seront en son pouvoir, la traite de gomme qui se fait à son escale et tout autre commerce qui pourrait s'ouvrir par la suite entre les sujets du Roi de France et les siens dans toute l'étendue de son pays. Article 2. Les coutumes à payer par les bâtiments qui viendront en traite de gomme resteront telles qu'elles ont été jusqu'à ce jour; et Ahmedou, Roi des Bracknas, s'engage et promet de se conformer aux règlements que fera le Commandant
- 73. pour le Roipour empêcher toute espèce fraude, et de veiller de son côté à ce qu'ils soient strictement exécutés par ses sujets. Article 3.
- 74. Dans aucun casde discussion entre les traitants et lui, le Roi Ahmedou n'arrêtera ni suspendra la traite, avant d'en avoir donné connaissance au Commandant, pour le Roi, et d'avoir reçu sa réponse. Article 4. Chaque fois que les envoyés d'Ahmedou viendront au Sénégal pour les cas prévus dans le livre des coutumes, ils recevront leurs vivres ainsi qu'il a été réglé par les anciennes conventions. Article 5. Reconnaissant que sa principale richesse provient du commerce que les Français viennent faire à son escale, n'ayant pas de plus grand intérêt que de le conserver et voulant par-dessus toutes choses assurer pour toujours la bonne intelligence qui existe entre eux et lui, Ahmedou, Roi des Bracknas, s'engage et promet de garder franchement une pleine et entière neutralité dans toutes les guerres où pourraient entrer les habitants français du Sénégal, lorsqu'il ne serait pas appelé à les assister ou que des considérations particulières ne lui permettraient pas de se joindre à eux. Article 6. Ayant entendu parler des établissements de culture libre, que le Gouvernement français se propose de former sur la rive gauche du fleuve et des traités que le Commandant pour le Roi a déjà conclu avec le Brack et les principaux chefs du pays de Walo, à ce sujet, sentant que le commerce de la gomme, qui ne soutiendra qu'avec peine la concurrence de produits plus précieux, ne peut suffire à un pays tel que celui qu'il commande lequel s'étend, sur la rive droite, depuis Bakel jusqu'au marigot de Guerer, frontière du pays de Fouta, pensant que vu la fertilité du territoire, qui est la même que celui de l'île à morfil et le grand nombre d'hommes qu'il peut fournir pour le cultiver, rien ne serait plus important pour lui et ses sujets que de le mettre en valeur et d'y retirer le commerce; Ahmedou, Roi des Bracknas, invite le Commandant pour le Roi, à diriger sur son pays, des sujets du Roi de France, pour y former conjointement et avec le secours des siens des établissements de culture dans toutes les positions qui lui paraîtront propres à les recevoir.
- 75. Article 7. En conséquencede l'article ci-dessus, pour son exécution et dans la vue de déterminer ledit Commandant pour le Roi à se rendre au vif désir qu'il en a et aussitôt que ses autres entreprises les lui permettront, Ahmedou, Roi des Bracknas, s'oblige et s'engage, dès à présent, à céder, remettre et transporter à S. M. le Roi de France en toute propriété et pour toujours toutes les portions de son territoire qui paraîtront, au Commandant pour le Roi, propres à la formation de tous les établissements de culture qu'il jugera à propos d'entreprendre par la suite.
- 76. Article 8. La tranquillitédu pays et la sûreté des personnes et des propriétés exigeant des mesures de protection suffisantes pour les mettre à l'abri de toutes incursions de la part des peuples voisins, l'intention et la bonté d'Ahmedou, Roi
- 77. des Bracknas étant,en outre, du moment où les Français s'établiront chez lui, de ne plus faire qu'avec eux, de considérer leurs amis et ennemis comme les siens propres, de tenir sévèrement la main à ce qu'il ne leur soit donné aucun motif de mécontentement par ses sujets; il demande qu'il soit construit, dans son pays, des forts, partout où ils seront jugés nécessaires par le Commandant pour le Roi et qu'il y soit placé des garnisons qu'exigera leur défense, se réservant d'y être reçu en toute circonstance où il sera forcé de pourvoir à sa sûreté personnelle, par fait de guerre dans son pays; et qu'il soit pourvu à sa subsistance pendant le séjour qu'il y fera. Article 9. L'intention du Gouvernement français étant que tous les établissements qu'il formera soient exploités par des bras libres, Ahmedou, Roi des Bracknas, s'oblige et promet de faire concourir aux défrichements et plantations des terres, ainsi qu'aux travaux de toute espèce desdits établissements les cultivateurs soumis à son autorité et de les fournir aux mêmes conditions que celles faites avec le pays de Walo dont on lui a donné communication et dont il déclare avoir pleine connaissance. Article 10. En reconnaissance de la conduite juste et irréprochable, tenue constamment, envers les habitants de Saint-Louis par Ahmedou, Roi des Bracknas, et en retour des dispositions ci-dessus, de la neutralité à laquelle il s'est obligé par le présent traité, ainsi que du désir qu'il a témoigné de concourir aux vues du Gouvernement français et des engagements qu'il a pris à cet égard; le Commandant pour le Roi, s'engage et promet de traiter ledit Ahmedou, comme un ami distingué, tant qu'il persistera dans sa conduite et ses intentions actuelles; de lui rendre et lui payer les coutumes d'honneur ci-devant accordées à Sidy Ély, son père, pour avoir contribué à la paix conclue avec le pays de Fouta, le 4 juin 1806; laquelle sera exigible le 1er août prochain et tous les ans désormais à pareille époque. Article 11.
- 78. Et quant àce qui concerne l'invitation par lui faite d'envoyer des sujets français former des établissements de culture dans son pays, de l'engagement qu'il a pris de céder toutes les portions de son territoire qui seront jugées convenables et de fournir les bras nécessaires à leur exploitation, etc., etc. Le Commandant pour le Roi les accepte pour en profiter aussitôt que ces entreprises actuelles le lui permettront;—s'engageant et promettant de lui accorder, en retour de ses concessions une coutume qui sera fixée pour la traite qu'ils passeront ensemble, avant de commencer les établissements et d'accorder pour les travailleurs qui seront fournis les mêmes conditions qui ont été faites avec Brack et les chefs du pays de Valo.
- 79. Welcome to ourwebsite – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com