Canned Software

It’s the day you go shopping (groceries), you go to your preferred supermarket and start your routine. You take all fresh goods, and then head to the canned ones. Your children love canned chicken soup; you know it’s not as healthy as the home-made version, but you use it as a prize for good behavior.

They take a two-week supply and gave it for you to put all the cans in the shopping cart. You, as a responsible parent, inspect the cans one by one, looking for defects and the most important fact: the expiration date. You realize that all cans have the same taste, but they are from different brands. Some already had expired (last year!), some will expire in about a month, and finally you see a group of units with an expiration date about one year in the future. As everyone expects, you pick the last group (is always good to have some canned food if a zombie apocalypse occurs).

Now imagine, just for a moment, that instead of canned chicken soup, you went to shop canned software. And that software will be used to run your business, your brand new car, your home fire detection system, or something as delicate as a life support medical machine. 

Continuing with this history, imagine that instead of an expiration date the software cans are labeled with two important information: what they do (functionalities) or ingredients if they were chicken soup; and what is the expected date when that software will no longer be maintained by its creators (expiration date). That last piece of information talks about the internal quality of the software. It says to you: How easy can this software be extended or fixed. Going back to the chicken soup if we have:

Rotten Software Can

• A can of software (soup) with a past Expiration Date: that means that is not possible for the team working behind that software to fix, add, or change features because the product is a total mess (internally).
• A can of software (soup) with an Expiration Date in the near future: this is a software system (project) that is already dying. Its internal quality is reaching the no return point. In a matter of month this system will no longer be maintainable by its team.
• A can of software (soup) with an Expiration Date so distant that nobody can really say when it will happen: this system is the most reliable, extensible, less risky one. 

Fresh Software Can

Of course we are assuming that the first quality feature (functional) is the same for the three scenarios. 

The second quality feature (expiration date) is what is commonly called the Maintainability Index.

So, please, the next time you need to buy a software system, check its expiration date, you don’t want to poison your business, home, car, or children.

Maintainability Index: opinions and usefulness

The usage of this metric is not universally accepted in the software industry. For example checkout (van Deursen 2014) Think Twice Before Using the "Maintainability Index", where the author exposes why he is not quite sure if the metric should be used. 

The main concern is about the reference data (base-line) used to measure software systems. The maintainability index can be considered a relative metric. Is a common practice for software laboratories to test systems (for its internal quality properties), and use that data so build a ranking. If the baseline does not represent the universe of software products relevant for the subject of the analysis the output is not very useful.

Thankfully, labs like the Software Improvement Group (SGI) calibrates their base data yearly. 

Reflections on Clean Code: Team's Performance

XP-agra for flaccid Scrum teams (Doctor's Choice)

Keep reading if you find yourself or your team in one of the following situations:

1. You no longer have confidence in your estimates (time, effort, risks)
2. You have 'owners' for certain software components
3. Your regression test takes more than half a day
4. A very high rate of bugs (defects) are discovered in production by your users
5. In order to find the piece of code to change or the place to add a few new lines you need to spend hours digging the code base
6. Sometimes you touch Component A and the change affects Components B to Z, and you discover that on late test cycles or live in production
7. With every iteration you feel that the time to perform minor changes is growing exponentially
8. Everybody fears the release date, and stay alert the next week or two expecting the next bomb coming from production
9. Your team is doing Scrum (or so you believe)

If any of the described situations is happening to you be advised: your team is suffering from the disease called "Flaccid Scrum" (FlaccidScrum). This illness causes your performance to, gradually, decrease until you reach the zero productivity (velocity) point. By that time the only possible solution is to dump the code base (put the product in the trashcan), and start over with a greenfield project.

But, fear no more, you can be cured with a simple solution: just take XP-agra the Doctor's Choice for flaccid scrum implementations. You need to start with solid engineering practices as proposed by eXtreme Programming.

The basic problem is that a flaccid scrum team is constantly neglecting the need for internal quality (not just functional quality) in the code base. A team with such a problem is compromising (1) the quality vertex from the following triangle:

Solid Scrum (with XP) mindset

Let's examine each vertex, in the context of "normal" Agile team:

• The time one is the easiest, it is fixed by one of the core concepts of agile methodologies "Time Boxing"
• The scope vertex must be flexible in order have really time boxed iterations, and
• The quality vertex must be fixed in order to maintain a sustainable velocity (performance) by the team.

Flaccid Scrum mindset 

This is the mindset, respecting each vertex, for a "flaccid" Scrum team:

• The time one remains fixed (time boxed)
• The scope vertex is fixed giving a false sense of commitment and "performance" to the Product Owner and the customer, and
• The quality vertex, by necessity, becomes flexible in order to allocate all committed scope inside the time boxed iteration.

The Jenga Tower

By compromising the internal quality the team is shooting himself in the foot because the performance will be gradually degraded. A poor quality code base is difficult to maintain, a headache for the team and for the customers. It becomes very fragile, with each change a new crack arise. With each crack a quick patch is added. After a few iterations the code base has too many patches and becomes extremely hard to touch without breaking it: this is the final stage of a Jenga Tower before collapsing. Something like this: 

"Each block removed is then balanced on top of the tower, creating a progressively taller but less stable structure." (https://en.wikipedia.org/wiki/Jenga)

Practical steps towards solving the problem

Just to be crystal clear,  XP is not a pill, we really can just "take it" and the problem will be gone. In order to solve the underlying quality problem we need to take small, but solid actions. Here I'm only listing the suggested steps but details on each one will be left for upcoming posts:

• First, we need to build awareness around the issue for all stakeholders:
• Your team (complete): developers, testers, leaders, ...
• Your product owner
• Your customers: both inside and outside the organization
• Capital investors / business owners
• Second, improve the knowledge level of the people actually doing the work, because they need to change their bad habits and may require some sort of education / coaching / etc.
• Finally, devise a plan covering short, mid, and large term actions for team to undertake. 
• One of the first steps of this plan is to measure the current situation
• Then, you need to define the KPIs that will be observed as process and quality improvement indicators
• Pick the smallest steps possible, because you don't want to completely stop the team and you need each new practice to be assimilated by the team shifting the mindset a little bit each time. 

Reflections on Clean Code: Estimates

Day one of your iteration, your team is doing the planning game (planning poker, ideal hours, etc.) and everyone is reflecting about the effort needed to work a given requirement. We could have two scenarios:

One: With a Clean Code Base

Clean Code estimates

Two: With a Bad (dirty) Code Base

Bad Code estimates

Imaging your code base as a tool’s repository, those tools are used to solve problems. Your job is to use the proper tool for each task, but you need to do that as quickly as possible. Now think what would happen if any time you enter the shop you find a mess of tools?

In order to do your job, first you need to find all required tools, you reach for the hammer, but find a screwdriver, then you find the drill on the level’s bucket, … (you fell me?)

After finding all required tools you start working on the piece of furniture, but you find that the last carpenter use nails where you expected screws. Also, he had use glue where fine nails where more appropriated. The hammer has grease on the handle and slips. The drill heads are out of order …

By the end of the day you are done with the piece, but you realize that building it from scratch will take half the time.

Too much bla, bla, bla: What should we do about this?

Put each piece / tool inside the proper drawer:

First, imagine your code base as a cabinet with many drawers, each one with a label. Depending on your design decisions labels will have words like (persistence, core logic, controllers, views, domain, tests, etc.); but no matter how your team decided to organize the code, each element must be inside the proper drawer.

You must put components where they belong in order in accordance to the team’s guidelines for the given application.

Leave pieces as clean as possible:

Now imagine a single file as the drill and its heads. Any time you use change heads you need to leave the set in proper order. Also, you should clean and grease moving parts regularly in order to extend the tool’s live and improve performance.
You must keep your components (files, classes, methods, etc.) as clean as possible both on the inside (implementation) and on the outside (public interface / contract).

Include the “cleaning” process in all your estimates:

Let me change the analogy for a moment: imaging what would happen if your preferred restaurant only estimates the cost of serving the dish to your table and cleaning up after you leave. But they “forget” to consider cost of dish-washing, kitchen cleaning cost and time, bathrooms cleaning time, etc.

So, the next time you’ll get there to eat your favorite dinner, they need to spend one hour just to start working on it because all elements were dirty and out of order. So you get served with one-hour delay. As they do all this in such a hurry, you find that the fork is dirty and the napkins have stains all over…

The same happens with software developers only estimating the “change” / “implementation” time,  and not considering the time needed to leave the solution as clean as they found it. Also they forgot the time to add / change existing documentation to reflect the changes. They do not consider the time for proper testing. Simply, they are leaving the shop dirty and tools out of order. When they need to “serve” another client they found the same problems as the lazy restaurant’s employees.

Phrase of the Software Craftsman 009

"Bad code tries to do too much it has muddle intent and ambiguity of purpose."

-Robert C. Martin (Clean Code)

Phrase of the Software Craftsman 008

"Bad code tempts the mess to grow! When others change bad code, they tend to make it worse."

-Robert C. Martin (Clean Code)

Phrase of the Software Craftsman 007

"Clean code always looks like it was written by someone who cares."

-Michael Feathers

Phrase of the Software Craftsman 006

"Code should be composed in such a form as to make it readable by humans."

-Robert C. Martin (Clean Code)

Phrase of the Software Craftsman 005

"Code that communicate its purpose is very important".

-Martin Fowler (Refactoring)

Phrase of the Software Craftsman 004

"Before you start refactoring, check that you have a solid suite of tests. These tests must be self-checking."

-Martin Fowler (Refactoring)

Phrase of the Software Craftsman 003

"[...] spending time keeping your code clean is not just cost effective; it's a matter of professional survival." 

-Robert C. Martin (Clean Code)