What gets us into trouble is not what we don’t know. It’s what we know for sure that just ain’t so.Mark Twain
For each desired change, make the change easy (warning: this may be hard), then make the easy changeKent Beck
“Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.”Kent Beck
The book wasn’t on my reading list, but I had a long drive and a friend suggested it, so here I am. Now I’m not into “self-help” books, however I did read a couple related books in the past.
- Essentialism: The Disciplined Pursuit of Less
- Outliers: The Story of Success
- Deep Work: Rules for Focused Success in a Distracted World
- Emotional Intelligence
So should you give a f*ck about this book? The book is well written and quite interesting but by no means deep. Like many other books, it essentially calls for you to figure out your priorities and focus on them. Unlike other books, this one seems to fill a particular niche – millennial struggle. One has to admit, life nowadays is different from the past and the pace of change is accelerating. It is not a bad thing per se, but presents different challenges. Perhaps you have less chances to be physically harmed or abused, but mentally… I say more. Information stream is just overwhelming and it comes from every part of the world, depending on your web-preference, you can be endlessly bombarded by good or bad news. On top of that there is instant-gratification phenomenon, press a button or better yet just imagine it and you are the winner.
Now one thing that got my curiosity peaked is: “counterintuitive approach” – which took me a bit by surprise, but let me explain. Due to my background, upbringing and some personal challenges in the past, I’m not what you would call a cheerful person. I consider myself a neutral, but I would not blame you if I come across as pessimistic. As a kid I never could answer: what would I like to achieve or be when I grew up. As teenager I adopted “avoidance strategy” (I also call it “working from negative”) – do anything to avoid A or B or C outcomes. So I went to university in order to avoid being a disappointment to my mother and working for low wage for the rest of my life. By default I always pick to do something in order to mitigate or eliminate an obvious or bigger problem (in my estimation) that is coming up. But no-one is perfect and self-delusion is an evolutionary tool, so drinking, smoking and junk food are my guilty pleasures. So to my big surprise the author actually explores, explains and recommends the “avoidance strategy” to achieve things and make a better life for yourself.
In a nutshell:
-: can use a bit more depth and some examples are questionable
+: well written & easy read
+: recipes and methods
+: a counterintuitive approach
=: it is a good book, with some out of the box ideas and discussions. It is short, hits all main issues and doesn’t overburden – can be read in one (perhaps long) sitting – well-worth ROI.
Title: The Subtle Art of Not Giving a F*ck: A Counterintuitive Approach to Living a Good Life
Author: Mark Manson
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.Brian Kernighan
I’m not big on quotes but from time to time I come across some, that are of a particular interest to me. I been kicking an idea of posting them for a while but somehow never doing it. Today it changes!
Robert C. Martin (aka uncle Bob) is one of the men who wrote Agile Manifesto. He created lots of worth while material for developers and championed TDD in a very hands-on approach – thanks for 3 laws of TDD.
I read couple of his books and watched countless hours of his teachings on YouTube. I invested heavily into TDD (thanks to Kent Beck ), which payed off for me in more ways than one and my commitment goes beyond words – please feel free to download and print TDD posters.
So I’m a fan, well… not really. I see lots of value in uncle Bob’s ideas and practices, so I have to give credit where it is due. However I don’t agree with everything he says and so I have couple of bones to pick over the book, but first things first.
The book came out at a very interesting times (end of 2019), when agile is a mainstream – everyone does agile now. Agile coaches without any technical background are training software teams, management happy to track development progress by every commit you make on hourly basis and damn the XP practices, full speed ahead. So timing of the book feels spot on, my only wish is that the book ends up in hands of managers.
But what about developers? Did I as a developer waste my time on the book? No, absolutely not! The book is a very good – easy read, short, concise and no fluff. It contains core concepts on what agile is, what it is meant for and all the practices associated. Now don’t expect details, it is a short book with it’s main focus on agile as a whole and not a full blown technical guide. However, it will provide enough to go and dig into each individual practice and believe me, some of these practices worth their own book. For example:
- Refactoring: Martin Fowler & Kent Beck – “Refactoring: Improving the Design of Existing Code”
- TDD: Kent Beck – “Test Driven Development: By Example”
- Branching: Paul Hammant & Steve Smith – “Trunk Based Development”
- Unit testing: Roy Osherove – “The Art of Unit Testing with examples in C#”
- Coding: Robert C. Martin – “Clean Code: A Handbook of Agile Software Craftsmanship”
Now I can’t shake the urge, so I’ll indulge it: I read Kent’s Beck TDD by example book in 2019, however the book originally was published in 2000 – speaking of being late to the party. By that time I was doing TDD for few years and participated in a few heated discussions on the subject. I guess 19 years is enough time for any subject to become semi-mysterious, bloated and extended beyond the original purpose. So the book was short of a revelation to me, it was simple, pure or how uncle Bob puts it: “back to basics”. It cleared the water, set boundaries and removed mysticism. Is it dated? Yes. Does it deal with modern complexity of micro services? No. But that’s the whole point: what is the original issue and how to deal with it; nothing more, nothing less.
Uncle’s Bob book is exactly the same way. It describes original issues and explains how to deal with them, nothing more and nothing less. If agile doesn’t fit into your team/organization then so be it. Don’t buy into over extended claims of agile industry that it will solve your problems. See for yourself what is agile all about, if it fits, go for it, if it doesn’t then look for something else. Perhaps there are next generation processes and perhaps they are based off agile, but don’t try to force something that doesn’t fit. One last note that I can’t pass, because it is personal and eats me up, I believe Kent Beck summarized it the best:
good engineering is only a small part of a successful project but bad engineering is main reason project failsKent Beck
Now it is time to pick a bone or two with the book. I respect uncle Bob and with this in mind let me ask: why go into something that he has limited knowledge and/or interest. In particular he offers his thoughts on agile in large enterprises. The subject came out iffy at best and confusing at worst. “Agile is for small teams” – yes and let’s leave it at that. There is no need to elaborate on the subject with dubious conclusion: world knows how to manage large projects, the modern society is a testament to that. I guess modern Boeing 737 MAX is also a testament to world’s ability to manage large projects. While he might be right, the book doesn’t answer or give much insight into the subject, so why talk about it at all?
Another bone is the value itself, I always been confused by the word and perhaps the whole argument stems from that, but let me elaborate. If we ask developer why he created so much code for let’s assume rather simple requirement, an answer could be: the code is fail safe, optimized and design wise allows for extensibility. Now in the mind of that developer he created ultimate value for the customer! What could be better than having a safe, fast and extendable code? Another developer might look at the same code with a very different perspective: it took too long to write, by making the code safe, it has many conditions that will never come to be, simply because such a data doesn’t happen that deep into the module. It is fast, but the functionality is not time bound, so unnecessary complexity for no apparent value. The code is extendable but no one has a crystal ball, so why make the code extendable at a cost to a customer who might not need to extend or modify it at all. Has this ever happened in your team?
Now I know, there are XP/Agile practices that guide us through all those tough technical challenges. But in order to invoke those practices (TDD, Simple design, refactoring, pair programming and so on) we must once again talk about the value. One developer with years of experience will look at TDD and say: “nonsense, overkill, waste of time”. Another developer might have exactly the opposite view, but do those opinions matter? If the entire team has to decide on values, then each opinion will matter, now it becomes a debate and political struggle to adopt XP practices/policies. More over how do you go about proving the value of those practices? The book says: “Instead of pushing TDD, maybe we could start agreeing on the value of reducing the time it takes to test our entire system. How long does it take today? Two hours? Two days? Two weeks? How many people are involved? What if we could reduce it to 20 minutes? Two minutes? Maybe even 2 seconds? And what if we could do that at any time just by pressing a button? Would that give us a good return on investment? Would that make our lives easier? Would we be able to release reliable software faster?”
Brilliant, we need to measure and record everything and apply statistics. Now, complexity of the decision making and cost of the entire team is going up, at the cost to a customer and thus far with no apparent value. And by the way, there are other ways to achieve the same result without let’s says TDD or any other practice. But let’s move on next and assume that we agreed on practices. Statistics is powerful, but does management need convincing? Do they want to spend more money? Is data all it takes to convince management and customers? Could there be other values at play? Ultimately a value is an elusive term, we all want a value but which one is a great question. Humanity is diverse and so value is very relative. All of us see value in different things even when statistics and data dictates otherwise. In lots of cases we don’t even have the right or enough data to deduce a value, yet we place bets and talk about the value.
Now the value topic is endless and perhaps I should examine it in a separate post, but now it’s time for final thoughts. The book has its flaws, some I discussed, some I didn’t (hello to end-to-end testing and QA responsibilities). However I wholeheartedly believe that the book is worthwhile the investment. Uncle Bob is entertaining as ever, the timing is spot on, the subject is fascinating and engaging. More importantly though, it brings agile back to the inception, drawing boundaries and highlighting essentials.
In a nutshell:
-: a bit short and has some confusing topics
+: easy read, to the point, concise
+: useful examples and discussions
+: helpful for managers, clients and developers
+: much needed refresh on agile
=: good book, has a lot of value for any developer, manager and client. Book is a bit short and some topics could have been expanded, but over all worthwhile the investment.
Title: Clean Agile: back to basics
Author: Robert C. Martin
I made few note while I was reading the book, so I figured to leave them here just for fun:
Recently I purchased used Mazda MX-5 2007, a third generation Miata, known as NC. The car has spent most of its time parked in a garage or a barn of the previous two owners and it has only 12,000 kilometres on it. Needless to say, it is almost new for the exception of a rock chip on passenger side mirror, few tiny scratches and couple of small dents – which have most likely originated from opening a door in a tight space.
Now, I always liked cars, however I never had an opportunity to dive into car culture and own some fun cars. I guess, one can say I was theoretical car enthusiast watching from a sideline. My past car ownership list is very short and consists of cheap, utility oriented vehicles that a friend of mine dubbed: “fridges”. Priority wise it’s always been: reliability, practicality, cost of ownership, price tag and I believe there is nothing wrong with that. However over the years I always dreamed of buying some light rear-wheel drive sports car that will be relatively cheap to buy, own, maintain and absolutely fun to drive. So how did I end up with a Miata? Well because the answer is always “Miata”. As fun as it is to perpetuate the meme, there is simply nothing else out there to satisfy all of the criteria, but let me explain.
Only a few to consider:
There are lots of cars on the market, starting with my favourite Kia Rio and all the way to super cars such as Lamborghini. However once you apply roughly $25,000 (USD) price range and rear wheel drive with manual transmission requirement, you will end up with fairly limited options:
- BMW 2 or 3 series (may be)
- 124 spider
Now, I never had much interest in BMWs, mostly due to monetary constraints. I drove a Mustang a while back and never felt a connection to the car. Camaro, I never tried but it doesn’t strike me as light weight car at 1,500-1,800 kilograms. 124 spider is a blast and I drove the old one (which reminded me of a Lada to some degree) and a new one (which I loved), however I couldn’t get passed the Fiat engine, which does not strike me as very reliable. Nissan 370Z is very appealing but dated and not light weight. Finally we end up with only Miata and GT86/BRZ. I drove both and this is where things get tough – both are good cars and I can see myself in either one. At this point I had to figure out my priorities, because the choice would come down to what I value more: practicality vs open top, boxer vs inline-4, devil I didn’t know vs devil I knew.
The devil I knew
About 5 years ago, friend of my wanted to buy a fun car. His budget was very limited but he was determined not to buy a “fridge”. After some searching he purchased Mazda Miata NB 1999 – base model with no options. It was old and rusted underneath. He drove it everywhere year around. We car-pooled in it for over a year, every day – sun, rain, snow, ice – doesn’t matter. The car impressed me, despite being, well, tired. It was fun all around. You can throw it into corners, you can floor it all the time, you can cruise it, you can easily wrench on it, it was just fun all around and at very small cost, not to mention it was speed safe – reap it through gears and you are still within acceptable speed limits.
Does it fit?
I heard about Mazda’s philosophy: “jinba ittai” – “rider and horse as one” but always though that it was marketing. Well, not in case of Miata. I think what finally drove me to it was exactly “jinba ittai”. Miata is not a practical car, hell, not everyone can even fit into it. It is not quiet or that comfortable either. But the ride feeling is awesome – every time I think to myself – “look at it, it is useless”, I drop the top, drive it and nothing else matters. But before I committed, I had to think through one final consideration: will it fit into my life? I have a family, small child, drive to work is 40 minutes on highway and I don’t have luxury of spending $24K+ on a car that might not workout when push comes to shove.
Right off the bet: my wife has a nice family car and she was ok with me buying a two seater since I can still pick up our baby from daycare. So I got down to research, as I live in Ontario, I found out that a child can ride in the front seat as long as airbag on passenger side is disabled. Good news since Miata (NA, NB, NC) allows you turn off passenger airbag with a simple turn of the key. Next I called friend of mine and asked if I can take his NB (second generation Miata) for a test drive. I took it on highway and within 20 minutes figured out: it will wear me out as a daily drive. Now I think NB is awesome car, but I have few issues with it. First and most important – I don’t fit quite right into it – I’m simply a little too tall and a bit too fat for it. Second the car is too bouncy for my taste – it is fun to drive it around, but every single day to work and back is too much for me. Yes it is possible to remedy all the issues by modifying stressing wheel (so it doesn’t saw off “important stuff”), add structural bracing and roll cage (for safety), adjust suspension for more comfort and few other things, but in my mind it was just too much.
Another friend told me to look at NC and I was feeling uneasy about it – mostly due to bias on the internet (and remember whatever you read on the internet must be true). NC is the black sheep of the family, no one wants it – it is too long, too heavy, too ugly, too Fordy and whatever else one can come up with. I personally never tried one and figured “what the heck”. It took me a while to find one for sale in my area, but once I got into it I instantly knew – I can live with it.
NC interior is bigger, more space for legs, steering wheel to body clearance is decent and I could heel-toe. Hard-plastic is not my favourite, but on the bright side it doesn’t require much maintenance and probably will not crack under the sun. But what about the drive? The drive is as engaging as ever, you are still positioned low to the ground, power delivery is nice, linear and definitely more powerful, shifts are crisp and it is ready to be thrown into any corner. There is a difference between NB and NC, you can definitely feel it and one can argue that NC is softer and less engaging but on the flip side it is considerably more civilized. You can most definitely daily drive it on the highway, it doesn’t wear you out as much. It is easier to take on road trips and if you want to harden it, change suspension to your liking. Not to mention that there are ton of performance options and ability to swap for 2.5 litre engine from Mazda 6.
In maintenance department NC is very similar to NB. Jacking points are basically the same, reaching for oil filter is a pain the in ass in both (when NB has air conditioning). Changing transmission & diff fluid is the same, coolant replacement is similar, spark plugs change is similar but easier in NB. Prices on all the parts are very reasonable and remember NC has been in production for a long time – there is big aftermarket availability and all the mods one’s heart desires.
I purchased NC during covid-19 pandemic and didn’t get to drive it much. I did all the maintenance and had some fun rides along with my 4 year old child – she loves cornering and open top. I didn’t have a chance to daily drive it to work and back 5 days per week, and so, much is left to be discovered. So far I have no regrets and will post more thought in the future as I get to drive it more.
Every developer is familiar with Pull Request, however recently I came across another useful practice – “sTool Request”. sTool request is a simple and powerful practice yet some, especially junior developers, hesitate to use it; at least I noticed the behaviour in my team and so it is a good time to talk about it.
Unless your team is practicing pair programming, everyone tends to work alone and often the only time you get to see work of another developer is at Pull Request time. While it is generally a good thing, there are few drawbacks:
- Effort has been expanded – sunk cost bias has already kicked in
- Work is completed – physically & physiologically – let’s move on to the next thing
- Code has settled – mistakes are more expensive to fix
- In case a bug is discovered at a later point, it is harder to figure from the original developer – rarely anyone remembers details of decision making and code several weeks back.
sTool Request can help remedy those issues to some degree, at the very least it is cheaper to brainstorm/discuss questions, issues and ideas prior to producing code, and/or at any point during the work. So here goes my proposal to a team:
“Got a question or a doubt? Perhaps you want to bounce ideas around? Ask a team member to grab a stool/chair, sit down and help you out. Use the momentum to have a rich conversation and/or debate. Don’t wait for PR (Pull Request), refactor card, or a bug report. We are all on the same team, working together to deliver team’s goal, improve quality and learn new things.”
I would love for people to pair program, but in the absence of the practice, it is useful to invoke “sTool Request”, summon a developer and work things out. There are so many times I though to myself: “if only a developer have asked prior, he wouldn’t have made those mistakes and also learned a ton from the experience”. It is harder to learn retrospectively, it is better to learn in the moment.