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.

Sudoku

Remarkably the evolutionary algorithm I developed for Eight Queens problem worked without modification for sudoku problem. The only differences were array size (DNA) and the fitness function.

This is perhaps not so surprising considering how evolution creates vastly different species (solutions) for different environmental conditions (problems).

Here is the pseudo-code of Evolutionary Algorithm:

Here is a diagrammatic representation:

It is simple really. You have a pool of population which is made of many solutions. At each iteration select fit parents, recombine their genes and allow mutation to make 2 distinct children. Sort the population by fitness score. Let the worst 2 die, and continue iteration until the best fit is found.

In the Eight Queens problem, from the chess-board, the array size is 8x8 = 64, whereas in Sudoku it is 9x9 = 81.

The fitness function calculates a positive number which increases with the level of fitness.

Usually the worst fit solution is calculable. In the case of Sudoku this is one of the worst solutions:

[1, 2, 3, 4, 5, 6, 7, 8, 9]
[1, 2, 3, 4, 5, 6, 7, 8, 9]
[1, 2, 3, 4, 5, 6, 7, 8, 9]
[1, 2, 3, 4, 5, 6, 7, 8, 9]
[1, 2, 3, 4, 5, 6, 7, 8, 9]
[1, 2, 3, 4, 5, 6, 7, 8, 9]
[1, 2, 3, 4, 5, 6, 7, 8, 9]
[1, 2, 3, 4, 5, 6, 7, 8, 9]
[1, 2, 3, 4, 5, 6, 7, 8, 9]
 
This is not even a legal acceptable final solution is Sudoku. But any solution in evolutionary landscape is legally born. When an individual solution's fitness is calculated it may or may not survive the next run (generation).

A perfectly fit Sudoku solution is achieved when all 1-9 digits present in 3x3 matrices along with no-clashing digits present across rows or columns.

Therefore in Sudoku the unfitness score is a number calculated by counting number of times a given digit is repeated across a row or a column and also adding the missing set of digits in all 3x3 sub-matrices.

The resultant fitness score is normalised form of unfitness score, i.e. fitness score is calculated by subtracting the calculated unfitness score from the maximum unfitness score (378).

Two runs from a typical output are given below:

-----------------------------------------
Run: 1
Best score 378
Found best '1' in 3540 iterations.
[4, 1, 3, 9, 8, 6, 2, 5, 7]
[7, 2, 9, 5, 3, 4, 8, 1, 6]
[6, 5, 8, 2, 1, 7, 3, 9, 4]
[2, 3, 7, 4, 5, 8, 9, 6, 1]
[8, 6, 4, 1, 2, 9, 5, 7, 3]
[1, 9, 5, 6, 7, 3, 4, 2, 8]
[9, 4, 2, 8, 6, 1, 7, 3, 5]
[3, 8, 6, 7, 9, 5, 1, 4, 2]
[5, 7, 1, 3, 4, 2, 6, 8, 9]
-----------------------------------------
Run: 2
Best score 378
Found best '1' in 8636 iterations.
[2, 7, 5, 3, 9, 4, 8, 6, 1]
[8, 1, 3, 5, 2, 6, 7, 9, 4]
[9, 6, 4, 8, 1, 7, 2, 5, 3]
[4, 2, 6, 9, 8, 3, 1, 7, 5]
[1, 8, 7, 2, 4, 5, 9, 3, 6]
[3, 5, 9, 6, 7, 1, 4, 2, 8]
[5, 4, 1, 7, 3, 2, 6, 8, 9]
[6, 9, 2, 1, 5, 8, 3, 4, 7]
[7, 3, 8, 4, 6, 9, 5, 1, 2]
...

I still have to tune the program for better performance. I may try different mutation or recombination strategies, play with population sizes and selection strategies to shorten the time required to create a sudoku solution.

The prototype was written in Python. Eventually I would like to port the algorithm to IOS 7 for creating the sexiest sudoku app ever.

The Evolutionary Algorithm I used was from the book Introduction to Evolutionary Computing¹.

References:
1. Introduction to Evolutionary Computing, Agoston E. Eiben, J.E. Smith, Springer, 01/01/2003
2. Sudoku - Wikipedia
3. Eight Queens - Wikipedia

User Interface Development Tips

My over two decades long background is in real-time/server side programming. 


Nowadays I am working almost entirely on GUI products. I am building a Visual Studio like IDE at work. On the other hand MiniBluebox, the home-grown project I develop part-time also involves user interface design.

For years I had the usual conviction that "GUI programming is dumb". But I found that it is actually the opposite. It is equally hard if not harder than server side programming, not necessarily in programming terms though.

The hardest bit may involve a mindset change, a realisation in full humbleness that no matter how smart you are, your usability perception as a developer is a much smaller component than what users usability expectations are. 

You need to get interaction design right, and that often involves user engagement. It is not something you can imagine and expect it to work for everyone.

The ultimate tips I may disclose are, 

1. Get as many field trials as possible. Be humble and let users be brutal in their criticism. Make sure your product website attracts feedback from users. Be an observant and listener. Try to understand what makes them happy or stressed out and then groom out the UI accordingly.
2. There may be tensions between usability and performance. Almost always favor usability if performance penalty is bearable.
3. Don't be scared of cutting out controls. Think this way if I remove this button or replace it with a slider control what would happen. Would that make my user happier. 
4. Make sure to sketch out user personas. Will plumbers, house-wives, executives, game players be using your product. What is the persona or personality that will likely be using your product. There will always be tensions between their usability expectations. You need to come up with a persona that would serve all of them reasonably well. But your persona may be dominated by just one of them. This is more of an art form or a Director's job than a Developer's it may sound. But it is the extra mile that would make a difference. Draw cartoons of him/her. Try to imagine them in their daily life. Try to imagine them, what is crossing their mind, when they sit down before they start your program.

Finally my best kept secret is this and rather than being a mere tip deserves to stand on its own right:

Your ultimate design criterium should be to make users happy about themselves when using your product. They shouldn't feel stupid or unconfident.

Evocom

I have been quiet for a while totally immersed myself into evolutionary computing.

I have developed a computer program named evocom to solve The Eight Queens Problem. I have also written a paper quantitively analysing and demonstrating fundamental aspects of biological evolution.

You can download evocom program and related paper at:

http://members.iinet.net.au/~coruh/evocom/

I have used great open source tools and free products in my work. Here they are:

• TextWrangler : A brilliant text editor for Mac. Simple, fast, reliable, user friendly, got syntax-coloring.
• Python: Mac comes with Python, free to download for Windows at http://www.python.org/
• LaTeX: LaTeX is a high-quality typesetting system; it includes features designed for the production of technical and scientific documentation. LaTeX is the de facto standard for the communication and publication of scientific documents.
• TeXShop: Award winning LaTeX editor for Mac, robust, simple, easy to use, reliable.

RIP Google Wave

Google Wave, an online collaboration platform in its infancy is dead.

Broadly speaking the main issue with GW was ‘poor usability’.

GW was too stressful to use.

Consider this. If more than two people are talking to each other face to face you will notice that the quality of communication rapidly degrades as number of people increases.

Now imagine same group of people, trying to maintain an online conversation using a tool like GW. They would be struggling to think, comprehend, scroll to see the newest message, type their own message, cut and paste a video link, copy an image, hack each other’s sentences with simultaneous editing.

Geeks might like that. But not everyone would like that.

Way too many interactions. Way too many distractions on the screen.

GW screen looked like a glorious billboard as if designed for maximum distraction. Well who wants to be distracted while communicating?

I mentioned this before:

"We became gadget-obsessed anxiety-driven freaks and our urban society is running on a short attention span culture.

Just about everybody, every hardware device, and every software on the Internet is desperately trying to grab the shortest possible time span dedicated to comprehension and expression."

Therefore I believe new collaboration tools must make every effort to take stress out from the environment.

Fundamentals

I returned to fundamentals. I started to follow computer science (CS) courses at MIT. 

MIT has a great program called MIT OpenCourseWare and it is free. Lecture videos are available from uTunes. uTunes is embedded iTunes portal which makes it easier to collate course material in one place.

The following snapshot shows a portion of my desktop.

I have course video at the top, a Python script edited with iMac’s Pico editor in the middle, and the output screen at the bottom. I also have course presentation in pdf document form and browser windows in other areas of my screen. 

It is great fun, probably more fun than sitting in a classroom. I can pause the video and do a bit of programming or research on the web then get back to course. 

It is also a fantastic activity to return to fundamentals of algorithms. Being a seasoned programmer allows me to focus purely on mathematics and analysis of algorithms.

My long therm objective is to study evolutionary algorithms and perhaps write a program to simulate evolutionary systems.

Skeinforce

Well it all started with iMac. Hypnotised with its beauty we bought one in May last year. One problem we had was our password management program Zippylock was Windows only and required .NET. I know this because I know who wrote it (bloggerboy)!

Earlier my mate Ricardo showed me a wrapper he wrote around Skein hash functions which grabbed my attention. Skein is a piece of beauty. Well it is small, coded in C, portable, very fast, and very powerful. You can go up to 1024-bit encryption with Skein. Behind Skein there is a good-looking team of security gurus and my security idol Bruce Schneier.

So I said OK. How about I write a little utility like Zippylock, this time x-platform though. So I wanted a x-platform GUI and x-platform compatible binary serialisation with locale support. What this means in short, I wanted to be able to transform my database file across Windows and Mac. Say I come to work, and enrol to a new professional forum. Then I add my user credentials into the database, save the database file in my USB drive, and use it on my iMac at home.

I also wanted to have a much simpler user interface. So the idea of designing something like Google suggest popped up. Google suggest has been introduced by Google recently, you know the thing, as you type you see a list of most popular options and the list narrows down with your typing.

Miraculously the x-platform development kit Qt from Nokia had a sample code of a widget on Google suggest metaphor.

I kicked off project Skeinforce here in Negative Matter on the 18 November 2009. Luckily all pieces of the jigsaw puzzle joined well and I've just finished the project earlier than I anticipated. It was great fun despite my wife’s fair protests of me neglecting house work and not communicating (as always she was right.)

Along the way I learned Qt (what a brilliant toolkit!), kept my programming mojo alive (I can’t live without coding), learned a few Unix and Mac tricks and in the end I had a nice little utility that I dreamed for. I guess the best part of being a developer (who doesn’t have kids;) you can design your own thing.

Anyway this is a free tool, and could be useful to many. You can download it from the following location (I'll also make the source code available soon.) Feedbacks are welcome.

http://members.iinet.net.au/~coruh/skeinforce/

Project Skeinforce

I am kicking off an ambitious fun project code named Skeinforce.

I set up the following blog for managing the project:

http://skeinforce.blogspot.com/

This means I will be writing less for Negative Matter.

Forgetful Loops

Consider a software algorithm that builds a tree in a computer program. Typically when you build a tree you would have a recursive loop in which tree nodes are created and connected. The loop will have an entry and an exit point.

You might also recycle the same tree builder algorithm to build a parallel tree, an almost identical tree with only its target context being different. For example tree1 is supposed to be an observer of explorer style representation, whereas tree2 observes a column based representation. So the nodes of each tree might have a different type, their properties are determined and their behavior are dictated by the context they live in.

Let us now assume that we are living in a universe U_R.

One way of comprehending our universe is thinking of it as a gigantic Hilbert Space. A vector-space that represents the state-spaces of quantum mechanical systems is also a Hilbert Space.

Think about every atomic particle that makes you, they have a certain position and momentum at any given time, i.e. they can be represented as vectors. And when I say 'at any given time' I mean the time of our vector space. Together with other quantum mechanical systems, such as the coffee mug, the earth, the sun, the milky way galaxy and so on, we are all part of one big vector space.

Another way of visualizing our universe is thinking it as a space-time sheet or fabric, on which every vector stays on the same fabric, moving in random directions and changing their magnitude all the time.

Returning back to our tree building problem, there is no reason why you would not build parallel trees by running the tree-builder algorithm sequentially, so you build the tree1 first followed by the tree2 and so forth.

After all our program runs in the realm of our universe, in the same space-time fabric. So the loops building these trees would occupy different localities on our universe's space-time since they are built at different times, nevertheless they lie on the same sheet of space-time.

Suppose now that there is a glitch in your program so that while executing the first loop to build tree1, the program suddenly switches its context, enters into the second loop and starts building tree2.

You may be surprised to find that when the program finishes building the second tree, and returns control to the loop of tree1, instead of the iteration continues where it left, it might leave the loop prematurely with tree1 left incomplete.

Suppose also that the glitch causing your program to suddenly leave the first loop at the first place is not avoidable. This also implies that your trees are NOT built sequentially contrary to your intention (design).

The only way to fix this software problem is to SAVE the loop's iterator prior to leaving the first loop, and RESTORE it back when the control is returned prior to the loop iterator is incremented.

The loop needs memory of where it left prior to making the jerky switch, otherwise it fails to restore itself.

This is a remarkably common pattern in mathematics, theoretical physics and literature no matter how speculative its representation might turn out to be.  Think about wormholes, multiverses, Alice's Adventures in Wonderland, The Magician's Nephew, and The Lion the Witch and the Wardrobe.

The loop is like consciousness. Suddenly leaving the realm of loop1 is like entering into a shortcut, a wormhole and finding yourself in the realm of loop2, a different consciousness in a different universe.

However there is one crucial difference. In literature we are biased to think that the heroes maintain their consciousness. They remember other realms when they return. This gives the audience a comforting cozy feeling.

I tend to think though there seems no need to remember your previous conscious presence in one realm or the other. All you need is a functioning anchor when you return. You might pretty much succeed as a forgetful loop provided that your anchor works.

Security and Evolution

In software development there seems to be an inherent 'arms race' around security. External predator software to breach software's security holes is in constant 'arms race' with the software's capacity to repel them. This kind of tense relationship recalls eternal struggle between prays and predators in nature. The pray develop a defense mechanism and survive better and longer say with a camouflage, then the predator develops a counter-measure and the arms race continues indefinitely (people will always attack browsers, browser vendors will always have to deal with them).

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.

Bad players

Every team's nightmare. Bad players.

Categorically they;

• Think they know it all
  
• Think they know the best
• Think they are more intelligent than anybody around them
• Think they are undervalued
  
• Think there is one perfect solution to all types of problems
  
• Think they can do a much better job if the whole thing is left to them
  
• Think not knowing is a sign of weakness
  
• Think asking questions is a sign of weakness
• Think admitting mistakes is a sign of weakness
• Think teaching people what they know is foolish and a sign of weakness
  
• Think hiding problems is the right thing to do unless someone asks for them
  
• Think being part of a team can not be fun, it is just an unpleasant burden
  
• Think the team's goals are not more important than their personal agenda
• Feel no sympathy for people who do not know as much as they do
• Feel no obligation to share their knowledge with people who do not know
  
• Think being a good team player is not going to help them being more competitive
• Think being a loner and staying as a specialist will make them special
• Think teamwork is the biggest threat to their existence
  
• ...

The list goes on and on.

The bottom line is these people are wrong on all accounts we listed above.

What they maintain is a massive delusion about the world around them and about themselves.

Contrary to the impression they want to give about themselves these people are extremely vulnerable. That is why they are so defensive and alert to protect their individual position.

What bad players are missing is that fundamentally being a good team player is not a foolish and altruistic behavior as it seems, on the contrary it is the smartest and the most selfish behavior one could master dictated by our genes ever since human species tripled their brain size in the last two million years. Most of the elaborate complexity our brains has to deal with is about being social. Our species survived and became intelligent because we managed to exploit our social capacity better with bigger brains, not just because we were successful individual hunters or gatherers, but because we could harness the social environment to our advantage.

Good team players are good team players because they have a sharper realization and awareness of their selfish interests. In the long run they know they will benefit more from being a good team player than being a poor player. In the long run good team players always win.

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.

Software Entropy

One of the common reasons why software bugs are not fixed is:

"The developers often don't have time or it is not economical to fix all non-severe bugs."

Bugs scattered across software systems cause "software entropy" to increase (a term that I coined.) Therefore disorderedness of any isolated software system increases over time, similar to physical systems.

On the other hand what makes a software company survive is selling "orderly behaving" products. But competitive market forces and aggressive Sales pressures may increase organizational tendency not to fix bugs. This behavior in turn may lead to software entropy to increase in an exponential rate.

Therefore the size of the backlog of Support department may start to increase exponentially rather than logarithmically. In those circumstances increase in software entropy may result in "customer dissatisfaction" which may eventually lead to sales to decrease.

Therefore there must be a balancing act between Sales and Support. Development resources must be shared and utilized in a way to keep software entropy increase in a logarithmic but controllable and stable fashion if not decrease.

This is similar to "clean house" analogy. If you don't clean up, air and maintain your house regularly, say once every two weeks, it would become more difficult to keep up with entropy. Dust and mold will cumulate. Certain mechanical devices will rust away, or start to malfunction, more dust-mite colonies will flourish, the air will become stuffy and unhealthy. If you leave your house for 20 years, the chances are you may need to rebuild the interiors, i.e. start from scratch.

Software business is no different, negligence of balancing out software entropy may bring catastrophic consequences. And at some "no return" point the business may fail all together if not acted early enough.

Bugs

A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect or unexpected result). Most bugs arise from mistakes and errors made by people in either a program's source code or its design.

...

There are various reasons for not fixing bugs:

• The developers often don't have time or it is not economical to fix all non-severe bugs.
• The bug could be fixed in a new version or patch that is not yet released.
• The changes to the code required to fix the bug would be large, and would bring with them the chance of introducing other bugs into the system.
• Users may be relying on the undocumented, buggy behavior; it may introduce a breaking change.
• It's "not a bug". A misunderstanding has arisen between expected and provided behavior

Given the above, it is often considered impossible to write completely bug-free software of any real complexity. So bugs are categorized by severity, and low-severity non-critical bugs are tolerated, as they do not affect the proper operation of the system for most users.

Wikipedia Software Bug