No Mind

It's the mind that makes you miss the shot
February 26th, 2009

A rose by any other name will end up as a cabbage

Last night a friend of mine pointed me to the 97 things wiki and an interesting axiom “A rose by any other name will end up as a cabbage“. The axiom page talked about how you should name the components in a software project. The idea arises from a simple argument “If you don’t know what it is to be called you don’t know what it is”.

In my opinion natural languages are the best tools for describing the requirements of a project.  Although diagrams are very helpful in explaining the overall logic or flow, but the details of the requirement should always be explained in natural language such as plain English. When requirements are written in plain English, you can toss the requirements across users for comments and get feedback at an early stage of software development. Not all users can understand the complexities of state machines, use case diagrams, ER diagrams etc. but all of them  understand, jargon free simple English. Yes, you can use any other natural language than English, when working with non-English speaking population.

Another advantage of using a natural language to describe requirement is that you get a natural abstraction layer called ‘name’. When you name something you try to come up with a mental abstraction based on the major characteristics of a (physical) object and second time you have to refer to same object or collection of characteristics you call it by a name, instead of long description of the object.  When you see a repeating pattern, give that a name. When you see a bunch of instructions to be executed repeatedly give it a name. When you see an interface, give it a name. At the same time ensure that the name is specific enough to convey the characteristics (eg. cheap,fast,easy, strong etc.) of the abstraction or object. A name that is not specific enough points to lack of clarity in the abstraction layer and is a sign of either too much of abstraction in the system or over engineering. At the same time you need not build abstraction only when you see lots of features being clubbed. An interface might implement only two or three features but the frequency of repetition of those features will make them as a candidate for abstraction and thus a name.

Creating abstraction comes natural to all the humans and it is easy for us to identify things by a name. May be that is why we came up with an idea of commands to computers because it was easier for a human to remember a single command instead of typing a set of instructions to see a list of files in a directory for example.  We further progressed into creating scripts which would be a collection of commands (essentially an abstraction), giving name to a script and then remembering the name as a command.

When you are designing a new software, having a specific name for a component will create the abstraction automatically.  But do watch out if you have too many names in your requirements, you might be suffering from over engineering and you might have created too many abstractions…

Who says whats in the name ?

December 29th, 2008

Software fault tolerance

Ever got frustrated when your software stops responding and crashes, throwing a popup message asking you to send the information to xyz developer? With increasing complexity in the software we see an increasing trend of software hangups. The classic case was the windows blue screen. Thanks to microsoft for getting rid of ugly blue screen and keeping windows OS running when one program misbehaves.

Even though whole world was fed up with blue screen, programmers have  not yet learned that one action by a misbehaving component should not bring the whole system down. With rise of web 2.0 we have seen rise in rich internet applications and a rise in hanging browsers. One misbehaving plugin or a misbehaving tab can crash the whole browser. Gosh, have they forgotten about keeping program stable while writing the initial code ? or introduce new uber cool unstable feature was more important than overall software performance ?

It is very easy to blame software authors for all the mess but lets spend some time trying to understand what causes software to fail and how to avoid failures.

Software failure can be divided in 3 parts, error,fault and failure. Fault or bug is that produces error and error leads to failure. Error is a state of the system under investigation, a state that can bring down the whole system. So our discussion will focus on handling the system states that are liable for failures. Fault tolerance is the set of techniques aimed at detecting, isolating and recovering from computational state that can lead to failure. In Software fault tolerance techniques and implementations Laura Pullum  identifies 4 steps for fault tolerance viz

  1. Error identification or detection
  2. Error diagnostic to identify the cause of error.
  3. Error containment to prevent further damage.
  4. Error recovery the transition from erroneous state to error-free state.

The simplest approach to faul tolerance is try-catch block in OOP. As soon as an error is detected an exception is thrown and a catch block isolates the error giving an option to recover from the fault.  Simple solution which works…  But OOP is a programming language feature whereas software is made of components, so one example is not enough. In this series I will pick examples from foss projects and show how fault tolerance can be built into a system. So see you for more…