Axioms of Software Business

I thought of keeping much grander title (Axioms of Governance), but settled for this provocative one. Addressing a limited (?!) field, namely Software Business, alerts people to stop and watch, as it is the current holy grail, and an accepted failure for many of us, especially me. If, trying to figure out the axioms for any field is tough, for SE Business it is all the more so, and for Governance in general, it is well nigh impossible. Our mind, allows hope, and hence interest, to a certain level of impossibility; beyond that limit we cease to be aroused by promises. All the same, I would like to urge you to give a fresh thought to a seemingly impossible endeavor of axiomatizing Software Business Management. And hence the provocative and promising name. But it can be promising, only if it helps you (and me) in solving our daily management problems, now and in future. For now, I guarantee, with my experience, it is definitely non-trivial in its decisiveness. What are axioms?

I take it, that it has four qualities,

• 1. An axiom should be self-evident. It is trivially true, needing no further explanation, or at least not a too rigorous one, to support it. 'Two points make a straight line', is a well-known axiom in geometry. Yes, this is assumed to be an obvious truth. Obvious in what sense? To whom? We have to start somewhere, and to avoid circular definitions as in dictionary, we have axioms, which are our open statements that, these are our assumptions, and if you accept, then the following follows...

  2. Axioms have to be mutually consistent. Meaning one axiom must not negate another, directly nor through any of its deductions.

  3. Axioms have to be predictive invariants. I think, almost all invariants (or constant factors) of a system is useful, and are the only source of our predictions. All the same, I would like to emphasize this factor, to better aid our imagination in the search for them.

  4. Axioms have to be a decisive finite set. Meaning, there are many truths that are floating around, from time immemorial. In a sense all proverbs are axioms of life. But, the distinctive quality of an axiom, is its finiteness. There is a small set out of all these myriad truths, from which we can deduce all other.

Of course life is a sensual thing, with many facets. But Axioms are concrete, finite and single minded. Hence, there is bound to be some limitations, especially if it is trying to simplify a real life situation, instead of just a mathematical domain like geometry. In sciences, axioms (or assumptions) are called as Laws. But remember, Laws are true only as long as they hold good in reality, in experiments. Once it deviates from observation, either the experiments have to be fine tuned with care, or our laws should change. Whereas it is only axioms that define the domain. So our search for basic truths in Software business is only a search for the laws and not axioms, as these laws do not determine how we do business, it is only what has succeeded and what has not, which is crystallized into laws. Laws are the assumed gist of our understanding. Anyway, I still would like to keep the title as axioms, and not as laws, just to be provocative. The word law, is too hackneyed to arouse interest, with not much difference to warrant a correction.

By the way, a complete set of axioms, or laws, to explain a given domain, is called a Theory. If a theory is new, it is only a Postulate, a Proposed Theory. But when a postulate becomes a theory is controversial, especially in laws, nothing is ever 100% true. Of course a set of axioms in math is always a theory: If it is predictive and useful then it is a useful theory, and if it is not it is useless, but never a non-theory. This article is only trying to find some laws, not the exhaustive list, and hence not proposing a theory.

What is the use of this effort?

I fully understand and strongly believe, as somebody said, A philosophy put in a nut shell, remains there. This is a powerful point. Life is too varied and too grand for any language to fully describe it. All real-life subjects too are that way. So, any attempt to simplify some real-life thing, can only stay useless, unless they are understood as the cues of much deeper understanding, and not as the real thing itself. With that humbleness and caution, theories do have their own importance. After all, human brain is not infinitely capable of handling complexity. Beyond some point, we have to summarize and simplify, to proceed further. This article is only an attempt to find, some of such invariants in the art-science-craft called Software Business Management. If human mind can afford the luxury of conjuring relationships between distant stars and our future, I think it is not too far off to say that there is a strong correlation between one management discipline and another, however technically different they are otherwise. Hence my initial desires to name this article as Axioms of Governance.

In a sense, axioms are like design patterns of Architecture or Object Oriented Programming. The ills of patterns are, that they are neither exhaustive nor disjoint. I mean, neither they claim to give the complete picture, nor they promise to clarify without overlaps. A pattern is a sort of 1½ truth or say 2½... Where, one pattern stop and another start is not always straightforward. The problem with this is that, we are always running around in circles. We cannot be clear enough, in case of dispute, whether one pattern is suitable or the other. Decision-making is that much tougher. To our mind, circular goals are still not as profitable as linear, non-circular ones. We need to know where we start and where we end. I assure you that I DO NOT guarantee non-circularness in the following analysis of invariants of SE. They are not axioms, they may not even be non-circular-laws per se, but they are more than patterns in their decisive distinctness, and they are definitely non-trivial.

A law like ideal for our business, is like the magnetic compass. We obviously need patterns in our path towards the ideal. Like mathematical limits, we only tend towards ideals, never achieve it. But still, this is very important. A seeking mind, after enough experience finds lot of patterns in its thinking and behavior. These patterns are useful, but do not easily form a coherent whole. Slowly, as they sink in, axioms and theories emerge. Say, we know that the highway is in north from where we are, what we need now, is to just keep moving in that direction, allowing some small detour on the way, due to temporary situational hindrances. When we go toward something, the detours are ok, as long as we are headed right. Though you could counter this with hill-climbing principle and all, this is a very practical ideal, in face of complete skepticism. Of course when we are touring the same terrain a second time, we'll be that much less doubtful, and less circuitous.

The Real Introduction

Like many of you, I'm forever intrigued by the goal of creating software, which is on-time and within budget. Even while saying these words I realize the ridiculous impossibility of this task. But I'm desperate enough to try finding some sense in it, as I realize that I'm almost immobilized without it. What is the use of the standards like SEI-CMM, ISO etc. in measuring a company's stature? Or, in improving my own company? Are they of any use at all? How should a boss behave with his subordinate and vice-versa? How should a task be assigned to an employee? How can the Employer be sure that their wards will not return back in the last hour saying that they have not understood the assignment? How can programmers be sure that their managers will not victimize for not doing something which they have not been asked for? What is the difference between the role of an application architect and a project manager? If managers doesn't assign a design properly, or not utilize the developers fully, whose mistake is it?

Whew! These are very very important questions, needing very real solutions. No hand waving, or 'we will handle it when we meet it' type of mentality can save us. Though no day-to-day solution could be given, yet we are too down trodden now: We don't even know in which direction to proceed. In social sciences (leave alone life), maybe we'll never get to have even science like complete laws (forget math like axiomatic certainty). But what we currently have is either an all-encompassing fanaticism, were some daily ritual, which if performed well could get us winning products, or some too distant ethical proverbs like 'clean coding conventions always saves the day' (will they?) or 'good documentation are worth their weight in gold' (are they?).

We need something in-between. Something that is a reliable goal to move towards, and which doesn't dictate or foreclose the situational details, thus making us unusably rigid. Will this something be non-trivial, while not being a complete scientific theory? As a developer, this is what I want. An ideal to work towards, which while not being insensitively inflexible, also assures me that I'm in the right track. I fully well recognize the forces of the need-of-an-hour, that is why I don't want infallible laws, since there isn't any (any law is fallible), but only strong invariants that are worth pondering. My current theories could be completely wrong, but whatever emerges newly, should be hastened by this current one. I think, this is the force that drives us all in finding some non-insane calm ways to go about this enigma called Software Development.

What are standards for?

I mean here standards like SEI-CMM and ISO. If a company is CMM level 5, can we say that they are superior to others? If not, what is that which makes us say that they are not? Before going more into these types of standards, let us just try to see the nature of any standard for that matter. Take for example Java API. Of course, it is not as absolute as that of W3C, but it is a world standard all the same within the Java community at least. What does an API mandate? It says that, what all classes/Interfaces will be there for the programmers to code with, and what are the signatures (The name, the input parameter and the return type) of the methods inside them. It also promises that any vendor who is Java compliant is guaranteed to implement these classes or methods in them.

Can we say that if some 30 vendors are Java compliant, then we cannot say who is the best among them? Of course we can, and it depends on who gives the best performance for the lowest price. Java compliance does not necessarily mean that the vendor is best of his breed, but only that they are mature enough to do business. The confident programmers in the audience, will believe when I say, that any seasoned developer, with enough managerial experience, can deliver a Java implementation, with some help. But that does not qualify them in the marketing race. Because they have no unique selling point. Almost all standard compliance, is only that, compliance, nothing more. Any decent fellow can be compliant, but can be miles away from market success, or performance.

Any organization can be ISO compliant in their process. That only means that they are mature enough to do business. Which also means that almost, everybody who is really interested in business can also be ISO compliant! No mean task, but definitely not a complete indicator of quality or performance. Even a useless product can be manufactured with quality, if it sticks to its specification. That is why, financial company have something called credit ratings, to measure another aspect of their business, which is reliability. Of course their profit is also one another indicator of their performance. Thus, standard compliance is only one facet of a company's performance. Reliability and profitability are other important measures.

Standards: World vs. Company nexus

The truism is that, not all companies that have standards compliance is good enough, and not all good companies have standards. This is valid only because standards are but one indicator of a company's worth, and not everything. Performance and Profitability are equally important. Can we then say that Standards are 50%, and other performances are 50%? Or, say 40-60? No! We cannot. A standard compliant company can still go bankrupt. A technically strong company can still be a pariah to other reliability seeking companies. Goodness doesn't mean strength and vice versa. They are independent qualities. A two dimensional thing cannot be defined in one dimension. A multidimensional quality called worth cannot be fully signified by one facet called standard alone. It is not a question of how much percent it contributes to the total worth. One dimension can be zero and still the whole could be very worthy. Winning is like life, any words to quantify it is forever incomplete, and only is an indicator.

Saying that we need to BE the other person to know them fully does not mean that we can never know them enough. Our mind always tries to find pointers, which with 20% effort, tries to find 80% of the information. So, we digitize the qualities of a company as parameters, and they together tell much more than the parts. The reason the theories are taken with a pinch of salt, is that, the words are only expressions, and we cannot express something completely, what we have hardly understood.

There is an anecdote of Richard Feynman. He once took an hour-long seminar with deep mathematics in physics, to an elite audience which included Einstein. Feynman thought that a small doubt he had in the mathematical derivation would be overseen by the old-timers, who were only traditional physicists. To his amazement, the first question raised by Einstein was the very same error that he made in the derivation. Feynman, visibly stunned, queried, how someone could go so fast into all these calculation, and find that error? Einstein replied that, a good physicist thinks, not in terms of math, but in physical sensations. Math is only an expression. However you express a physical reality in math or other forms, a mind tuned to the reality beneath, will always find it. I have an uneasy feeling that this anecdote might be a complete hoax, are inaccurate at least. But the message is powerful and worthy. Life is too too complex for any one way of expression. A sensation, a philosophy, a quality can be expressed in many words, and still not be anywhere near realization for the audience. Our attempt in standards is not that at all, we just want to measure few things to indicate with strong probability that someone or something is worthy enough in that sense. A quality standard is only one variable in the multi dimensional reality called the corporate success.

The Boss is Everything

This is contrary to what Bill Gates said 4-5 years before, that the days of freelance development success is gone; now is the age of corporate mega collaboration. I myself have seen JBoss's success from scrape. Maybe OpenSource is a complete new phenomenon to compare. All the same, the heroics of the leader are irreplaceable. Even now Gate's control and quality over his organization is more due to his legendary stature and respect for his achievements, and not just a positional reverence. The days of single human heroics are not over yet, nor ever will be. In many ways, any standard or any performance metrics is useless for improving a company's stature! A already well-run organization is not much benefited by standard compliance as it is superfluous, and a standard's goal is not to improve a non-standard organization. A standard's purpose is to certify that you are good, but not to make you good. The company, which fails to understand this, looses more in this misplaced anticipation and expenses. A standard is to certify, and certification is to marketing. Of course for an almost standard organization, certification can help in providing that fillip, that is required by it to rise to that next level of excellence.

It is very important for developers to understand that, no amount of CMM and other things can help them become standardized or more efficient. In fact being a standard organization is the precondition for being certified with that standard. Of course, there are ways, even legal ways, to get standards certification even without being that quality. However stringent a standards be this can always happen. However tough an examination is, it can always fail to single out a creative thinker. An exam could narrow the possibility, but the differences will ever be. I think it is the people's mentality of comparing an exam to school, and hence think that and exam could improve them. It can only prove, not improve (Rhyme intended). A standard certification is not a school. Its intention is not to teach. If by seeing the question paper or the answers to that you can be educated, then we don't need schools. If even coaching cannot make creativity certain, will certification do that? Only introspection, and study and conscious practice can ensure excellence. First, the standards certification is not a school, and even schools are not fully successful in ensuring success. So, don't disrespect your hunches and special strengths in search for a globalized standard. Instead of gaining you might be loosing something in the process.

Who is the best boss?

I hope, in defining the best boss, we almost define the best subordinate too. There are many aspects in the employer-employee relationship. We'll try each one separately. Firstly, a blunt one: Should the boss know each and every activity? The answer could only be an unqualified YES. You could say that some people do survive without knowing everything, but they do just that, survive. A debacle is always pending. Of course if the employer and employee are experts in their own, equally important fields, they can only behave as peers. The degrees to which one is superior over the other, is the hint, to the degree to which they must collaborate or be bossy. The following ideas are same either way.

One, to demand conformance and trust, and secondly to understand the process enough, so as to be able to assign it to somebody, a boss has to be capable of doing the thing, before giving it to others. Why a job is delegated to lower levels is due to many reasons. Either due to more important work or due to lack of total expertise. The second point is interesting. A subordinate should ideally be an expert in something, which the boss can only accomplish slowly alone. Because of this division of labor, a employee could be more skillful than the boss. Yet, the boss should know it enough, so as to be capable of doing it alone. This is what keeps the employee under control. The boss's superior strength comes from his broader knowledge about different fields, and the clear understanding of the interfaces between the fields.

Unless a boss knows enough, how can he be calm if the employee stumbles? If he is not himself clear, his only reaction on an employee's failure is either victimization or anger. But if the boss is clear what he wants and knows how to do that, he would just discard the useless employee with equanimity, or would offer key help, knowing their problem. After all that is why we need a boss. What is the use of a boss, who incapably depends on an employee for an idea and even victimize for not being good enough? There is a sharp difference between delegating something, and stealing. You can never ever replace the maxim of Leading by Example.

Ills of communication

Fine, now let us assume that there is no stealth involved. Say, the boss is well meaning and qualified, how can he now ensure that the job he assigns to his subordinate is understood fully by them? Assume too that the employee is skillful enough to complete, if only he understands what is required of him. Of course having a common language like UML or some such thing would trivially simplify the issue. But that is not usually the reality. Is there no recourse?

The usual practice is in two ways. Either the manager assigns the job to the workers in writing, and expects them to understand it correctly. Or they ask the developers to write up the initial document on which they can decide. Both are potentially dangerous, BUT not always. If the organization is big enough they cannot do anything else but to give the assignment in writing, unequivocally. Even here, there should be a common language, known by all, before this one-way top-down flow can be successful, if not there is every danger of misunderstanding by the developer, and consequent last minute hand-wriggling. Similarly, if the manager is not knowledged enough, asking for a proposal can only mean inability of the boss and consequent victimization. Even if this is not the case, if the boss is well-meaning, but the employee is not strong enough to initiate the process, again frustration results. One-way communication of assignment can only succeed in the happy accidents of either there exists a common language of communication, or that the developer is remarkably intelligent and on his way to his own personal glory (beyond even his boss).

How to ensure useful communication?

For all other small to medium scale enterprise (maybe even in a big organization with a thin and deep hierarchy), the best way is a two-way negotiation of job assignment. Of course we assume that neither the employee is a dull head nor that they are completely unexpressive; in both of those cases special training should precede the commencement of any transaction (else, the manager can always fire them and hire someone with at least basic skill set). What is interesting is, if the developer were skilled enough that they would only do something if only they understood it, and not so skill full that they can initiate the process completely on their own.

You must understand all these discussion is not some autocratic situation where we are training some maharaja how to rule. What holds for a upper level manager, holds good for the lower management too, and all the way from the CEO to the lowest manager. I think the only option left for the lowest developer is, if he knows the boss's worth, to follow it to the word, or gets promoted at the soonest. Similarly 'asking for the proposal is bad' only means in the general sense that one is asked for more than what he is hired for. There are many positions where the nature of the job itself needs initiation from the lower cadre, and the boss himself is skillful in that. The condition is just that there is no point in assigning something more than a developer could chew.

Two-way communication, meaning? I'm allergic to excessive documentation or paper work (or say e-paper work). But at the same time, I do realize the dire need for documented job assignment, for two reasons. One is to ensure that I track people's work, and two I ensure that my assignment is clear to the receiver. We have seen that one-way assignment is potentially failure prone, so how else to bring about negotiation? For want of better name, I call it as MoU (Memorandum of Understanding). The idea that the manager give in writing the assignment to the wards is a too centralized a load to the manager. Instead, if the developer is asked to write the assignment and get it approved, after a brief prelude of hand waving and explanation, then it is very useful.

MoU: Memorandum of Understanding

MoU nullifies two fears. One, employee is assured that the onus of job chunk's relevance is squarely on the employer. Secondly, the employer is assured that whatever he wants to accomplish is well communicated. Because, an oral start (maybe with some associated material tips too) and a consequent written reply from the developer means that the whole idea has gone into the mind of the developer and has come out in a concrete acceptable form. What better proof is there beyond this for ensuring negotiation? I prefer minimal infrastructural efforts and maximum productive work. MoU ensures that.

Architecture Design and Job Assignment

The goal of designing a solution, is two-fold. One, to meet the requirement, of course. And two, to maximize the possibility of parallel development through modularity. I think the second is not recognized in such explicit terms. To make it bit more dramatic, the abstract time line and abstract job assignment, should be furnished only by the architectural team, and not some non-technical project manager. How could the managers know the possibility of parallelism in the design? Their role is only supportive. Their job is to make the timeline concrete with exact dates, and the job assignment concrete with exact names, and then ensure that all these go along smoothly, and the real-time problems are properly abstracted and given to the architect team for solution. This is the only way that introverts and extroverts can coexist. People with mixture of both can be the nexus people (spokespersons) or the manger of the whole project.

After all, Software business is a knowledge business, both the boss and the team thrive by their expertise. Every non-technical staff, should realize their supportive role and symbiotically coexist. Be very clear, that without the product and its strength there is nothing to sell. Right from the requirements to release, the architect should be involved and suitably supported. They in turn should make their demands and proceeding in clear unambiguous terms.

The Epilogue

The project succeeds or fails purely because of the chief architect's management. And this management itself is dependent on the parallelized architecture of the project. Which in turn depends on the proper and complete understanding of the requirement of that phase of development. There are of course, many more angles to be considered but this remains the core of the whole process.

Of course, this is not any final word, but definitely good enough directions for me to start with. What I started for was a reference point, which can give me some bearing in the day-to-day compromises. That I think is there now. Yes, there are many important details hanging in looses strands, which I hope can be tidied up, with the more help and experience.