Posts

Notes about Modern Software Engineering

Notes to my future self about David Farley's book Modern Software Engineering. IMHO the book was quite boring, and presented just a few new ideas. Chapter 1 - Introduction We need to become  experts in learning and  experts in  managing complexity . The scientific method we learned at school: Characterize - make an observation about the current state. Hypothesize - create a theory explaining the observation. Predict - make a prediction based on hypothesis. Experiment - test the prediction. When we implement many small experiments this way, we will limit our jumping to wrong conclusions and do a better job. Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software. To become experts in learning , we need the following techniques: Iteration, Feedback, Incrementalism, Experimentation, Empiricism . To become experts in managing complexity we need: Modularity, Cohesion, Separation of Concerns,
Post a Comment
Read more

Notes about Tidy First?

This is a short new book by Kent Beck, having almost 100 pages #surprising . Most of the chapters are one or two pages long. Foreword I liked an old quote by Benjamin Brewster in Foreword, saying: In theory, there is no difference between theory and practice, while in practice, there is. According to Larry Constantine, who wrote the Foreword and who coined Cohesion and Coupling, Cohesion and Coupling are how our brains deal with complicated systems. Using relationships between pieces of code. Nice and tidy. That's the theory. Preface Beck calls his design "Empirical". Why? The most debates in software design are about microservices, how big repositories should be, events versus explicit calls, objects versus imperative code. These "What" debates hide more fundamental disagreement in software design. What Beck misses in the debates is "When". We have two extremes from the "When" perspective: Speculative design - we know what we will want to d
Post a Comment
Read more

Notes about Growing Object-Oriented Software, Guided by Tests

These are my notes about the the book of London school of thought regarding TDD. Both Martin Fowler in his essay and Kent Beck in the Foreword say they practice TDD differently. Therefore I was expecting what I thought was mockist style of testing, with too-small unit tests coupled too much to the implementation, based on what I saw in some companies in Prague (Czechia). I was very surprised with the quality of tips the authors provided. I don't like the first part of the title of the book, a farming metaphor of programming, because if overextended, it would seem like we are out of control of growing the software. I do like the subtitle, being "guided by the tests". The authors make a point of " listening to the tests " and responding to hints of the tests about the design of the production code as well. Chapter 1 - What Is the Point of Test-Driven Development? We know building the software is a learning process and we know there will be changes. What we need i
Post a Comment
Read more

Notes about A Philosophy of Software Design

My notes about the book by John Ousterhout. It is quite a short book. Originally I made a mistake of reading just the Conclusions of the chapters but there is a lot of contents not in the Conclusions. After really reading the whole book, I started to like the Red Flags and other small pieces of hints. Chapter 2 - The Nature of Complexity Complexity is anything related to the structure of a system that makes it hard to understand or modify. Isolating complexity in a place where it will almost never be seen or touched is almost as good as removing it. There are many symptoms of complexity: Change amplification - when change requires modification in many places.  Cognitive load - how much a developer must know in order to make a change. Sometimes more code is simpler than less code because of cognitive load. Unknown unknowns - it is not obvious which places should be modified or what knowledge the developer must have to make a change. Complexity is caused by 2 things - dependencies and o
Post a Comment
Read more