• Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 25 other followers

  • Archives

Perfection of Mean and Confusion of Aims – PART II

In the earlier blog https://3point4.wordpress.com/2010/02/25/perfection-of-means-and-confusion-of-aims/ we saw that one size does not fit all. We need to customize the process frameworks to suit the specifics of the customer and the project team. Agile was advocated, Agile we meant there was more of mindset rather than fixed set of sequences and activities.

 One common place example comes to my mind when we think of this quote “Perfection of Mean and Confusion of Aims” from greatest scientist Albert Einstein…… The Washing Process.

 Problem statement: To remove the stains from the cloth. (Not to damage the fabric).

 Expected Solution    :  Stainless cloth, ready to wear.

 Step 1: Prepare Detergent solution (Detergent + Water mixed in right proportion)

Review the requirements for functional and non functional requirements, group reviews. Avoid requirements Gold plating and introducing complex features etc. This will overload resources and cause reworks. Just use the right quantities of mixture of detergent and water and not too much.   

Step 2:  Soak the cloth in detergent solution. Allow for some time for the Soap to act on the stains

Ensure the Design Plans are made, design inputs are provided and design outputs are validated. Inadequate design and quick design prototype to save development time will lead to poor products. Soak the product enough time in reviews and detailing don’t get stuck with design process, move to coding after sufficient design activity.

Step 3:  Washing in the machine by churning for few cycles

Through iterative reviews, refactoring to ensure that design outputs meet the input specs. Do appropriate refactoring and tailoring to remove the downstream problems that the product may face with regard to design insufficiency

Step 4:  Rinsing (removal of Soap and remaining dirt if any)

Convert the design (pseudo code) into source code by syntax. Remove the unnecessary detailing. Use reusable components. Adequately test the code. Don’t extend testing to unnecessary paths that are not required. Ensure to rinse (test) the product to clean off all the defects                       

Step 5: Drying (Removal of water)

Move the source code into production by ending the testing processes. Testing should be stopped at optimum stage. Testing beyond a stage will add cost to the software vendor as well as delay the shipment of the product to the customer adding more costs. Follow Agile Principle.

We see here that better to ruse the process in phases as applicable and let the process be enabler rather than stoppers.

Summary: To get a clean cloth (product), we soap, soak and rinse. While rinsing we are actually removing the soap that we applied as means to remove dirt. Similarly while drying we remove the water that we used during rising. Much the same way we use processes as means only and not as end. Processes should be used as appropriate and should lead to matured products

Result: Dried unstained cloth ready to wear (after ironing) 

Conclusion : Without Soap and water we cannot remove stains ; after a stage if we keep the soap and water we cannot get the cloth in wearable state. Hence Soap and Water are required up to a stage and need to get rid of them after the intended use.

Similarly use processes as a means to get to the Aim.

Lean not Leaner (Simple not Simpler)

Lean (eliminate heaviness) but not leaner (Lacking fuel).

Use Tools to reduce waste (effort) and don’t eliminate unit testing, good estimation and effective reviews.

Agile ways of development means ensuring light weight and efficient velocity for the project engine to take off to iteration destination.

However in the name of simplicity we should not make things too simpler by avoiding necessary fuels (reviews, unit tests), air (tools), lubricants (stand up meetings) to the Agile engine.

Over simplification results in lack of values to stakeholders.

Lean Leaner
Think Product Vision by prioritizing Product Backlog through Sprint Backlogs Don’t forget Product backlog, theme and vision while detailing in Sprints
Agility means thinking in story points and ensuring values to all stakeholders. Customers are not interested in tasks status but stories status that adds value to them Don’t skip stories planning, estimation, mapping  with tasks as subsets. Tasks based planning will be useful for developers if they cant think through stories.
Eliminate Manual efforts in : unit testing, reviews, code integration. Use Tools Don’t skip Unit testing, adequate reviews by being “Agile” that is not
Have short stand up meetings Don’t overlook stand up meetings as a way of saving time. Skipping stand ups results in teams sitting down on the sprint.
Have planning poker estimation or any other rational and simple estimation. Don’t skip formal estimation and allow guess estimates. This over simplification will lead to confusion and missed features for the sprint planned.
Have product vision in back of the mind and focus on the current sprint. Set and leave the integration and regression testing to the tools . Don’t dilute code review without thinking about the dependencies and the impact of the present features into future iterations.
Use test early and test often tenet for both functional and non functional requirements. Never avoid non functional / alternate paths for testing in the name of agility
Clear the impediments by ensuring right resources, training, clarity, tooling and understanding Does not mean compromise on technical Quality of the features by concession to developer’s lack of skill. Train resources.
Collaborate with stakeholders Not to include over participation from people not directly involved
Make it simple Not Simpler

Everything should be as simple as it is, but not simpler – Albert Einstein.

Education – Remains of Knowledge

Jobs are plenty. Right resource for the right job is a problem. If one does a simple root cause analysis one will be able to understand some underlying causes. After knowing the causes is it possible to address the problem. Not always easy.

 Manufacturing industries have more than 100 years of experience and fairly understood the nitty-gritty of consumer requirements and more importantly about the right way of developing products and services using right tools and techniques. It is safer to assume this.

In the dynamic word of IT, software development is still evolving with multitudes of technologies and tools every day. Much as we appreciate this fact, how the IT industry is ready for producing great products / services to customers is the question?

Software engineers should gain knowledge and skills on continuous basis through not only formal trainings in-house and external faculties, but also should do fair amount of exploration in social media like Google, TechReublic, Technorati , Blogs, Digg and countless other industry-academy forums.

As the years go by people tend to forget what they learnt from colleges, industries and even in previous projects. It is essential and necessary requirement for resources to remain well informed and hands-on on continual basis. This is the way we can keep minimum required skills for successful career in Software Development field.

Albert Einstein:

“Education is what remains after one has forgotten what one has learned in school”.

Perfection of means and confusion of aims

Typical Projects with the paraphernalia of sequences and steps are PUSHed into waterfall development methodologies. Project managers and stakeholders insist so much on process frame works, documentation and client sign-offs at every phase like Business Requirements, Software requirements, LLD, HLDs, Code check-ins, testing etc leading to heavy overheads. Not only does this create wastes in the system, it causes potential defects waiting to be discovered during the downstream stages of product releases. This is the way to “how to make projects fail and increase cost”.

Instead if project stakeholders commit to Agile Development, build products collaboratively and value people who matter most like developer, user and other key stakeholders and have trust in the system being built, the aim – the goal of successful products release will be achieved in the end. Means are important for sure, not to the extent of impeding the aim – “building products quicker and better”.

Product owner and scrum master jointly can decide on priorities based on drive the product development towards success.

  • Have Product Vision.
  • Collaborate with Customers.
  • Believe in people who build products.
  • Use optimum process as a means.
  • PULL the Value through customer driven development.
  • Eliminate Waste.
  • Make Great Products.

Wisdom of Albert Einstein:

“A perfection of means, and confusion of aims, seems to be our main problem”.

Never made a mistake never tried anything new


Though Getting it Right First Time a Great Goal and learning from Total Quality Management idea is a great inspiration for making superior products, in the real software development how far this is feasible and at what cost needs to be thought about.

As cost, schedule and Quality are very vital determinant for any new product or service that is being delivered; let us see if an organization balances these critical factors. In today Agile development world which encourages collaborative development and incremental delivery it is not possible to develop products Right first time. Though there are mission critical developments like aerospace, health Care, financial segments that need clinical precision, Agile development will not help much. It has to go through the disciplined classical software engineering cycle with reviews, inspections, audits and tests with due sign-offs from impacted stakeholders. However for majority of the software development that do not require very high levels of accuracy to the sixth decimal levels, Agile development will suit better. Agile provides quicker returns on investment to the software vendor and simultaneously make the products available to the users. Based on the feed back user provides the product under goes modifications to fulfill the expected and implied needs of the users. In this process all stakeholders do understand that “Build the product right first time” may not be possible and it will increase costs, make the development and release of the products delayed.

With due respects to Getting it Right First Time Principle, project managers need to apply them prudently keeping in mind the wisdom of  Albert Einstein:

 “A person who never made a mistake never tried anything new”.