Management Anatomy

Whenever Ogilvy was hiring a new manager for a new office in a new country, he sent two numbered envelopes and a Matroska puppet (this Russian puppet is an empty wooden shell which you can open it (like a Kinder Egg) and you will find inside of it yet another, smaller puppet. You can open that second puppet and you will find inside a third one… and so on).

Ogilvy was asking the new manager to open the first envelope with the instructions of opening the Matroska puppet, including all subsequent puppets and align them, than open the second envelope.

The second envelope had the following message inside:

“If you will hire smaller people than you, we will become the company of the dwarfs. If you hire people greater than you, soon we will become the company of the giants.”

Are you seeking for more efficiency in the software development process? is your target also to do more with less. Here's a YAT (Yet Another Technique), to reduce cost dumped in the process. 

Let me take you in a short introductory trip before:

Recently I've started to learn German language. The basic concept of conjugation of the verbs is simple. Let's take the verb spielen (playing) as an example:

Ich spiele (I'm playing)

Du spielst (You're playing)

Er/sie/es spielt (He/She is playing)

So, you can draw the simple conclusion - you take the root of the verb (spiel) and you follow some sample rules, like: in 1st person you add the -e as termination, in the 2d person you need the -st termination, while in 3rd person you will add the -t termination.

Like this, you could continue with another verb: arbeiten (working). So:

Ich arbeite

Du arbeitest

Er/sie/es arbeitst

Simple enough? see, we are one step closer to speak German :) But wait a minute... let's use our new knowledge and take the verb "dürfen" (may - to be free to do something):

Ich dürfe, Du dürfst, Er/sie/es dürft?!? - the answer is: no. Unfortunately this is an irregular verb, so the rule listed above doesn't apply here. Here how you are conjugating:

Ich darf

Du darfst

Er/sie/es darf

:( - nothing to do with the knowledge we collected before. So what rule applies to the irregular verbs... none: that's why they're called irregular (there's no common convention what to do with them). 

So what I can do with the conjugation of irregular verbs as a beginner of German language? Nothing more, than learn all of them by hard.

So my learning process will be extended and longer that I expected? The answer is yes!

The same applies for software system which is reinventing its own rules for each and every module... one can not learn a rule and apply it in multiple places (multiple modules of the system), but needs to learn the specific aspects of all parts.

I'll give you a few open questions:

how much additional unit testing you need for non-standard components?

how much more you need to do documentation for non-standard components?

Customer Perceived Value is a term used in marketing, which describes a simple concept: the value of a product for us (as a customer) is calculated according to the formula

Value = Benefits / Cost.

In order to design a successful product you'd increase the benefits and reduce the costs.

Simple enough you'd say... but let's look on the components.

Costs: what are the costs? the price of the product? what if it's free? or what if users do choose the competitor despite the fact we are cheaper?

Costs consists of multiple elements: yes, there's a monetary costs (how much I need to pay for), but there's also a time cost (how much time I need to invest to acquire or how), energy cost (how much do I need to invest in learning), psychic cost (how simple is to use).

Benefits: product value (which of my problem solves the product), service value (how happy I am with the customer support), image value (how do I look in the eyes of my peers if I am using this product).

In the era of rapid technology evolution, it is not the biggest that survives, but the fastest (Lean Software Development).

Half of the software development efforts (and budgets) are consumed by quality assurance (QA) processes (unit testing, system testing and acceptance testing). One third of the development is about planning and only one sixth is about actual implementation (coding).

In other words: while the creative process takes about the half of the time, the other half is about sorting out the mistakes from this initial effort. That’s why is important to recognize, that quality assurance starts at the planning phase. If the software architecture is lean and clean it will probably be cheap to maintain.

So how to make it lean and clean?

Ubiquitous domain language is one way to proceed. Does it sounds like a hype expression? for sure. Let me simplify: use simple, straightforward terms, do not let to proceed with a concept which is not understood by every team member in the first 10 seconds. (Remember? every 10 % of complexity in the domain model adds 100% complexity in the overall development process).

Teach your team about TCO (Total Cost Of Ownership): show them what’s the cost of maintenance. Help them to adopt KISS.

Adopt agile methods: re-factoring for keeping simplicity, clarity, minimum amount of features in the code.

Or in other words: "Think big, act small, fail fast; learn rapidly" – these slogans summarize the importance of understanding the field and the suitability of implementing lean principles along the whole software development process.

Key Performance Indicators are a good way to communicate expectations and evaluate performance in an organization. But how to select the ones for a software development team: software development is much a research-like activity with rarely predictable performance ratios.

Which quantitative indicators to be chosen? Is it the low number of software bugs? compared to what or whom? what if the project is a large one? if specifications are loose?

Lines of code? wouldn't be against  basic OO and code re-usability principles? sure it would.

Number of change requests fulfilled during a standard unit of time? how do you standardize and measure change request complexity?

Projects finished on time, on budget? well, according to the statistics, at least 60% of software projects are failing in one way or another (usually due to heavy underestimation).

After a few years of experimentation I've chosen the followings:

Availability and No SLA breaches;

EBIDTA per employee;

No task delivered without following the Definition Of Done guide;