Management Objectives & Coder Objectives

Technical Debt.
Management has business goals - both short term and long term. The two need to be balanced. That is the art of management. Excessive focus on one, or the other, will lead to failure. The short term, by its very nature grabs attention; in most cases to the detriment of the long term. In software development this leads to the taking on of Technical Debt.

Consequences.
As Technical Debt piles up the code becomes increasingly fragile. Fixing one defect introduces other defects. Feature addition becomes a nightmare. Customers become increasingly dissatisfied. The brand erodes.

Causes.
Technical Debt 101 explains the factors that cause technical debt. I strongly recommend reading the article.

Concentrating on today's fires is exciting. Trouble is, the excitement is paid for by taking on technical debt. In this, management have very "willing allies" - the Coders. What are a coder's objectives? The most important are:

1. Improve job market prospects. Hence acquire skills, knowledge.
2. Ensure that they are not easily replaceable by their current employer. The higher the technical debt the greater the job security.

Practices required to prevent buildup of technical debt do not figure in the objectives of most coders. In the rare case that it does, management, by their actions, ensure that it is soon given up.

Software Exorcism is a book that deals with Technical Debt. The book, as it's title says, is about getting rid of the "evil spirits" that can take up residence in software. An evil spirit, in Hindustani, is called Bhoot. Once evil spirits take up residence the software becomes what, in Hindustani, is called a Bhoot Bangla - a Haunted House. Now there is a vested interest in not exorcising the evil spirits.

Exorcism: First Step.
Technical Debt must be managed. Managing anything - whether diabetes, or sports teams, or whatever - requires metrics. Managing financial debt requires financial metrics. Managing technical debt requires technical debt metrics. Managing technical debt will ensure a development process that,

1. Prevents unhealthy build up of Technical Debt. 
2. Takes corrective action to reduce it to defined acceptable levels.

The Conjunction "And"

I try and follow a rule when writing: If the sentence contains the conjunction "and" I see if I can split the sentence into two, or more sentences. An "and" indicates that I am trying to convey more than one aspect/purpose of an idea in the sentence.

I am an advocate of intentional naming. Intentional names can result in long names. If a function name contains an "and", it is an indication that the function is intended to do more than one thing.  It breaks the rule that a function should "do only one thing and do it well" - also known as the Hedgehog Principle.

Being In The Zone

Coding can be exciting. Especially when you are in the flow - in the zone. That's why we like to code. The total absorption in the task, I believe, is the same as being in a state of meditation.

I should know. Why else would I be coding in my seventies?

However, as with anything that we enjoy doing we must learn to do it in a disciplined manner.

In the zone one needs the discipline to :

1. Write the Executable Specification before implementing the code that it will test.
2. Use the idioms of team's coding standard. 
3. Spend time on thinking up names that convey the intention/purpose/responsibility of the files, objects, structures, functions, and variables.
4. Commit frequently to the version control system (I advocate using Git). Do a diff of the source files with the earlier commit. Document the reason for the changes in the commit log.
5. Refactor ruthlessly.

The discipline has to be practiced when in the zone. 

Easier said than done. I should know. Six-Pack Abs need discipline 😊

Why Did Some Dog Not Bark?

In an earlier post I had described as to how unit tests are "dogs that should not bark". Meaning that Unit tests run "All Green" as code is added, modified, refactored. When a unit test fails, prompt action is taken to get back to an "All Green" state.

One situation when "silent dogs" should be a serious concern is when the signature of a function is changed. That means unit test for the function is missing. That means TDD was not followed. That means a Defect in the Process.

Another situation is when a defect is discovered while inspecting the code. A little while back I had experience of that.

It was an expression that computed the radius of a circle given the length of a chord and the distance of the midpoint of the arc from the chord. High school stuff. The expression was correctly worked out in the explanatory documentation. But in the code I forgot to divide the expression by 2. I plugged the function into the module and merrily carried on. The defect was found by a member of the team that I was coaching. I asked for comments from the team. The best answer: "The dog did not bark". I had the satisfaction of knowing my coaching had been effective😊

I had not followed TDD. My Process Had been Defective. 😢

Lesson: No matter how simple the algebraic expression, use TDD to implement the function.

Validation & Verification

Validity & Verity
I am asked. "Did you have lunch today?"

I answer, "Monday."

That answer is invalid. The question has just two valid answers - "Yes" or "No".

If I give one of the valid answers, it does not mean it is the truth (verity). My answer has to be verified.

Validation checks for Validity. Verification checks for Veracity.

Valid Programs & Correct Programs
A C program that can be compiled without errors is a valid C program. Is it a correct program? By executing the program, it can be verified that the program meets its specification. It can be verified that the program is correct. Correct programs are a subset of Valid programs.

Validation Criteria & Quality
What if the compiler options are set to treat all warnings as errors? Now if there are warnings the program will not compile. The program is no longer a valid program. There is nothing to verify.

What if, to successfully check-in code to the version control system, the code must meet Complexity Metrics?

What if the code cannot be checked-in because coding standards are not met?

There is more to qualifying as valid code than just clearing compiler errors.

If you want to improve code quality, enforce stricter validation criteria.

Beautiful Architecture

People eat, sleep, entertain themselves, meet biological needs within physical structures. These structures could be student hostels, barracks, small flats, large flats, bungalows. Each of these have very different architectures. It does not mean that students cannot live in flats, or houses; or that families cannot live in hostels. Its neither convenient, nor efficient. These different architectures cater to groups that have different "processing" needs.

Aircraft hangars and automobile service stations are both meant for maintenance. The "processing" needs are different. Their architecture differs radically; and it is not a matter of scale.

Airports and bus terminals both cater to the transportation of people. The "processing" needs are different. Their architectures are different.

You can operate business establishments and godowns in a palace. Bhagirath Palace is an example. The original architecture was designed for a different purpose. By all accounts it was beautiful. Definitely not beautiful now.

In addition to "processing" needs, there is the matter of values. Design is about trade-offs.Values are used to decide trade-offs. Values decide what is beautiful and what is not. In a residence where should the toilet be? Some three decades ago, I have seen toilets that were separate from the main residence. It reflects a value system. In Chickpet, which is a dense business plus residential area, I have seen a murrah buffalo in the front yard of a multi-storey building. It reflects a value system.

Architects who design buildings must understand both the "processing" needs and the value needs of their customers. Buildings that make the "processing" pleasurable and efficient and meet the values of the customer, have an architecture that is beautiful.

Software architects must understand the "processing" needs of the problem domain. They must also understand the values of good software engineering, the values of stake holders, and the tension between these. To the extent that architecture satisfies the "resulting balance point" of these tensions, it can be said to be beautiful.

An Architectural Story
New Delhi used to have a number of hutments. These were very near the very impressive buildings, on Raisina Hill, that were designed by Lutyens. The hutments were speedily constructed during World War II. They were meant to be temporary and to be torn down after the war. They were shabby, but met the "resulting balance point" at that point in time. Four decades later, most of them were still in use as government offices and family residences. They were hard to live in and hard to work in. Definitely not beautiful.

Some code that I have seen remind me of  "hutment" architecture.

Schooling of Software Architects

In my previous post I briefly described what I understand by software architecture. Software architecture is created by software architects.

When coders writes their first function, they start their schooling as architects. And the schooling continues all through their professional lives as coders. Here's why:

• As more code gets added, complexity increases, code will need to be refactored. If testing is getting complicated code will need to be refactored. Refactoring is architectural work. 
• Which functions are to be hidden and which ones to be made accessible (declared in a .h file) is an architectural issue. 
• Re-organizing functions so that the module (a .c file) has functions that cohere. That is architectural work. 
• Taking corrective action if the Law of Demeter is violated, is architectural work.

Caring about issues of complexity, coherence, coupling, privacy, interfaces, is the behavioral trait of an architect. Coders need to - and can - develop this trait from their earliest days. Coders who lack these traits, though they have decades of experience, are not architects. Putting "Architect" on a business card does not make an architect.

Software architects are not gurus preaching in an ashram. They operate in the heat and the dust of the bazaar. The more remote architects are from code, the more atrophied will be their architectural skills. Unlike building architects, software architects have to start as "brick layers" and "mistrys" (masons) and they must always continue to be competent "brick layers".

Creating architecture calls for judgement. Judgement develops with experience. Learning from one's own experience is a must. But learning from the experience of others - team members and the wider professional community - furthers it. Only a learning organization can be a school for architects. And real architects want to never graduate from school.