Tuesday, July 30, 2013

Combating Food Waste

I read recently that in most households anywhere between 15 to 30% of food is thrown away. Almost 50% of salad leaves are thrown away.

These are certainly jaw dropping statistics, and I am wondering if we can somehow figure out a way to reduce the waste. For many of us, who do like to cook, maybe there is a way to keep track of food that is going to become spoilt soon and incorporate those ingredients in our recipes in our daily cooking.

Equally important, could be uncooked food that we can donate to a food drive that is nearing expiry, and can be picked up from our kerbs. Food that is already cooked that can be picked up from our homes as well, with hours of expiry listed. These could be picked up by  volunteer organizations and provided as meals to hungry folks. There of course needs to be a goodwill system that recognizes more dependable and honest folks versus people who try to pass of their already spoilt food into these drives. A recycling fee could be paid to these households that have been consistently good and honest about the quality and condition of their food.


Sunday, July 28, 2013

Understanding the complexity in systems using simplified mechanisms

As the systems we design and build are getting more function rich, the underlying logic is getting bigger and bigger, and as a result, the complexity in these systems is also increasing. The traditional view of adding features to products has meant that we are now left with systems, whose complexity is understood by very few and sometimes nobody at all.

This is causing trouble not only in testing these large systems, but more often than that even the architects and developers are at a loss to understand which all pieces of the system are interacting with one another.

In open source systems, this complexity is somehow managed by adding more eyeballs to the code base as well as constant re-factoring by self-motivated and many time unpaid developers. However, in commercially developed software the complexity can kill or really shorten the product life.

Luckily, there are techniques that can help everyone understand the underlying complexity so that it can be understood and tackled by everyone. One of these techniques is called DSM where all components of a system are put in a NXN matrix and then the interactions between these components is mapped in the resulting matrix/grid. Optimization techniques involve pulling the interacting elements closer to one another spatially on the grid, so that these can then be understood as one system rather than random components interacting with one another.

Lets hope these techniques become more accessible in the days to come so that we don't end up being in the new Dark Ages of automation, where no body really understands why and how our software and hardware components interact with one another.


Thursday, July 18, 2013

Principles of Dashboard Design

I was thinking about the ideal strategy for designing dashboards, till I came across a couple of blog entries by the master himself - Ralph Kimball. In these blog posts, titled "Drill Down to Ask Why" (first and second) the master gives the mantras of good dashboard design.

Here they are, in the order explained by the Master (and mentioned to him by his colleague):

1. Publish reports. Provide standard operational and managerial “report cards” on the current state of a business.

2. Identify exceptions. Reveal the exceptional performance situations to focus attention

3. Determine causal factors. Seek to understand the “why” or root causes behind the identified exceptions.

4. Model alternatives. Provide a backdrop to evaluate different decision alternatives.

5. Track actions. Evaluate the effectiveness of the recommended actions and feed the decisions back to both the operational systems and DW, against which stage one reporting will be conducted, thereby closing the loop.

More on Asking Why?
Giving the example of an air fare planner looking for reasons for poor performance of their data, Ralph provides the following illustrations:

1. Give me more detail. Run the same yield report, but break down the high-level routes by dates, time of day, aircraft type, fare class and other attributes of the original yield calculation.

2. Give me a comparison. Run the same yield report, but this time compare to a previous time period or to competitive yield data if it is available.

3. Let me search for other factors. Jump to nonyield databases, such as a weather database, a holiday/special events database, a marketing promotions database or a competitive pricing database to see if any of these exogenous factors could have played a role.

4. Tell me what explains the variance. Perform a data mining analysis, perhaps using decision trees, examining hundreds of marketplace conditions to see which of these conditions correlates most strongly with the drop in yield (explaining the variance in data mining terminology).

5. Search the Web for information about the problem. Google or Yahoo! the Web for “airline yield 2008 versus 2007.”

I think the above provides a great structure for a real enterprise level executive dashboard.