Clean Agile: Back to Basics

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:

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 fails

Kent 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
Cover:

I made few note while I was reading the book, so I figured to leave them here just for fun:

Journey to NC

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:

  • 370Z
  • GT86/BRZ
  • Mustang
  • Camaro
  • 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.

NC

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.

Only forward:

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.

Cheerz!

sTool Request

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.

The Mythical Man-Month

“Adding manpower to a late software project makes it later.”

Brooks’s Law

Sooner or later every developer learns about Brook’s Law, for me it was later, but still better than never. After the encounter and countless references to the book on the internet, I decided to read it for myself and see what it’s all about.

The original book came out in 1975 and the latest revision in 1995. I think it is important to set expectations right, and accept that the author wrote a lot from that perspective – good old days when the industry still debated “if-else block” vs “goto statement”. In addition, the book isn’t an easy read, lot of technologies/terminologies aren’t familiar to me and that made it harder to follow. However I don’t think any of that should be a showstopper, I say: “push through”!

Opinions are like assholes – everyone got one and I’m no different. However I’m really struggling to express my thoughts on this book. On one hand the book is quite insightful, on the other hand, for the lack of better word – irrelevant. On one hand human behaviour didn’t significantly change since 1975, on the other hand business did. Let me give you an example from my personal experience: 45 years after the book has been published, managers still think that adding new developers to meet a three-month deadline is a solution. Never mind that a good developer typically needs more than three months to even get up to speed on our projects. However, adaptation of scrum (or alike) methodologies and business acceptance of small value-adding iterations has changed the way developers schedule and deliver code. There is no more hiding, in every sprint something of a value must be developed, demoed and shipped.

I can grumble, agree and disagree with the author on several points, but I think it is meaningless and unfair. I think the book should be taken for what it is, and not some sort of a guide from the days long gone to the present generation. Nevertheless, perhaps some people must read it for the sake of not solving the same old problems, the same old way, that never worked anyhow. Perhaps everyone should read it and understand that not all IT problems uniquely belong to IT industry and an answer is readily available just outside of it. Perhaps I should stop rambling and admit: may be the book didn’t impress me as much as I hoped it would but at least I don’t feel any regrets spending my time with it.

In a nutshell:
-: Not an easy read if you aren’t familiar with terminology and technology of the past
-: Some irrelevant concepts
+: A lot of insight into software industry, some still hold true
+: Interesting references and opinions
+: Enjoyable, with certain expectations
=: I don’t think this book should be atop a reading list. However if you are curious and have time, I wholeheartedly recommend it. Don’t set any expectations, remember the book originated in 1975 and enjoy the essay.

Title: The Mythical Man-Month: Essays on Software Engineering
Author: Frederick Brooks
Cover:

Notes & Quotes from the book, I couldn’t help myself but to take:

“Solutions to many IT problems already exist in other industries, but IT pro feel and act as those don’t apply.”

“Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.”

“Self-Documenting Programs – a basic principle of data processing teaches the folly of trying to maintain independent files in synchronism. It is far better to combine them into one file with each record containing all the information both files held concerning a given key. Yet our practice in programming documentation violates our own teaching. We typically attempt to maintain a machine-readable form of a program and an independent set of human-readable documentation, consisting of prose and flow charts. The results in fact confirm our teachings about the folly of separate files. Program documentation is notoriously poor, and its maintenance is worse. Changes made in the program do not promptly, accurately, and invariably appear in the paper.”

“Long before any code exists, the specification must be handed to an outside testing group to be scrutinized for completeness and clarity. As Vyssotsky says, the developers themselves cannot do this: “They won’t tell you they don’t understand it; they will happily invent their way through the gaps and obscurities.””

“Day-by-day schedule slippage is harder to recognize, harder to prevent, and harder to make up than calamities. The first step in controlling a big project on a tight schedule is to have a schedule, made up of milestones and dates for them. Milestones must be concrete, specific, measurable events defined with knife-edge sharpness. A programmer will rarely lie about milestone progress, if the milestone is so sharp he can’t deceive himself.”

“Cosgrove advocates treating all plans, milestones, and schedules as tentative, so as to facilitate change. This goes much too far— the common failing of programming groups today is too little management control, not too much.”

“Intercommunication is worse. If each part of the task must be separately coordinated with each other part/ the effort increases as n(n-I)/2. Three workers require three times as much pairwise intercommunication as two; four require six times as much as two. If, moreover, there needs to be conferences among three, four, etc., workers to resolve things jointly, matters get worse yet. The added effort of communicating may fully counteract the division of the original task”

“The basic fallacy of the waterfall model is that it assumes a project goes through the process once, that the architecture is excellent and easy to use, the implementation design is sound, and the realization is fixable as testing proceeds. Another way of saying it is that the waterfall model assumes the mistakes will all be in the realization, and thus that their repair can be smoothly interspersed with component and system testing.”

“The first step is to accept the fact of change as a way of life, rather than an untoward and annoying exception. Cosgrove has perceptively pointed out that the programmer delivers satisfaction of a user need rather than any tangible product. And both the actual need and the user’s perception of that need will change as programs are built, tested, and used.”

“First, the man with strong management talent and strong technical talent is rarely found. Thinkers are rare; doers are rarer; and thinker-doers are rarest.”

“The job done least well by project managers is to utilize the technical genius who is not strong on management talent.”

“In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done.”

“In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done.”

“Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date. Bad news, late and without warning, is unsettling to customers and to managers.”

“But false scheduling to match the patron’s desired date is much more common in our discipline than elsewhere in engineering. It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers”

“The fate of WIMP: Obsolescence. Despite its excellencies, I expect the WIMP interface to be a historical relic in a generation. Pointing will still be the way to express nouns as we command our machines; speech is surely the right way to express the verbs. Tools such as Voice Navigator for the Mac and Dragon for the PC already provide this capability.”

“Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them”

“The bearing of a child takes nine months, no matter how many women are assigned.”

Frederick Brooks

You should definitely throw an exception

A while back I decided to make a progressive web-app and for the fun of it, learn a new framework (Angular 7 at the time, 9 now), language (TypeScript) and to top it all off, challenge myself by test driving the entire thing.

Before I dive into our main thought, a little disclaimer: I’m sort of a full-stack developer; meaning my world rotates around developing microservices with Dropwizard + Java 8, a little bit of front-end with Backbone & Marionette + JavaScript and a little of Oracle on DB side. Uninspiring and outdated, stack is my daily existence. Regardless of stack, I do test drive all of my code, I believe it is a good idea and I have been doing it for a while now.

From the very inception, I decided to test drive my app and to do it only with unit tests and depending on your definition, integration tests. After years of writing, re-writing and maintaining end-2-end tests, I figured one thing only: they are a waste of time and money. So my entire app is test driven by jasmine specs, starting at individual components (or a service) and moving onto a combination of components (how they work together) and culminating with the main component which is mostly in charge of testing navigation through out the app.

Now, to test a component in Angular (to the best of my knowledge and understanding) is to test a template and associate code together as one thing (unit of work). This represents a bit of a challenge, mostly associated with manipulation of UI. Effectively you will be doing a lot of query selections, clicking, and sometimes dealing with async and Angular change detection. Since I get to work on my app few hours per week, I tend to forget (sometimes rather quickly) fine details of writing a component test. Like the saying goes: “if you can’t beat them, join them”, so I gave up on constant rehashing and decided to write my own test helper, which is easy to use and doesn’t need much to remember. For example, find an element with the placeholder value of “name”.

In addition to all of the above, jasmine errors tend to be verbose and not very user friendly. For example if you are trying to query select all elements, which don’t exist (but you assumed they did) and then call a method on a particular one, you will be met with off-putting exception “undefined is not an object”.

TypeError: undefined is not an object (evaluating 'this.findElementsByPlaceholder(placeholder)[0]') in http://localhost:9876/karma_webpack/main.js (line 3909)

I believe we can do better than that. We can wrap “query select all” calls in your own method, check length and if there are no elements then simply throw an error with explanation. For example:

Error: Could not find a placeholder: name in either of tags: placeholder,ng-reflect-placeholder in http://localhost:9876/karma_webpack/main.js (line 3906)

By doing so, you effectively eliminate confusion and save yourself some time (at least I do). So go out there and throw some well-explained exceptions, so you don’t have to guess which object is undefined and why.

Cheerz.

Multiselect dropdown

Today in the morning I spend couple of hours trying to implement dropdown with filter and “valid only” entry. I started my endeavor with ng-bootstrap dropdown (since I’m working on Angular app), quickly realizing that it will not work since there is no filter option. Next I figured that a typeahead will fit much much better.

Everything worked out very well except for one big caveat: the typeahead does not clear “<input>” field when entry is not valid (not in the list of options). After monkeying with “onBlur” for about 20 minutes, a sane thought occurred in my head: “What am I doing? Hacking? There must be a straight forward way!”.

Welcome Multi-Select Dropdown

The Multi-Select Dropdown also supports single option:

It looks promising and I’m very happy someone figured it out, however I wonder why doesn’t ng-bootstrap include such a useful component?

New Family Production Board

Last year I read a book “Toyota 14 principles” by Jeffrey K. Liker and learned a few powerful ways in order to get stuff done. Right after I finished the book, I implemented FPB (Family Production Board – which is a Kanban board) using masking tape, permanent marker and sticky notes. The board was a success, as we seem to accomplish more stuff than ever before.

Today I decided to upgrade the board to something a little bit more substantial – an old white board, left over from my previous upgrade. The purpose and means remain the same, however the board now looks a lot better.

Cheers.