I am looking forward to attending the  NoSQL Live event in Boston. Before attending, you might want to brush up on the current state of affairs in the NoSQL universe. Below are a few links that give you a comprehensive overview of the same.

• No Sql databases – Part 1 – Landscape by Vineet Gupta
• Paper : High Performance Scalable Data Stores by Rick Cattell
• NoSql ecosystem by Jonathan Ellis

I just finished reading the story of Mohammad Yunus and Grameen Bank in the book titled Banker to the Poor: The Story of the Grameen Bank. It is amazing how he threw out many of the standard policies and practices that traditional banks implemented and invented new ones to meet the needs for the poor. Here are some examples

• Eliminated filling out lengthy/multiple forms since the poor did not know how to read and write.
• Abolished collateral since the poor did not have any.
• Encouraged office workers/bankers to be out on the field to meet clients instead of them coming in.
• Made loan repayments weekly instead of one large payment at the end because it was very difficult for them to save up a large money
• Gave out small loans and worked with the customer to repay them
• Gave loans to mostly women ( in Bangladesh it seems most loans were made out to me ), because they had higher rate of repayment

The list goes on. But what was impressive if his ability to question the status quo and the traditionally established processes. Expanding this to software markets, sometimes it is is very beneficial to question the current process in existing markets or understand which other possible customer population has been prevented from using the solution. If it looks like  there is a new way to doing things it is worthwhile putting thought into doing it.

Author Robert Glass has collected a woderful list of many facts and some fallacies  found in the field of Software Engineering in his book titled Facts & Fallacies of Software Engineering. Here are some regarding software maintenance that I have observed personally :

• Fact : Maintenance Typically consumes 40 to 80 percent of software costs. Therefore, it is probably the most important life cycle phase of software
• Fact : Enhancement is responsible for roughly 60% of software maintenance costs, Error correction 17%, Adaptive Maintenance 18% and Other (Preventive maintenace, Refactoring etc.) 5%
• Fact : During Maintenane, the task of “Understanding the existing product” takes about 30% of the total maintenance activity.

Depending on the type of software these numbers might vary, but clearly it illustrates the fact that software maintenance is an expensive activity . Almost every manager who has been part of any kind of maintenance activity intuitively  feels this, but seeing these concrete numbers gives a much crisper understanding to the scope of the issue.

Many folks have tried to define metrics to measure maintainable software. There are many things that can make software maintainable. In my experience software with the characteristics below are extremely maintainable.

1. It is easy to understand and well documented. When you open up a software module/package, if you can follow the implementation logic fairly easily then that helps a lot. Well documented does not mean lots of documentation. Rather I would consider the following documentation sufficient

• An architecture/overall design  document which clearly communicates
• The goals and principles of the design
• The major frameworks and modules that are part of the system
• An example or two of how key use cases are accomplished using this architecture

• Code with good naming conventions so that reading it is easy and helps understand the flow
• Major modules/frameworks have clearly documented APIs (as part of the interface definition itself)

2.  The modules and frameworks have well defined and separate concerns/responsibilities

3. The public interfaces of the frameworks/modules are stable (don’t change a lot), used in many places and don’t have too many variations of the same interface method

4. The structure of the code/architecture is simple (I do not know how to define simple yet, but I will take a shot in my next post)

The term “Lean” has been used in the context of software development for a while now.  Lean Software Development and Lean Startup are two of the popular ones. I would like to use the term “Lean Software” to literally mean that. Lean software has the following characteristics

• They do not have any unwanted/nice to have/”cool features customers really don’t care for” features
• They do not have any unwanted/cool/”latest and greatest but adds no value to the solution” technologies
• They do not have any unwanted/never used/”this will be useful in the future”/”code anticipating future needs” code

I have repeatedly seen more than one of the above symptoms in software. All the conditions will unnecessarily add complexity/unwanted code to the software being built resulting in possibly more defects or time to build. Over the course of time if you assume a 10% loss every development iteration; by the 5th or 6th iteration you are either taking 20% more time or effort or you are doing 20% less new features. Over the next few posts, I am going to elaborate on these points.

It is universally accepted now a days that Unit Testing is a good idea. However, there are a number of situations when unit testing is not a good idea. Below are 2 such scenarios

1. Changing APIs/implementation
2. New technology/Language etc. which does not have good unit testing support structure

Changing APIs

Unit Tests are most useful when you have written them for a method and then the implementation of the method changes and your test is still valid. This helps validate that the new code has not broken the contract of the method. Hence for whatever reason if the API and the method contracts are changing all the time then it is not worth writing exhaustive unit tests and then rewriting them with the new APIs. I am not suggesting that when people change APIs that they should not rewrite their unit tests. Rather, if you cannot stabilize your APIs then do not write too many unit tests or design your solution to have a good stable set of interfaces so that you can effectively use the unit test suite.

New Technology Use

If you are using a new programming language or framework which does not have a good unit testing framework or support then you might not want to spend time building a custom solution. Then as the language develops or test frameworks get developed, your investment will become and unnecessary overhead. If you intend to do large scale development with many many developers then it might still be worthwhile setting up your own framework. An alternative would be to open source the framework and get more community support or development around the new test framework.

Eric Ries at Lessons Learned has started developing the concept of Lean Startup.  You can read his thinking in this blog post at http://startuplessonslearned.blogspot.com/2008/09/lean-startup.html .  In summary, he says Lean Startups have these 3 characteristics.

1. They use of a commodity technology stack (Open Source Software stacks/platforms etc. ) to build their products/services
2. The practice of Agile Development Methodologies
3. The application of a customer-centric iterative process for product development

I really like the concept Eric is formulating.  He has incorporated  Steve Blank’s Customer Development Methodology for concept 3 above.  II agree with this philosophy whole heartedly and in the next few posts, I will be putting forth my thoughts and experiences.

Below are some links that will give you an introduction to Lean Startup concepts

http://www.slideshare.net/startuplessonslearned/lean-startup-fbfund-edition

http://www.slideshare.net/sblank/lean-startups-steve-blank-eric-ries-presentation

http://www.slideshare.net/venturehacks/customer-development-methodology-presentation

Wolfram Alpha (http://www.wolframalpha.com) and Google Squared (http://www.google.com/squared)  are two new computing services that try to present search results in a structered, factual format. Wolfram Alpha claims to be a computational knowledge engine.  What this means is that instead of searching the web and just returning links to pages, it searches and computes through its own knowledge store and returns a structured representation of the information it has. It has many limitations but the idea is definitely interesting. It allows you to search in natural language and works better with factual queries. Below are some example queries and their results

Searching for India results in key demographic, cultural and geographic information

Searching for “Internet users in Europe” results in total Internet users in Europe with distribution by country, charts etc.

Since the site is built on Mathematica, it can easily compute mathematical formulas. Wolfram Alpha  is no Google killer as it claims to be, but it is still an impressive piece of functionality and very interesting. I can easily imagine a host of new applications that will come up that will use the structured data output and make it useful for users. For example, I can now build a country explorer, which can get results from Wolfram Alpha for multiple country queries, and then compare them, show their maps etc.  Google Squared is a similar idea too, but instead of going against an internal knowledge base, it seems to scrape data directly from the web and present it in a structured format. This is just the release 1.0 of the services, but I am looking forward their evolution.

I came across this very interesting presentation on design and user interation.

http://www.slideshare.net/tmo/the-web-in-the-world-presentation

A few weeks ago, I read Jeffrey Krames’ book “Inside Drucker’s Brain”. It is a short and simple introduction to management guru Peter Drucker’s thoughts and philosophies on Management. It covers all his important ideas like Leadership & Execution, Strategy, Innovation, Management etc. This is not a comprehensive treatment on Drucker’s teachings, but a quick introduction. Most thoughts are definitely interesting but there were 2 chapters that got me thinking. Here are some ideas that i was very much interested by

Idea 1 : Abandon all but tomorrow

Krames quotes Drucker as follows

“The first step in a growth policy is not to decide where and how to grow. It is to decide what to abandon. In order to grow, a business must have a systematic policy to get rid of the outgrown, the obsolete and the unproductive”.

“increasingly organizations will have to plan abandonment rather than to try to prolong the life of a successful policy, practise or product”

Drucker’s litmus test of abandonment is  to ask the question “if we did not do this already, would we go into it now, knowing what we know? and if the answer is no, the organization has to ask: And what do we do now? it has to do something, no just another study”

Idea 2 : Ouside-in

Krames summarizes Drucker’s eight realities for every manager. Two of them are thought provoking for me. They are
  
Results and resources exist outside the business : Drucker stressed that there are no profits within an organization, only cost centers. Results never depend on anyone within the company but, instead, on customers in the marketplace.

Results are achieved by exploiting opportunities, not solving problems: solving problems can only return an organization to prior status quo.