Evidence based software engineering....

This is my personal pet interests. Most software engineering today is based on 'hear-say', 'guess work', 'poor mathematics' and 'statements from so called gurus'.

But, how much of it is actually correct? Is there any evidence to back up most of what passes for software engineering?

See the article at:

Bits of Evidence

View more presentations from Greg Wilson.

Google Wave ... used it and .....

Just played around with Google Wave. Currently, I don't quite know what to do with it. It is a communication tool and at this point in time I do not know if anyone else will use it if I do.

Wave is one of those tools where I really have a gut feel that it will get used in ways that the creators have never imagined. It is one of these creative adventures that I feel will eventually help it.

Either way, the Javascript that powers it is impressive. Kudos to the engineering team that built something like this with HTML5/CSS and Javascript (on the client side anyway). Even if this does not take off, the tooling and knowledge gained by this exercise will help us build richer web applications.

-- rv

PS: It really does need a Google Wave notifier -- I for one will not log in every day till there is some level of critical mass.

Feeling guilty about testing .....

Software testing is one of those fuzzy things where the theory in the books completely differs from how testing is done in practice. Unfortunately, the poor practitioners all too often end up feeling guilty for not testing their products properly. Compounding this problem is the fact that there is a whole lot of techniques that are positioned as 'best practice', 'will find the most bugs' etc. -- unfortunately they do no such thing expect adding to the guilt that the testing is poor. 

Why is it so messy? Do we really need to test software as per the books? 

The key observation from my experience is "normal developers test (execute) code to discover behaviour" -- so, they explore the program to check if it broadly matches the expected behaviour. Further, developers also work with requirements that are incomplete, potentially inconsistent and sadly vague. Developers to some extent guess what is expected. They will fill in the gaps based on similar software systems (or) their common-sense (or) gut-feel (or) experience as reference points. This guess work is unavoidable, unless the person providing the requirements, and the developer implementing the requirements both are 'perfect beings'. 

Back to the question at hand -- So how does one go about testing properly? 

Rather than directly answering it I would like to take a detour to make my point. Lets' say you downloaded some new 'browser' software. Your intention is to browse the web, check e-mail, Facebook, Twitter etc. How do you go about testing the viability of this product for your needs? Do you start by writing down all their tasks, define expected behaviour and then proceed to validate?  People explore tools and systems -- and if they are not too painful, they get used. So, what is the most effective way to test a product? The simplest and easiest method is 'use it like the end-user would' -- and do not feel guilty that you are not doing enough. 

I must add some limitations/variations: 

1. If you have a well defined set of mathematical functions -- these can be tested (more) formally and quite rigorously. 

2. If you have a workflow (or) set of rules that are available as a mathematical expression (some graph, logic rules) again a testing approach that matches inputs to outputs will work. 

3. Safety critical systems -- typically quite a lot of effort goes into the requirements to make sure that the fuzzy aspects are completely reduced. 

In cases like the above, test coverage also comes in very handy. Effort can be put into automation and formal testing since it is actually likely to work. Things like compilers, parsers, business rule engines, workflow engines, chess playing software, data structures, well defined algorithms etc. will all fall into the above two categories.  Rest of the time ... "use it to test it". -- rv

Is Google the next Microsoft?

How does an organisation evolve over time? From start-up to corporate giant. Is Google the next Microsoft?

I want to start off with a broad illustration of the steps first on how a start-up slowly gets into the corporate monolith -- but, taking it purely from the perspective of the Executive/Senior management. We can pretty much see where a company is headed purely by observing the profiles of the top management.

Stage 1: Start-up. The management and leadership is closely involved in the product development. In many cases, they are engineers, designers, developers -- the actual builders have all of the power and set the direction. "Lets create/innovate" is the mantra. The company is in the 'Yes we Can' mode.

Stage 2: Market-Development. In this stage, the sales and marketing people start to run the company. They gain power, they generate the revenue -- they dictate the next minor feature to appease the next new client. The product start to loose some coherence, but overall the company can still maintain the innovation. The Chief's in the company will be the Solution architects, Sales and Marketing people. Growth by adding customers is the mantra -- there is a whole lot of positive energy in the company.

Stage 3: Slash-and-Burn. In this stage, the financial and operational arms take control of the company. The easy growth phase is over. Revenues are fairly stable now. The only way to show profits is by optimising resources, cutting costs, being careful with every penny. The Sales and Marketing people are asked to put in a budget and estimate revenue. MBA's start taking control -- Excel is the tool of management choice. Optimisation is the mantra. The employees start to look back fondly at the old days when they made money solving customer problems. [If a company is considering Outsourcing -- they have entered this phase]

Stage 4: We-are-Borg. In this stage, the only way to keep growing is through acquisitions (or) by being acquired. The other options are via lobbying governments for preferential treatment. Monopoly practices, bullying, playing at the edge of law, re-interpreting ethics, borrowing as much as possible etc. The company is now run by the legal department the Chiefs tend to have a background in Finance, Takeovers and/or Politics. There are many mantra's by this point in time - 'Greed is Good', 'Last man standing', 'Heads I Win, Tails you Lose', 'Stealing is ok, getting caught is bad', 'It is only illegal till we re-write the law' etc.

Stage 5: Implosion / Explosion. The entity dies due to imbalances within itself as it becomes completely paranoid, inconsistent and diseased -- like in nature, the most useful parts are pickup up first by other companies and the rest is left to slowly decay.
---

My contention is that almost all companies (or departments) run by normal humans will go through these phases -- the only question is how long they spend in each phase. If the company is large enough, different departments may be at different stages too. This is not a continuous linear process -- that is, companies can move back stage and then go forward again too.

Why does this happen? Simple -- most companies want to grow and be more profitable over time. In a finite world, there will come a time when growth is only possible by taking resources and profits away from someone else. There is no known example of an entity that has grown continuously forever -- and there probably will not be.

So the question is 'Where is Google?'. I think they are in Stage 2. They claim they have built a culture that slows down the natural forces that compel growth and profit taking ... the answer will be fairly evident in about a decade or so.

-- rv