Yet Another Programming Blog

These are my highlights while reading Robert C. Martin's book Clean Agile: Back to Basics. Preface Uncle Bob starts with a disclaimer. This book is not a work of research. Think of it as a memoir. I knew this upfront and I was looking forward to see him grumbling about what the world has done to his Agile. Big things don't get done by big teams. Big things get done by many small teams collaborating while doing many small things. This is what programmers in 1950s and 1960s new instinctively and this is what got lost in 1970s. Couple of folks reinvented this idea and called it 'Agile'. It has been nearly 20 years from the start of this movement and Martin thinks it is already time for yet another reboot. Acknowledgments I usually don't read Acknowledgments, but these ones have exceptional list of names. It is basically a to-do list for following and reading the mentioned people. Ward Cunningham, Kent Beck, Martin Fowler, Ken Schwaber, Mary Poppendick, Ron Jeffries and

This is not my kind of book. I usually read books about programming. But the beginning of the book was quite funny. Steve Krug dedicated the book to the woman who laughed so hard while reading this book that milk came out of her nose.  Introduction - Read me first Krug wrote this book for people who cannot afford to have an usability expert in their team. The book is short on purpose - it is more likely it will be used. Krug's definition of usability is: An average person can figure out how to use the thing to accomplish something without it being more trouble than it's worth. This is quite similar to how readability is important when programming. Chapter 1 - Don't make me think This is the first Krug's law of usability. The things we create should be self-evident, so the average people could immediately tell 'Oh, that's a ____'. If you can't make something self-evident, you should at least make it self-explanatory. This reminds me of a Screaming Archite

Notes to my future self about the Kent Beck's book TDD by Example. Part I - The Money Example Kent Beck show us how he works in this part. The routine is: Quickly add a test. See it fail. Make a little change to make it pass. See it pass. Refactor to remove duplication. We quickly see that by following these steps the problem at hand is divided into very small and simple steps . This is useful e.g. if we are distracted a lot. The tests tell us where to continue. Also the small size of the steps reduces "fear" (how Beck calls it). However we are not forced to do the steps these small. We can go at any speed. But when things get weird, we can fallback to really small steps. I'm not very fond of how Beck calls lots of code smells Duplication . The problem is in dependency between the test code and the implementation code. We have to refactor so we don't have any logic shared between the tests and the implementation code. This is the main driver of the design. From th

 These are my notes for my future self about Sam Newman's book Monolith to Microservices. Chapter 1 - Just Enough Microservices What are Microservices? Microservices are independently deployable boxes modelled around business domains, which communicate with each other over network. They are form of Service-Oriented Architecture (SOA) which is opinionated about how services' boundaries should be drawn. The services encompass both behavior and data - they own their underlying database and they expose the data via a well-defined API.  Sam Newman stresses that independent deployability is the absolute key. To achieve it, we need the services with loose coupling, which means services should have stable contracts between them. That also means microservices should not share their databases directly. Microservices are modelled around business domains. If done correctly we should almost never have to change more than ones service for any given feature. If we had to, it would be much har

Chapter 1 - Pragmatic Philosophy There is a repeated pattern at the start of the book (tip 2), which its authors, Hunt and Thomas, use regularly. They think about their work while they are doing it and try to improve it. It is about e.g. repetitive stuff, which could be automated. Tip 3 is about the attitude to business requirements. As a developers, we should be actively searching for ways to make business requirements possible, instead of giving lame excuses, why it is not possible. What would we think about a bank officer who makes lame excuses why he cannot do what we ask? Tip 4 is about a theory, that technical debt is like broken windows in cities. Those are small problems, which, left unfixed, can raise to become huge problems. We should be fixing even small technical debt as soon as it is found. We should also think about, what is the root cause, that this technical debt happened at all. Tip 7 elaborates whether software quality should be part of the requirements. The most of t

Many developers feel no shame when a production bug is found in their code. They ask 'why testers didn't find it?'. Microsoft developers eventually found out some bugs are impossible to spot for the testers. By 1989 the bugs became the developers' responsibility. Developers had to deploy "zero defects" to the Testers. By 1986 Microsoft had explicit monitoring code build into their production code that alerted programmers about bugs. The two critical questions to ask about every bug are: How could I have automatically detected this bug? How could I have prevented this bug? A Hypothetical Compiler  Steve Maguire suggests to turn on all compiler warnings. Today IDEs like IntelliJ IDEA handle warnings perfectly in my opinion. He also suggests to use checkstyle-like tools. Assert Yourself Use debug version of your program to implement assertions. Use assertions to assert input parameters. Use assertions to detect impossible conditions. Write second version of a com

Software Construction The claim that construction errors cost less to fix is true but misleading because the cost of not fixing them can be incredibly high. Construction is 30-70% of a software project. Productivity of individual programmers varies by a factor of 10-20 during construction. Construction is the only activity that's guaranteed to be done. Software Metaphors Advantage of models is that they are easy to grasp as conceptual wholes. Disadvantage is that they can be misleading when overextended. They are heuristics, not algorithms. The writing metaphor suggests that programming is like writing a casual letter. Truth is programmers often talk about 'code readability'. The writing metaphor implies a development process that's too simple and rigid to be healthy. One example of poor advice coming from this metaphor is Fred Brooks' "Plan to throw one away, you will anyway." Another metaphor is software farming - growing a system . You design a piece,