Author Archives: srikalabharadwaj

Features of functional programming

Functional programming is a programming paradigm that evaluates as if it were a mathematical function and avoids state and mutable data. Programs are executed by evaluating expressions as opposed to imperative programming which depends on statements to decide what is to be done next. In lay man’s term a functional programs tells what to do and not how to do it.

Features of fuctional programs

Higher order functions of First class functions

Functions are treated like any other values and so can be passed to other functions as arguments or be returned from other functions. One function can be defined and manipulated from within another function. example: SubtractFromList y=map(\x->x-y). map takes a function and a list as arguments and applies function to all elements of list and returns the list of results.


one function is applied to its arguments one at a time and with each application a new fuction is returned that takes the next argument. Higher order functions and currying is helpful in refactoring the code and reducing the amount of repetition. 


Sometimes expressions can yield actions that are considered to be side effects of a particular action. Languages that prohibit side effects are considered to be pure. Functional languages are usually pure. Sometimes it maybe beneficial  to write impure code such as in I/O state code. But this should be kept to a minimal and functional languages support this. Side effects can be simulated by using monads which provide implicit threading that the compiler does not know. Example: Maintaining bank account balance. These are applicable to tasks that need to be implemented within a state.

Immutable Data

Pure functional languages operate usually on immutable data where instead of altering existing values, altered copies are created and the original copy is preserved.


Recursion is heavily used in functional programming as it is the canonical and often the only way to iterate, A feature often used is tail recursion where one function calls another function as its final action.

Lazy evaluation

Functions are not evaluated unless their values are required to evaluate the function call itself. This leads to reduction of overhead arising from evaluating all functions beforehand. Imperative paradigm uses eager evaluation where function arguments are evaluated before invoking. Example print length([2+1,3*2,1/0,5-4]). In imperative programming this code causes the program to crash as 1/0 cannot be evaluated. In functional programming this program crashes only if the length method is called. It runs error free if length is never called which is not the case in imperative paradigm.

Functional programming provides better support for structured programming. It is clean and avoids side effects. Referential transparency is achieved. The program itself is shorter and easier to write. The use of higher order functions enables better embedding of functionality. However the disadvantage is that running of functional programs is less efficient in terms of CPU and memory use. Functional programming is not very suitable for implementation of I/O operations.

C&K metrics for Object Oriented Design

There is a huge need for process improvement in software development as 70% percent of the projects are below satisfactory level. One of the prominent approaches of design being used today is the object oriented modelling. There is a need for a suite of metrics to help a manager to measure the design especially when adopting to a new technology or when stepping into a new terrain.

Some of the metrics that were proposed before C&K metrics were subject to criticisms such as lacking a theoritical basis, lacking desirable measurement properties, being insufficiently generalized or being labor intensive to collect.

Six metrics were presented by Chidember and Karemer and they provided a method to collect them and also validated them based on a previously established measurement principles. The highlights of the paper that they presented was a theoritical ground for the metrics.

A OO Design can be conceptualized as a relational system consisting of a set of elements(classes, objects) , a set of relations and a set of binary operations performed on the elements. DΞ(A, R1…Rn, O1….On). A is set of object elements. R1….Rn are empirical relations of object element A and O1….On are binary operations on element A. This definition is now mapped onto a formal system F to provide mathematical basis. If a is an element in D, then μ(a) is an element in F.  μ does not make implicit changes to a. Example: Heights of school children can be mapped onto real numbers. Taller can be described as 36 inch child > 30 inch child. Children standing atop one another are mapped to adding real numbers.

An ontology is described where the design would be viewed as composed of things referred to as substantial individuals and concepts. The key is that substantial individual  possess properties inherently. The six metrics are


Two objects are coupled if and only if at least one of them acts upon the other. X is said to act upon Y if the history of Y is affected by X. In order to find coupling between object classes, the software engineer must consult CRC cards and count the number of collaborations listed for the class.


The degree of similarity of the methods within the object can be defined to be the intersection of  the sets of variables used by the methods. A software engineer can measure cohesion by first picking an attribute and counting the number of CRC cards that access that attribute.

Complexity of an object

Cardinality of its set of properties. To guage weighted methods per class, software engineer must compute the complexity of the method.

Scope of properties: 1)Depth of inheritance: Software engineer must consult the inheritance tree and traverse it till the deepest child and find the depth.
2)Number of children: Software engineer must consult the Inheritance tree and calculate the number of children that are one level below the class under abstraction

Methods as measures of communication

A message can invoke a behaviour by calling another method. A software engineer must take the firat message and count the number of methods that can be potentially executed as a response to that message.

Combination of object classes

Additive aggregation of 2(or more) things like the combination of 2 object classes results in another class whose properties are the union of the properties of component classes.

Motivations for participating in Free and Open Source software development

A survey showed these statistics about the highest educational degrees of participants in the Free and Open source software movement- 3% PhD, 21% Masters, 48% graduate college, 24%- Non college and 4% other. Let us see a few motives that might be driving the diverse set of people in a voluntary contribution setting.

Intinsic motivations

Personal need for a particular software: “Scratching a developers personal itch”

A single developer may be motivated to kick start a project simply due to the lack of adequate software solutions for the problem in hand. Linus Torvalds need for unix for his PC lead to Linux. Eric Allman’s need for a more efficient email server lead to “sendmail”. Larry wall’s need to automatically generate web pages resulted in Perl. Another example is Don Kluth’s document setting needs gave way to TEX.

Just for the fun of it!!

Homo ludens refers to the playing human. Programmers often confer that programming is like a leisure time activity i.e playing around with the different possibilities and thrill of mastering a challenge. Torvalds often said he did it for the joy and fun in it. With more eyes watching, errors are better scrutinized and thrill is greater.

kin selection Altruism

The free and open source group is a community of highly skilled selfless people. They consider their work a gift for the community and the general public.

Pure Altruism: Stallmann believes that the motivations are pure selfless ideas and beliefs is creating and distributing free software that anybody can modify or use.

Participation in social events

History has shown that voluntary involvements in social movements be it civil rights or gay rights stems from personal identification with the people involved or personal belief to support the cause.

Social status upgrade

Programmers maybe motivated to participate for peer acceptation and recognition. There are levels in the community and promotion to the next level is based and pure merit. This gives good credibility and respect to the programmer.

Extrinsic motivations
Job signalling/Self marketing

Participation might be used as a signal to potential employers. Source code acts as a window to the programmers performance capabilities for those scouting for talent. Active participation helps to catch the attention of employers who otherwise might be tough to contact. Freelance programmers might showcase their work as a profile to potential employers.

Expecting revenues from related products/ services

RedHat offered commercial consulting, training, distribution and implementation services. The software itself can also be sold for a price or its upgrades or customizable features may be charged

Expand their skill base

Gain a better understanding. Exposure to a wide variety of techniques and projects.

Component Design Principles

Mieke Gerretzen said “Good design goes to heaven, bad design goes nowhere”. The importance of a good design cannot be stressed enough be it in architecture or software development. Robert Martin pointed out that 3 basic characteristics of a bad software design are rigidity, fragility and immobility. Component design principles discussed below are guidelines to ensure a better designed code.

Open Close Principle

“A module should be open for extension but closed for modification”.

Changes have to be accommodated after a piece of code is written. These changes should be made in such a way that minimum ripple effect is felt among the related classes. The changing functionality should be coded to an interface from which the new classes can derive the common functionality and introduce the change. In the example, the account class is closed to changes, but if we want to add a new account of say recurring deposit type we have to inherit from the AccountType which acts as an abstraction interface and so avoids changes in Account


Dependency Inversion Principle

“Depend on abstractions, do not depend on concretions”

In any design there are low level classes that implement functionality and higher level classes that control the logic. People tend to first code the functionality first at the implementation level and they design classes to use the functionality. This is a bad practice as, if changes need to be made to the low level classes which is often the case the higher classes also have to be altered. Consider the example of a copy module that reads from the keyboard and writes to the printer. People tend to write classes such as keyboard read and printer write(low level classes) first and then write the copy class to use these classes. But when a common change comes along such as changing the output to be written to a file, we will have to change the copy class as well. Instead a good practice would be to use abstractions and make the low level classes to depend on these abstractions. So the design order would be High level classes->Abstraction Layer->Low level classes.

Interface Segregation Principle

“Many client specific interfaces are better than one general purpose interface”

We should create a specialized interface to serve each major category of clients. We should not create fat or polluted interfaces. Fat interfaces force the submodule to implement dummy methods. Consider the example of a company which employs robots and human workers. A human works and eats, whereas a robot only works. If work and eat are in a single interface, robot had to implement a dummy method for eat. A better solution would be to create 2 separate interfaces one for work and another for eat.

Image    Image

Single Responsibility Principle

“A class should have one and only one reason to change”

If a class has 2 reasons to change, then the class must be split into 2 classes else changing one responsibility will change another functionaity. Consider a Email example- Say it has 2 potential changes 1) content (to html) 2) protocol used (to POP3).  If we keep only one class, each change for a responsibility might affect the other one as follows creating a undesirable effect:

  • Adding a new protocol will create the need to add code for parsing and serializing the content for each type of field.
  • Adding a new content type (like html) make us to add code for each protocol implemented.
Liskov’s Substitution Principle

“Subclasses should be substitutable for their base classes “

If a component is working well with a base class, it should work just as well with the its subclass passed to it. In other words the pre and post condition must be the same regardless of whether a base class or sub class is passed the component.


Program management

Web framework- gantt chart







CMMI-development. What is it all about?

Lillian Hellman said- “Things start out as hopes and end up as habits”. CMMI promises to show organizations the path of such a workspace conversion-where hopes become repeatable habits!

CMM- Capability Maturity Model was developed by Software Engineering Institute at  Carnegie Mellon University as commissioned by the US, Department of Defence. Later in 2010, CMM-Integrated was launched with separation of concerns such as Development, Services and Acquisition. The major changes were better description and marriage of cmmi with agile method(to end their made up cold war).

CMMI models are a set of practices which when followed thoroughly, can  improve  processes and their management.  CMMI makes life easy  by making the customer trust the organization  more, by helping to add value to the stocks and by giving a better recognition overall.

The CMMI document divides development into 22 core process areas such as Decision analysis and resolution, product integration etc.. Each area has components which are classified as required-MUST be visible in the organization, expected-important to achieve and  informative. Each process area is governed by a set of goals–  both SPECIFIC to the the  area and GENERIC. Achieving these goals is possible by following a detailed set of specific and generic practices given in the document. There are examples, subpractices and elaborations that give details about the implementation of practices. Click here to see the entire CMMIv1.3- development report. A generic goal is explained below as described in the document.

GG 3:Generic goal is “Institutionalise a Defined Process ”

Generic practices to be followed are

  1. Establish a Defined Process.
  2. Collect Improvement Information

 Subpractices are

  1. Store process and product measures in the organization’s measurement repository
  2. Submit documentation for inclusion in the organization’s process asset library
  3. Document lessons learned from the process for inclusion in the organization’s process asset library.
  4. Propose improvements to the organizational process assets

Examples of process related experiences for Product Integration area:

  • Records of the receipt of product components, exception reports, confirmation of configuration status, and results of readiness checking.
  • Percentage of total development effort spent in product integration (actual to date plus estimate to complete)
  • Defects found in the product and test environment during product integration
  • Problem reports resulting from product integration

CMMI can be applied for a team, workgroup etc. In a world of rating everything, from your personality to the pen that you use, why should software organizations be left behind. A provision for applying for appraisal and getting a rating according to the relevant maturity level is possible.


Continuous Representation for process area. CAPABILITY Levels

Staged Representation for organisation. MATURITY Levels

Level 0 Incomplete– process partially performed              –
Level 1 Performed– needed work done to satisfy specific goals Initial- chaotic environment. Depends on heroics
Level 2 Managed- Planned and executed process as per policy Managed- planned execution
Level 3 Defined- standard practice according to tailored guidelines Defined-process standardization
Level 4            – Quantitatively Managed- quality management
Level 5            – Optimizing- innovation and deployment

Standard CMMI Appraisal Method for Process Improvement (SCAMPI)provides 3 classes of improvement to be applied at different levels. Class C is for few process areas and done within 3-5 days by Appraisal team member. Class B focuses on Deployment and a certified Lead appraiser is called in. Class A is stringent and is the basis for the final rating and focuses on institutionalisation and is done by a Lead Appraiser with a team. Example: Click here to see a sampling summary as published by SEI for Aricent.

The CMMI results published by SEI can be viewed by clicking here

Current research being carried out by SEI post CMMIv1.3 is

  • Tuning to process requirements in multi model environment
  • Studies of CMMI’s effect on Performance.
  • Mapping CMMI standards with IEEE,ISO etc to set a global standard.
  • tuning for improvement in small organization