Humility

The strength in Humility is grossly underestimated. When realised Humility allows harnessing the best in others.

Vibe

It is a mistake to undermine specialisation in a team. Everybody has a different vibe that drives best in them. A good leader seeks to exploit vibes that collectively make the harmony in a team.

Minimum Viable Product

M in MVP is the only variable. You may vary M to buy time to market in exchange of nice to haves. But the lure of profit can be blinding as you may find it tempting to touch V which will ruin sacrifices made in M.

Team Branding

Since the dawn of Humanity tribes used the contemporary concept of “branding”. The tribe had its own dress-code, totems, songs, dances, icons and signs. Branding allowed them to claim their territory and enjoy a secure sense of belonging. It led to stronger tribal bonding that increased their chance of survival in the wild.

Nothing much changed in modern corporates. Same concept. The modern businesses use branding to secure their competitive position.

But why stop there?

Agile teams around the globe perhaps instinctively employ similar tools in order to strengthen member bonding and team presence. The coffee meeting surely is a tribal meeting, so as having a geeky team name and logo.

One aspect of team branding however may not be so obvious and that is its effect on Engagement. I strongly feel the security provided by tribal bonding has a big effect on Engagement.

Letting the team continuously maintain and strengthen their branding can be a smart win for the organisation. Let them have a newsletter, let them have a billboard, let them have t-shirts with team logos, let them organise meet-ups, hackathons and watch how heavily they will be engaged.

Junk Code

The human genome contains three billion base pairs, the DNA letters in which the code of life is written. Yet only a tiny proportion of these letters -no more than 2 per cent- are actually used to write our 21,500 or so genes. The remainder, which makes none of the proteins that drive the chemical reactions of life, has long been something of a mystery. Its apparent lack of function has led it to be dubbed 'junk DNA'.

Much of our junk DNA has origins that have been relatively simple to establish. A very large part of it belonged originally to viruses, which have incorporated their own genetic codes into our genome in order to reproduce.

The legacy of our viral ancestors can also be seen in so-called retrotransposons. These repetitive chunks of DNA, which were originally deposited by viruses, have the ability to copy themselves into the human genome again and again, using an enzyme called transcriptase.

In some ways, the continued presence of this junk DNA is not surprising: DNA is 'selfish', and will replicate itself regardless of utility to its host organism. But for it to withstand natural selection, some of it must surely be functional.

Software made by humans is like synthetic DNA. Remarkably junk code also exists in software systems made by us. In fact in evolutionary design methodologies such as Scrum it seems more likely that imperfect code being copied to incoming generations of software.

Scrum sprints typically follow a short 4-6 week iteration pattern. In Scrum the focus is on delivery, therefore junk code may get more chance of being copied compared to quality focused methodologies.

I don't think however junk code makes evolutionary methodologies less successful. The advantages of being agile has more survival value than less adaptive quality driven methodologies.

Consider this real life example:

Sprint1 in Project P ends, the architect A approaches the developer D.

A- Hey.. Something drew my attention, you guys hard-coded the magic-token in your module. Whereas there is a common function in our library which you should have used to retrieve the magic-token. How come this happened?

D- Oh. We've just cut and pasted the code from project Q. They also used the hard coded magic-token.

A- Ahh. I see. Damn. They should have used the library too. I wonder how we may clean up this mess.

D- I can fix this easily now in project P.

A- No, wait.. Fix it in the next sprint. I'll talk to other teams see if I can get them fix their code too.

As you probably guessed the hard-coded magic-token in this example is junk code. Like Junk DNA it possesses a powerful intrinsic ability to get itself copied into other projects/sprints i.e. other generations of code (perhaps because people find it more reassuring to use magic-tokens than using functions returning them). It seems despite A's intention to clean up the code once and for all, in practice it may be logistically not viable and quite expensive to clean up dozens of other projects' code across all versions from this viral but relatively harmless junk code. So it is likely that the fix will only be made in project P (provided that it is remembered in sprint2), and the viral code will continue to survive.

Evolutionary design in software systems is remarkably similar to evolution by natural selection. More importantly in software projects aiming at perfect design would almost certainly limit software's adaptive power and consequently diminish its competitive value.

References:
50 Genetic Ideas, Mark Henderson
Parasitism, Wikipedia
Agile Software Development, Wikipedia
Agile/Scrum Development, Wikipedia

Imperfect Design

Is there such a thing called perfect design?

Time and time again the global software industry failed to deliver designs that worked in good order, delivered on time and within budget. Many projects failed either because they performed poorly, did not meet user expectations or they could not catch up with technological momentum.

There are historical reasons why software engineering projects failed more often than other types of engineering projects. In the past thirty years immense market demand on software as a result of exponential growth of cheaper synthetic memory availability (Moore's Law) created an avalanche effect known as the PC revolution. The tidal wave effects of the PC Revolution was immense and widespread. It did not stop at households. The collapse of the Mainframe Computer and consequent emergence of vast IP networks in the corporate landscape quickly followed. On top of that the Internet Revolution that emerged in the last two decades pushed competition to unprecedented levels.

Historical developments aside software engineering is also very different by its nature. Most notably software engineering blueprints are thousands sometimes millions of lines of code that can easily be erroneously constructed or ill-configured, inducing defects with much less chance of being detected due to difficulties of human brain comprehending code as opposed to say a suspension bridge blueprint. In addition there are vast number of mathematical possibilities in which you can construct a software program. It is like infinitely many and sometimes irregular ways of cutting a jigsaw puzzle, then recycling the pieces to make more puzzles.

So software engineering is a difficult discipline. Due to the factors we described above standard development and management practices of other engineering disciplines did not work out well when applied to software development. This led to emergence of the Open Source movement, and more dynamic development methodologies such as XP (eXtreme Programming) and Agile in the past decade or so.

What is common in these novel practices is that products are collaboratively, adaptively and continuously designed, developed and deployed in iterative cycles. Design evolves over time similar to biological evolution of species by Natural Selection.

In Nature no species is perfect at any given time. In successive and many generations species simply adapt to changing conditions or fail to adapt and become extinct. There is no perfection that warrants indefinite survival but a continuum of struggle we call survival by adaptation. There is no concept of an upfront design or designer yet alone a perfect one, in fact there is no beginning or end in the design process, design evolves indefinitely so long as it survives Nature's scrutiny.

Similarly in many Open Source projects there is no centralized vision of design (akin to Blind Watchmaker analogy). The design evolves by itself without a designer. Everyday thousands of coders worldwide collaborate on different parts of hundreds of software products similar to gene coalitions established within our cells. There is no seek for perfection, akin to the fact that perfection does not exist in Mother Nature. Resources can be deployed and utilized more efficiently by allowing mistakes rather than chasing an impossible Platonic vision of perfect design. In return product versions are released at a much faster rate with greater chance of seizing survival opportunities when they are exposed to users' scrutiny. This process is called Evolutionary Design.

To show my point lets look at Mother Nature's design process and see how imperfect it can be. The following is one of countless examples of faulty designs we inherit from our vertebrate lineage.

In this extract from The Blind Watchmaker, Richard Dawkins talks about how imperfect our eyes are from design perspective. Somewhere along the evolution of vertebrates a group of genes might have been copied in error but in a way not enough to jeopardize emergence of our species millions of years later.

"My second example of an evolutionary progression ... concerns the retina of our eyes (and all other vertebrates). Like any nerve, the optic nerve is a trunk cable, a bundle of separate 'insulated' wires, in this case about three million of them. Each of the three million wires leads from one cell in the retina to the brain. You can think of them as the wires leading from a bank of three million photocells (actually three million relay stations gathering information from an even larger number of photocells) to the computer that is to process the information in the brain. They are gathered together from all over the retina into a single bundle, which is the optic nerve for that eye.

Any engineer would naturally assume that the photocells would point towards the light, with their wires leading backwards towards the brain. He would laugh at any suggestion that the photocells might point away from the light, with their wires departing on the side nearest the light. Yet this is exactly what happens in all vertebrate retinas. Each photocell is, in effect, wired in backwards, with its wire sticking out on the side nearest the light. The wire has to travel over the surface of the retina, to a point where it dives through a hole in the retina (the so-called 'blind spot') to join the optic nerve. This means that the light, instead of being granted an unrestricted passage to the photocells, has to pass through a forest of connecting wires, presumably suffering at least some attenuation and distortion (actually probably not much but, still, it is the principle of the thing that would offend any tidy-minded engineer!)."

Evolutionary Design will continue to change the software engineering practice in a profound way. We will see fitter and better products emerging, satisfying complex and varying needs of demanding consumers.

On the other hand today software engineers must come into terms with the concept of imperfect design or design without a designer. This is a completely novel mindset that developers need to understand and adapt. In the Evolutionary Design era catching up adaptation cycles and focusing on delivery is far more important than chasing up an ideal design that warrants failure.

Beta is Reality

I have just posted the following response to Andrew Keen's article It's Time to Bust the Beta Cult in the Internet Evolution.

Beta is Reality

Should there be such a thing called finished product?

The era of software products designed behind closed doors without dynamic user involvement is over.

a) It costs too much to develop a finished product, especially for startups, yet alone I argue that the concept of finished product is an illusion, products are never finished, and should not be finished.

b) It is too risky to ignore user feedback during development. The chances are you will be increasingly drifted away from user satisfaction. There is no way you would know what users want unless you design your product with them.

c) Increasingly users want to get involved once they experience the satisfaction of being listened. User profiles are changing, the era of passive user is over.

This is in fact what I call the evolutionary design, a concept akin to natural selection we observe in biological systems. The product evolves based on its survival value; its ability to adopt changing user requirements. In fact there is no up-front designer. Users become the nature, and they themselves design the product by selecting the fittest, fittest in terms of giving them the best satisfaction score.

The design by natural selection does not need to be perfect or completely bug free. Take the evolution of human eye for example, which is a strikingly good example to bad design, if there were an up-front designer.

"The vertebrate eye, is built "backwards and upside down", requiring "photons of light to travel through the cornea, lens, aquaeous fluid, blood vessels, ganglion cells, amacrine cells, horizontal cells, and bipolar cells before they reach the light-sensitive rods and cones that transduce the light signal into neural impulses – which are then sent to the visual cortex at the back of the brain for processing into meaningful patterns." This reduction in efficiency may be countered by the formation of a reflective layer, the tapetum, behind the retina. Light which is not absorbed by the retina on the first pass may bounce back and be detected.", ref. Wikipedia.

The beta paradigm represents evolutionary generations. Each generation, i.e. each beta life cycle changes the product's survival value, sometimes towards the extinction end, other times towards the selection end, and the reality is you would never know up-front whether your product be extinct or survive in x years time. Except that users (the nature) will survive even if it means they may end up selecting and using a different product, not yours which might have become extinct.

Therefore it seems to me that the evolutionary design (hence the beta concept) in software systems is here to stay. We humans have discovered and learned the power of natural selection in the past 150 years, why shouldn't we enjoy exploiting and using that power in commerce and in other areas of human ingenuity.

Finally, I am also thinking Beta as a meme, ie. "a postulated unit or element of cultural ideas, symbols or practices, and is transmitted from one mind to another through speech, gestures, rituals, or other imitable phenomena.", ref. Wikipedia.