Sundarrajk's Weblog

Archive for the ‘Book Excerpt’ Category

The Education of the ChildThe Education of the Child by Ellen Key
My rating: 4 of 5 stars

A wonderful book on how to rear a child. The author highlights how use of corporal punishment is detrimental to the growth of the child. She also highlights how forcing one’s opinion and worse wishes on the child turns the child into a limited human.

The author says that we should lead by example and create an environment where the child can pick up the right and good traits rather than drilling it into their heads.

Some of the strong statements made by the author are as under:

“To suppress the real personality of the child and to supplant it with another personality continues to be a pedagogical crime common to those who announce loudly that education should not develop the real individual nature of the child.”

“Education must be based on the certainty that faults cannot be atoned for, or blotted out, but must always have their consequences”. A moot point that is raised is does “saying sorry” really help? Or for that matter thrashing the child? The author goes on to say “At the same time, there is the other certainty that through progressive evolution, by slow adaptation to the conditions of environment they may be transformed. Only when this stage is reached will the education begin to be a science and art. We will give up all belief in miraculous effects of sudden interference; we shall act in the psychological sphere in accordance with the principle of indestructibility of matter. We shall never believe that a characteristic of the soul can be destroyed. There are but two possibilities. Either it can be brought into subjection or it can be raised up to a higher plane.” How pertinent it is when coming to reforming culprits.
“Madame de Stael’s words show much insight when she says that only those people who can play with children are able to educate them. For success in training children the first condition is to become as a child oneself, but this means no assumed childishness no condescending baby talks that the child immediately sees through and deeply abhors. It means to treat the child as really one’s equal, that is, to show him the same consideration, the same kind of confidence one shows to an adult. It means not to influence the child to be what we ourselves desire him to become but to influenced by the impression of what the child himself is; not to treat the child with deception, or by exercise of force, but with seriousness and sincerity proper to his own character.”

“Not leaving child in peace is the greatest evil of present day methods of training children.”

“The statement that no human being learns to understand another, or at least to be patient with another, is true above all of the intimate relation of child and parent in which, understanding, the deepest characteristic of love, is almost always absent.”

“Parents do not see that during the whole life the need of peace is never greater than in the years of childhood, an inner peace under all external unrest. The child has to enter into relations with his own infinite world, to conquer it, to make it the object of his dreams. But what does he experience? Obstacles, interference, corrections, the whole livelong day. The child is always required to leave something alone, or do something different, to find something different, or want something different from what he does, or finds or wants. He is always shunted off in another direction from that towards which his own character is leading him. All of this caused by our tenderness, vigilance, and zeal, in directing advising and helping the small specimen of humanity to become a complete example in model series”.

“The art of natural education consists in ignoring the faults of the children nine times out of ten, in avoiding immediate interference, which is usually a mistake, and devoting one’s while vigilance to the control of the environment in which the child is growing up, to watching the education which is allowed to go on by itself.”

“To bring up a child means carrying one’s soul in one’s hand, setting one’s feet on a narrow path, it means never placing ourselves in danger of meeting the cold look on part of the child that tells us without words that he finds us insufficient and unreliable. It means the humble realization of the truth that the ways of injuring the child are infinite, while the ways of being useful to him are few.” How true.

“What is required, above all, for children of the present day, is to be assigned real home occupations, tasks they must do conscientiously, habits of work arranged for week days and holidays without oversight, in every case where the child can help himself. Instead of the modern school child having a mother and servants about him to get him ready for school and help him remember things, he should have time every day before school to arrange his room and brush his clothes, and there should be no effort to make him remember what is connected with the school. The home and school should combine together systematically to let the child suffer for result of his negligence.
Just the revers of this system rules today. Mothers learn their children’s lessons, invent plays for them, read their story books to them, arrange their rooms after them, pick up what they have let fall, put in order the things they have left in confusion, and in this and in other words by protective pampering an attention, their desire for work, their endurance, the gifts of invention and imagination, qualities proper to a child, become weak and passive. The home now is only a preparation for school. In it, young people growing up, are accustomed to receive services, without performing any on their part. They are trained to be always receptive instead of giving something in return. Then people are surprised at a youthful generation, selfish and unrestrained, pressing forward shamelessly on all occasions before their elders, crudely unresponsive in respect of those attentions, which in earlier generations were a beautiful custom among the young.”

“We must begin in doing for the child in certain ways a thousand times more and in others a hundred thousand times less. A beginning must be made in the tenderest age to establish the child’s feeling for nature. Let him live year in and year out in the same country home, this is one f the most significant and profound factors in training. The same thing holds good of making a choice library, commencing with the first years of life, suitable books for each age; not as is now often the case, get quite spoilt by constant change of summer excursions, by worthless children’s books, and costly toys. They should never have any but the simplest books; the so called classical ones. They should be amply provided with means of preparing their own playthings. The worst feature of our system which imitate the luxury of grown people. By such objects the covetous impulse of the child for acquisition is increased, his own capacity for discover and imagination limited, or rather, it would be limited if children with sound instincts of preservation, did not happily smash the perfect playthings, which give them no creative opportunity, and themselves make new playthings from fir cones, acorns, thorns, and fragments of pottery, and all sorts of rubbish which can be transformed into objects of great price by the power of imagination.” Alas!

“Try to leave the child in peace; interfere directly as seldom as possible; keep away all crude and impure impressions; but give all your care and energy to see that personality, life itself, reality in its simplicity and in its nakedness, shall all be means of training the child”.

“Neither overbearing nor pampering parents do good for the child’s development. Both alike, torture their children though in different ways, by not understanding the child’s right to have his own point of view, his own ideal of happiness, his own proper tastes and occupation.”

“Family life would have an intelligent character if each one lived fully and entirely his own life and allowed others to do the same”.

“We must realize that every pebble by which one breaks into the glassy depths of the child’s soul will extend its influence through centuries and centuries in ever widening circles. Through our fathers, without our will and without choice, we are given a destiny which controls the deepest foundation of our own being. Through our posterity, which we ourselves create, we can in certain measure, as free beings, determine the future destiny of the human race.”

“An English specialist has maintained that the future thanks to the modern school system, will be able to get along without originally creative men, because the receptive activities of modern man will absorb the the cooperative powers of the brain to the disadvantage of the productive powers. And even if this were not a universally valid statement but only expressed a physiological certainty, people will some day perhaps cease filling down man’s brain by sandpapering process called a school curriculum.”

View all my reviews

tldr; warning

Tools and Infrastructure

Manage Assets

How Do I Get Started?

If you’re not using any type of source code control for your project, make it your top priority.
According to a recent survey, some 40 percent of IT shops in the United States do not use any source code or version control product at all, so we know you’re out there.
  1. Evaluate a few SCM systems. We heartily recommend CVS or Subversion. Both are free and used by some of the largest software companies in the world. If you choose a commercial solution, these products will still give you a baseline to compare their feature sets against.
  2. Learn how to use your SCM.
  3. Generate a single-page quick-start guide that shows how to use the system for common operations.4. Show the system to your team. Be sure everyone is comfortable with the system.
  4. Import your code and supporting files.
  5. Start keeping all your files in the SCM.

Am I Doing This Right?

First, are you actively using the system? If you go weeks—even days—between code check-ins, you aren’t using the system actively. This defeats the whole purpose (backing up your work and maintaining an accurate fine-grained history). Even if your code isn’t ready for the production tree, it can be placed in a private or personal area of the system.
If the hard drive on your workstation crashed right now, how much work would you lose? If it’s more than a day or two, consider changing the way you work.
Also, how long would it take you to get a new machine up and running for development? Are all of your build scripts and development resources checked in?
Can you perform SCM operations quickly? If it takes you twenty minutes to check out code and another fifteen minutes to put changes back in, you won’t do check-ins frequently. Your basic interactions must be fast.
Operations such as fetching differences can put a heavy load on the CPU and disk drives. Quite often companies will put their SCM software on an antiquated computer, making all interactions painful.
Hardware is cheap, but developer time is expensive. Whatever it takes (training, hardware, or new SCM software), be sure that your SCM is fast enough to keep up with you.
Are you backing up the SCM’s repository? If the building burns down tonight, do you have an off-site backup that you can use to restore to another machine? A great SCM does you no good if the data it’s storing gets lost. Be sure you are getting a complete, weekly off-site backup at a minimum.
Finally, do you know your system well enough to perform these basic operations easily? Here’s a minimal list of operations that you need to know:
  • Check out the entire project.
  • Look at the differences between your edits and the latest code in the SCM.
  • View the history for a specific file—who changed this file and when did they do it?
  • Update your local copy with other developers’ changes.
  • Push (or commit) your changes to the SCM.
  • Remove (or back out) the last changes you pushed into the SCM.
  • Retrieve a copy of the code tree as it existed last Tuesday.

Warning Signs

  • No activity in the repository. An unused repository is a useless repository. You should see activity every hour through the day as individual developers check in and check out regularly.
  • Incomplete repository. If the repository contains only some of the files needed to build your product, it’s not pulling its weight. Beware of “experimental” release or test trees that aren’t being stored in the repository or of contents of critical XML files or databases.
  • Slow access. If it takes a long time to check in or check out files, people will eventually stop using it—even if they are using it now.
  • Lost files, corrupted files. Some version control systems (made by certain large, unnamed companies) are known to “eat” files on a regular basis. Upgrade to a real system, such as the freely available CVS or Subversion.

Script your Build

How Do I Get Started?

If you just inherited a new product without an automated build, you should take these steps immediately to get a build script in place:
  1. Have a team member manually build the system while you take notes.
  2. Define the individual build steps.
  3. Pick a build tool but be prepared to revisit other options if this tool becomes too burdensome.
  4. Incrementally script each step; eliminate manual operations one by one.
  5. Run the script on another workstation. This step will catch any accidental workstation-specific code.
  6. Now have another team member try to use the script without your help.
When you complete these steps, you will have a script that should work for everyone.

Am I Doing This Right?

If you’re using your manual build system properly, you will be able to build your entire product:
  • With one command
  • From your Source Code Management system (SCM)
  • On any team member’s workstation
  • With no external environmental requirements (such as specific network drives). If you have issues with any of these items, have another look at your build process.

Warning Signs

  • Your build contains any manual steps.
  • Your build script has to be modified to run on different machines.
  • Only a few team members know how to edit the build script.

Build Automatically

How Do I Get Started?

You must already have a good build system in place to move to the next level with an automated build system.
  1. Select an automatic build system to use. Do not write your own.
  2. Obtain a “clean” machine to run on.
  3. Install your automatic build system, and configure it for your environment. Document every step of the install.
  4. That’s it! You can set up this type of system fairly easily, and the return on investment (known to management as ROI) usually reaches the break-even point in the first few months. If management doesn’t see the benefit, run the system on your own machine at first. People who have never used a CI system often need a live demonstration to appreciate how powerful the concept is.

Am I Using This Right?

If you’re using an automatic build system (or a CI system), you are far ahead of most software teams. But there are still a few questions you need to ask yourself:
  • Do you have tests in the system? After all, no one cares if it compiles if it doesn’t run.
  • Is anyone paying attention to the system? Are the notifications turned on?
  • Does your build get fixed quickly or stay broken for days?
  • Does your build finish in a reasonable time, or does it take too long to complete?
If you can answer these questions favorably, your team will be able to spend their days adding features instead of tracking down which line of code broke feature X sometime during the last six months!

Warning Signs

  • Your automatic build system breaks frequently.
  • Your team ignores broken builds.
  • The build stops running, and no one notices.

Track Issues

How Do I Get Started?

If you don’t currently have an issue tracking system, don’t wait. Don’t delay your transition until you can transfer every issue ever encountered.
That’s an admirable goal, but don’t wait until you have your manual system clean before using the automated system. Just start using it as soon as you can. Enter the new issues in your new system, and over time it will achieve the critical mass of information that makes it a vital resource. If you have the time to populate the new system, great! But don’t make it a requirement for use.
  1. Pick an issue tracking system (Appendix D, on page 172).
  2. Set up a test system for yourself, and learn how to use it.
  3. Generate a one-page quick-start guide for your internal users.
  4. Start keeping all new issues in this system.
  5. Move pre-existing issues over to the new system as time permits.

Am I Doing This Right?

If you track issues with any sort of a system, you’re doing great. The real question is whether you store enough information in the system and whether anyone uses the system internally. Use these questions to gauge your success:
  • Can you generate a list of the top-priority, unaddressed issues? How about the second-tier issues?
  • Can you generate a list of last week’s fixes?
  • Can your system reference the code that fixed the issue?
  • Do your tech leads use this system to generate to-do lists for development teams?
  • Does your technical support team know how to get information out of the system?
  • Can you system notify “interested parties” so tech support (and others) can see when an issue is fixed

Warning Signs

  • The system isn’t being used.
  • Too many small issues are in the system.
  • Issue-related metrics are used to evaluate team member performance.

Track Features

How Do I Get Started?

Getting started here is pretty much the same as How Do I Get Started? in the Issue Tracking section.

Am I Doing This Right?

You’re in good shape if the following is true:
  • You use this system as a first stop when it’s time to generate the next release’s feature list.
  • You routinely record new product ideas in the system.
  • Many of the submitted features are rejected. Otherwise, you’re culling them before you enter them.
  • You can generate the last product version’s “new feature” list by running a report from this system.
  • Your stakeholders can easily check on feature status, and they get warm fuzzies because it matches their expectations.

Warning Signs

  • No new features are being added.
  • Everything is priority one.
  • Features get added but never implemented.
  • Irrelevant features are being added.

Use a Test Harness

How Do I Get Started?

If your team has no tests at all, you may want to discuss it with your tech lead (or manager). You can add tests to your areas of responsibility to show the benefit, but for maximum benefit the entire team should participate as well.
If your team is already writing tests, find out what they’re using for a framework. Many developers write their own framework—don’t go there! But if anyone in your shop has settled on a standard framework or tool, find out what it is and why they selected it; leverage their experience and expertise.
Once you’ve selected a framework, use the defect-driven strategy to create tests for your code. We strongly suggest you create mock client tests, and that you run all your tests in a CI system. A CI system is the best way to assure the tests are run regularly.
  1. Select a testing tool or toolkit.
  2. Start adding tests to problem areas.
  3. Ensure that your tests are being run in an automatic build system.

Am I Doing This Right?

Your answers to these questions will make it clear if you’re on the right path:
  • Is your test suite effective? Are your tests catching bugs?
  • What are your code coverage14 numbers? Are they increasing over time?
  • Is the product you’re testing stable?
  • Are the tests being run automatically?
  • Do your tests tell you whether they pass or fail? (If you have to manually determine whether they passed or failed, they aren’t automated.)
  • Does everyone in your shop have the ability to add tests? (If not, the framework is probably too complicated.)

Warning Signs

Have another look at your strategy if your tests:
  • Aren’t being run
  • Never catch any problems
  • Take too long to run
  • Require significant effort to maintain

Pragmatic Project Techniques

Use The List

Maintain a prioritized list of things to be done with the estimated time required to address it and its status.

How to Get Started

  1. For an entire day, write down every task as you work on it (this will be your “finished” list).
  2. Organize whatever daily task list you do have into a formal copy of The List.
  3. Ask your tech lead to help you prioritize your work and add rough time estimates.
  4. Start working on the highest-priority item on The List—no cheating! If some crisis forces a lower-priority item higher, record it.
  5. Add all new work to The List.
  6. Move items to your finished list as you complete tasks (this makes surviving status reports and “witch-hunts” much easier). The act of creating The List forces you to organize and prioritize your work. Just as keeping a diary helps you think through and understand what you’ve been doing, The List helps you sort out your current workload but in a fairly high-level, lightweight way.
  7. Review The List every morning. Update it whenever new work pops up. . . especially the last-minute crisis tasks; you’re likely to forget about those when someone asks you what you on earth you did all last week.

You’re Doing It Right If…

  • Is every one of your current tasks on The List?
  • Does The List accurately portray your current task list?
  • Did the tech lead or customer help you to prioritize The List?
  • Is The List publicly available (electronically or otherwise)?
  • Do you use The List to decide what to work on next?
  • Can you update (and publish) The List quickly?

Warning Signs

  • You fail to add tasks to The List because you’re “too busy.”
  • More time is spent updating The List than completing the tasks.
  • It takes weeks for team members to complete individual items on their personal lists (hint: the items are too big).
  • The List is updated less than once a week.
  • Priorities on The List don’t match “real” priorities.
  • The List is a closely held secret, not visible to anyone outside your team.
  • In addition to the team’s list, there are other publicly available versions that differ.

Tech Lead

Have a Tech Lead in the Project. The tech lead has several major areas of responsibility that will vary by company and team composition. The following is a minimal list of a tech lead’s responsibilities:
  • Set direction for team members.
  • Orchestrate your project’s feature list.
  • Prioritize your project’s features.
  • Insulate your team from external distractions.

How to Get Started

If you aspire to be a tech lead, you need to prove you’re ready to handle the additional responsibility. Look over the job requirements, and strive to live up to them. Voluntarily perform as many of the tech lead duties as you can. Don’t wait for the job to fall into your lap; demonstrate that you are trying to earn the position and can handle it well.
Use The List for your personal work but also keep one for your team. Monitor work in progress while keeping an eye on upcoming projects.
Evaluate your team’s process. Locating the weak spots and finding practices or concepts to address problems will give you a new perspective. For example, if your team is having trouble keeping the code compiling, then you should set up a CI system on your desktop to help solve the problem.
Don’t give up if you aren’t promoted to tech lead right away. Continue learning and growing for the next assignment. Not everyone has the temperament for a tech lead role, but working toward it gives you a broader picture of the entire project, which makes you a more productive team member. You become a better developer by thinking about and considering how you’d be a tech lead.
If you’ve just become a tech lead, create a rough road map. Chart where the team currently stands and the direction you want them to go. What problems will you address? What work will you encourage?
Make a list of all known problems. Then survey the team to see if they know about additional problems. When you think you’ve arrived at a real list, decide which items you can address and which you can’t.
Daily meetings are a great way to keep track of your team’s work without smothering them.

You’re Doing It Right If…

As your team’s tech lead, you should be able to answer these questions favorably:
  • Do you know what every member of your team is working on?
  • Can you generate a project status summary in less than five minutes?
  • What are the next five to ten features for your product?
  • Can you readily list the highest-priority defects for your product?
  • What was the most recent problem you cleared up for a team member?
  • Would a team member come to you if they needed an important issue resolved?

Warning Signs

Here are some warning signs that your tech lead is ineffective or overbearing:
  • Lacks big-picture view of every team member’s work direction
  • Causes work to halt when they show up
  • Takes credit for the team’s work
  • Fails to solve problems, or worse, causes problems
  • Inaccurately forecasts work time lines
  • Is unaware of team members’ technical proficiencies and/or what team members want to learn
  • Is oblivious to personality clashes on the team

Coordinate and Communicate Everyday

How to Get Started

If you’ve never had daily meetings before, you’re in for a real treat! Here are a few ideas to get them rolling:
  • Be sure everyone knows the format (which questions you want answered).
  • Everyone must answer the questions. There are no passes, and no exceptions.
  • At first, be lenient on the time restriction. A lot of new information is exchanged in the beginning, so you must allow communication to flow freely.
  • Hold your meetings at the same time and in the same place, every day. Make daily meetings a habit, not a chore to keep track of.
  • Post topics that are discussed during daily meetings on a web page or plog
  • Pick a person to start the meeting, and then move clockwise (or counterclockwise) through the group. Randomly picking one team member after another is more apt to make them feel ambushed.
Stay Focused
Daily meetings can be a valuable tool if everyone stays on-topic. It’s important to be very specific in the meeting, Don’t say you’re “70 percent done.” Instead, say that today you added the login screen, and though it’s not functional yet, it should be tomorrow. Pause for a moment if someone says, for instance, that the login screen is broken, and ask them to describe the problem in more detail (e.g., “It doesn’t communicate with the authentication manager yet”). When a project is new, the tech lead runs this meeting, but eventually the leadership responsibility should rotate throughout the group. Use these daily meetings to grow your leaders in-house.
If a topic starts to take on a life of its own, or the meeting starts turning into a problem-solving session, the leader should quickly take it “offline” by having the involved team members get together privately after the main meeting. There’s no reason the entire team should have to listen to Jim and Sue brainstorm for half an hour on a problem that only they have. They can give everyone a short overview of the solution after they’ve found it.
Several prominent development methodologies insist you limit meeting times by having everyone stand. That works, but if the meeting participants are disciplined about being brief (or if the leader is disciplined about keeping everyone on-topic) standing shouldn’t be necessary. Try it both ways to see what works for your team.

You’re Doing It Right If…

If you are already having daily meetings, that’s great! Here are a few guidelines to be sure you stay on-track:
  • Are the meetings useful? If no one in the group is learning anything, the reports might be too terse. If more details are needed in a particular area, push those topics into a side meeting with a smaller group. However, the two-minute rule is a guideline, not a law. You may find thirty seconds is just fine, or you may need three minutes.
  • Are meetings consistently held the same time and place every day, or do they fluctuate? Having daily meetings at the same time and place makes it easy to remember. Meetings can move occasionally, but avoid mixing things up frequently.
  • If you stopped holding the meetings, would people complain? They should! The team should come to depend on the daily meeting to stay “in the loop.” If the meetings can be dismissed, then they weren’t providing value. The team should rely on the daily meeting as an invaluable resource.

Warning Signs

Daily meetings are a great tool. But like any tool, they can also be harmful if handled improperly. The following are a few warning signs that your daily meetings have drifted off-course:
  • Each team member takes ten minutes or more.
  • One team member consistently takes up as much time as the rest of the team put together.
  • People are heckled in a mean-spirited manner. Joking among team members is good (and to be encouraged), but if your daily meetings turn into sniping sessions, they’re not productive anymore.
  • Deal with the snipers.
  • Your meetings consistently start (or finish) late.
  • The meetings become content-free, with developers making claims such as “I’m still 90 percent done” or just “workin’ on the Frozbot.”
  • Team members ramble or forget to report things they’ve done. Privately ask these team members to write down what they’ve done, so they stay focused during meetings and keep their report concise. They would also do well to have their own copy of The List to help keep them organized.

Review All Code

How to Get Started

Code reviews are great tools! Once you get in the habit, you’ll wonder how you ever wrote decent code without them. Use these tips to get started:
  • Be sure everyone understands the type of code review you have planned. Review frequently on smaller blocks of code. Don’t wait for weeks, accumulating hundreds or thousands of lines of changes. No MAD reviews for your team!
  • Have one of your senior team members sit in on each code review for the first few weeks or months. This is a great way to share knowledge and get the reviews on a solid foundation.
  • Make sure your code reviews are lightweight. It’s better to review too little code than too much. Having two overlapping reviews is better than having one larger one.
  • Introduce a code change notification system (see Practice 14, Send Code Change Notifications,, on the following page) at this time. It’s a great complement to your code reviews, and it helps to remind team members who forget to ask for reviews.
  • Make sure you have management buy-in before requiring all team members to participate.

You’re Doing It Right If…

  • Do code reviews get an automatic approval? This shouldn’t happen unless everyone on the team is perfect.
  • Does every code review have major rewrites?If so, it indicates a problem somewhere: either with the coder, with the reviewer, or with the tech lead (who gave the directions that the coder and reviewer are using).
  • Do code reviews happen frequently? If the time between reviews is measured in weeks, you’re waiting too long.
  • Are you rotating reviewers?
  • Are you learning from the code reviews? If not, start asking more questions during your code reviews.

Warning Signs

  • Code reviews are infrequent.
  • The majority of code reviews are painful.
  • People avoid checking in their code because they don’t want a code review.
  • Team members who have reviewed code can’t explain what it does or why it was written.
  • Junior team members review only other junior member’s code.
  • Similarly, senior team members review only other senior member’s code.
  • A single team member is everyone’s preferred reviewer.

Send Code Notifications

How to Get Started

There are several ways you can introduce code change notifications.
We’ve used both manual and automatic systems. With a manual system, you type emails by hand (pasting in code diffs by hand) and send them to team members. With an automatic system, a program that watches your SCM generates notices and sends emails.
Both are valid approaches, but automatic is always preferable. However, getting an automatic system in place may be difficult in your environment; if that’s the case, use the manual method. Make sure your team knows about the notifications before they start arriving.

You’re Doing It Right If…

Notifications must be regular and trustworthy.
Don’t send out five-meg diffs!

Warning Signs

The only real problem you need to watch for here is dependability. The notifications must be reliable. If your team members don’t believe the mail will be sent after code changes, they won’t come to depend on notifications. This is easier to fix with an automatic system than with a manual one, but in either case, you must take this problem into account.

Tracer Bullet Development

How to Get Started

The best way to get started with TBD is to pick a project and try it out.
Review the concept with your teammates before you get started. We’d suggest you try a smaller project first to get a feel for how TBD works.
  • Define your system objects.
  • Define the interfaces between them.
  • Write the interface stubs.
  • Make the stubs talk with each other.
  • Fill in the stubs with functional code.

You’re Doing It Right If…

  • The entire system is always up and “running.”
  • Team members understand the system objects as well as “their” objects.
  • Team members feel comfortable helping out with other system objects.
  • You can rewrite large portions of your code base and nothing breaks.
Warning Signs
  • Team members argue for hours over the “right way” to design an interface.
  • The end-to-end system never actually runs end to end.
  • Builds are frequently broken because interfaces were changed and the consumers didn’t know.
  • You have only one big honking system object.
  • You have 700 itty-bitty system objects.
  • The team has been working for months and the system still doesn’t have compiling stubs.
  • The team has had compiling stubs for months and no working features are in place.
These are excerpts from the book. These are the summary from end of each of the chapter.

Chapter 1 – A Method in Madness

  • Make sure to do the following:
    • Work out why the software is behaving unexpectedly.
    • Fix the problem.
    • Avoid breaking anything else.
    • Maintain or improve overall quality.
    • Ensure that the same problem does not occur elsewhere and cannot occur again.
  • Leverage your software’s ability to show you what’s happening.
  • Work on only one problem at a time.
  • Make sure that you know exactly what you’re looking for:
    • What is happening?
    • What should be happening?
  • • Check simple things first.

Chapter 2 – Reproduce

  • Find a reproduction before doing anything else.
  • Ensure that you’re running the same version as the bug was reported against.
  • Duplicate the environment that the bug was reported in.
  • Determine the input necessary to reproduce the bug by:
    • Inference
    • Recording appropriate inputs via logging
  • Ensure that your reproduction is both reliable and convenient through iterative refinement:
    • Reduce the number of steps, amount of data, or time required.
    • Remove nondeterminism
    • Automate.

Chapter 3 – Diagnose

  • Construct hypotheses, and test them with experiments.
    • Make sure you understand what your experiments are going to tell you.
    • Make only one change at a time.
    • Keep a record of what you’ve tried.
    • Ignore nothing.
  • When things aren’t going well:
    • If the changes you’re making don’t seem to be having an effect, you’re not changing what you think you are.
    • Validate your assumptions.
    • Are you facing multiple interacting causes or a changing underlying system?
  • Validate your diagnosis.

Chapter 4 – Fix

  • Bug fixing involves three goals:
    • Fix the problem.
    • Avoid introducing regressions.
    • Maintain or improve overall quality (readability, architecture, test coverage, and so on) of the code.
  • Start from a clean source tree.
  • Ensure that the tests pass before making any changes.
  • Work out how you’re going to test your fix before making changes.
  • Fix the cause, not the symptoms.
  • Refactor, but never at the same time as modifying functionality.
  • One logical change, one check-in.

Chapter 5 – Reflect

“The six stages of debugging” and reads as follows:

  1. That can’t happen.
  2. That doesn’t happen on my machine.
  3. That shouldn’t happen.
  4. Why is that happening?
  5. Oh, I see.
  6. How did that ever work?

  • Take the time to perform a root cause analysis:
    • At what point in your process did the error arise?
    • What went wrong?
  • Ensure that the same problem can’t happen again:
    • Automatically check for problems.
    • Refactor code to remove the opportunity for incorrect usage.
    • Talk to your colleagues, and modify your process if appropriate.
  • Close the loop with other stakeholders.

Chapter 6 – Discovering that you have a problem

  • Make the most of your bug-tracking system:
    • Pick one at an appropriate level of complexity for your particular situation.
    • Make it directly available to your users.
    • Automate environment and configuration reporting to ensure accurate reports.
  • Aim for bug reports that are the following:
    • Specific
    • Unambiguous
    • Detailed
    • Minimal
    • Unique
  • When working with users, do the following:
    • Streamline the bug-reporting process as much as possible.
    • Communication is key—be patient and imagine yourself in the user’s shoes.
  • Foster a good relationship with customer support and QA so you can leverage their support during bug fixing.

Chapter 7 – Pragmatic Zero Tolerance

  • Detect bugs as early as possible, and fix them as soon as they come to light.
  • Act as though bug-free software was an attainable goal, but temper perfectionism with pragmatism.
  • If you find yourself faced with a poor quality codebase, do the following:
    • Recognize there is no silver bullet.
    • Make sure that the basics are in place first.
    • Separate clean code from unclean, and keep it clean.
    • Use bug triage to keep on top of your bug database.
    • Incrementally clean up bad code by adding tests and refactoring.

Chapter 8 – Special Cases

  • When patching an existing release, concentrate on reducing risk.
  • Keep on the lookout for compatibility implications when fixing bugs.
  • Ensure that you have completely closed any timing windows, not just decreased their size.
  • When faced with a heisenbug, minimize the side effects of collecting information.
  • Fixing performance bugs always starts with an accurate profile.
  • Even the most restricted communication channel can be enough to extract the information you need.
  • Suspect your own, ahead of third-party, code.

Chapter 9 – The Ideal Debugging Environment

  • Automate your tests, ensuring that they do the following:
    • Unambiguously pass or fail
    • Are self-contained
    • Can be executed with a single click
    • Provide comprehensive coverage
  • Use branches in source control sparingly.
  • Automate your build process:
    • Build and test the software every time it changes.
    • Integrate static analysis into every build.

Chapter 10 – Teach your Software to Debug Itself

  • Use assertions to do the following:
    • Both document and automatically validate your assumptions
    • Ensure that your software, although robust in production, is fragile during debugging
  • Create a debug build that
    • Is compiled with debug-friendly compiler options
    • Allows key subsystems to be replaced by debugging equivalents
    • Builds in control that will prove useful during diagnosis
  • Detect systemic problems, such as resource leaks and exception handling issues, preemptively.

Chapter 11 – Anti Patterns

  • Keep on top of your bug database to ensure that it accurately reflects your true priorities.
  • The polluter pays—don’t allow anyone to move onto a new task until they’ve completely finished their current one. If bugs come to light in their work, they fix them.
  • Make a single team responsible for a product from its initial concept through deployment and beyond.
  • Firefighting will never fix a quality problem. Take the time to identify and fix the root cause.
  • Avoid “big bang” rewrites.
  • Ensure that your code ownership strategy is clear.
  • Treat anything you don’t understand as a bug.

Can a man cast from his heart the pain of loss? No but he can find joy in something won.

Tragedies do happen. We can discover the reason, blame others, imagine how different our lives would be had they not occurred, but none of that is important, they did occur and so be it. From there onward we must put aside the feat that they evoke in us and being to rebuild.

There is no tragedy, only the unavoidable. Everything has its reason for being; you need only to distinguish what is temporary and what is lasting. What is temporary, the unavoidable. And what is lasting? The lessons of unavoidable.

Every human being sometime has tragedy enter hist life; it might be the destruction of a city, the death of a son, an unproved accusation, a sickness that left one lame forever. At that moment God challenged one to to confront him and to answer this question, “Why do you cling fast to an existence so short and so filled with suffering? What is the meaning of your struggle? The man who did not know to answer this question would resign to himself, while another, one who sought out a meaning to existence, feeling that God had been unjust, would challenge his own destiny. It was at that moment that a fire of a different type descended from the heavens – not the fire that kills but the kind that tears down ancient walls and imparts to each human being his true possibilities. Cowards never allow their hearts to blze with this fire; all they desire is for the changed situation to quickly return to what it was before, so they can go on living their lives and thinking their customary way. The brave, however, set a fire to that which was old and even at the cost of great internal suffering, abandon everything, including God, and continue onward. The brave are always stubborn. From heaven God smiles contentedly, for it was this that He desired, that each person take into his hands the responsibility for his life. For in the final analysis He had given His children the greatest gift of all gifts; the capacity to choose and determine their acts. Only those men and women with sacred flame in their hearts had the courage to confront Him. And they alone knew the path back to His love, for they understood that tragedy was not a punishment but a challenge.

He had fled from doubt. From defeat. From moments of indecision. But the Lord was generous and had led him to the abyss of the unavoidable, to show him that man must choose – and not accept his fate.

God was infinite in his mercy, and implacable in His severity with those who lacked courage to dare.

Is it always necessary to leave? It is always necessary to know when a stage of one’s life has ended. If you stubbornly cling to it after the need has passed, you lose the joy and meaning of the rest. And you rise being shaken to your senses by God.

Lord hearth the prayers of those who ask to put aside hatred. But He is deaf to those who would flee from love.

For many generations men tried to impose their will by force; they spoke of what they wanted but cared not what the people thought and all those empires have been destroyed. Our people have grown because they leaned how to listen; this is how we develop trade, by listening to what the other people desire and doing whatever was possible to satisfy him. The result is profit.

If you have a past that dissatisfies you, forget it now. Imagine a new story of your life, and believe in it. Concentrate only on those moments in which you achieved what you desired and this strength will help you accomplish what you want.

A child can always teach an adult three things; to be happy for no reason; to always be busy with something; and to know how to demand with all her might that which she desires.

Children are able to overcome what took place because they have no past – for them everything that matters is only the present.

Everything that happened could have happened but did not is carried with the wind and leaves no trace. Life is made of our attitudes. And there are certain things that the Gods oblige us to live through. Their reasons for this does not matter, and there is no action we can take to make them pass by.

Our souls are prisoners of the terror of death.

Freedom is to feel what the heart desired with no thought to the opinion of the rest.

It was then as he discovered death could elude him, fear of death returned. There was still the possibility of seeing the ocean, of finding a wife, having children, and completing his work in his shop.

Every man has the right to doubt his task, and to forsake it from time to time; but what he must not do is forget it. Whoever doubts not himself is unworthy for in his unquestioning  belief in his ability; he commits the sin of pride. Blessed are those who go through moments of indecision.

Souls too, like rivulets and plants, needed a different kind of rain; hope, faith, a reason to live. When this did not come to pass everything in that soul died, even if the body went on living, and people could say “Here this body was once a man”.

For some more refer to the link.

Being a follow up book does not impede the relevance of this book. In the first book the author illustrates how innovations failed in large corporations, while it succeeded in smaller companies in a very lucid way and backed with right amount of examples. In this book Christensen uses the same lucid way of illustrating how innovations, read disruptions, can happen in organizations. He gives solid reasoning on why it does not happen and a solution on how it can be made to happen.

The Growth Imperative

In the first chapter titled “The Growth Imperative” the authors highlights how the need to satisfy the share market drives the executives to concentrate on what gives a high rate of growth in the current quarter, current financial year, rather than concentrating on something that will potentially provide more growth after the next few years.
The second reason he says is that people get carried away by appearances. The example he quotes is that originally people thought that by having wings it will be possible for them to fly. What they did not know is fluid dynamics which is actually the science that helps humans fly today. Similarly companies tend to assume that aping others who succeeded they will also succeed. Instead they should understand the science or reasoning behind the success before attempting what other successful companies are doing.
Many company’s today would tend to follow Steve Jobs’ example and say I do not want to ask the people what they want, I will give them what they want. A company that blindly follows this technique is bound to fail. They need to understand what the users really want to do.

How can we beat out most powerful competitors?

In the second chapter the authors show how an innovative disruption takes place. The authors say that typically a product or a service initially goes through a phase when it is not sufficiently good for the end users. This is the phase of disruption when companies try to outdo each other and build proprietary models and earn a large profit. Slowly the product or service starts becoming better and better and soon it exceeds the expectations of a certain set of users. The users start getting a feeling that they are being overcharged for the product/service. Under these circumstance if a new product/service is launched which meets the functional and price points of these over served or other unserved customers then disruption of the earlier product or service has begun. The earlier company is to ignore this disruption as it is engrossed in refining its product or service further to suit the needs of its premier customers and it tends not be bothered by the disruptive product or service scrapping away at what it considers low revenue, low profit market from its perspective. Soon this disruptive product or service becomes better. The earlier product or service has reached a revenue plateau and growth becomes difficult. This sends the earlier company into a downward spiral. And the disruptive company now gets into the upward spiral following the same route the earlier one did when it started off.

The author goes back to the example quoted in the Innovator’s Dilemma of how the mini steel mills upended the Integrated Steel Companies. Initially most of the steel companies were Integrated Steel Companies which were giant installations and could create all types of steel products required from rebars to sheets to beams and the whole lot. When the mini mills were launched they first were capable of making only rebars. The companies that purchased these mini mills made a lot of profit in making rebars as their cost of running the company was much less than the Integrated steel mills. These large mills were glad to let go off the rebar production to these small companies. Soon all the large companies stopped making rebars and the small companies felt in a drop in their profit levels as now they were competing with their peers.]
As a next step the mini mills became capable of producing Bars and Rods. This was again a low margin game for the large manufacturers and they let go off this. It followed the same cycle and soon the smaller companies found themselves in the same low profit situation. They now upgraded themselves to manufacture structural steel and it followed the same cycle and then they upgraded themselves to manufacture sheets which has followed the same route.
In the 70s the Integrated Steel Companies accounted for practically 100% of the steel production in the US. Today they account for only 50% of the output, the rest is produced by the companies using mini mills.
The author highlights that in most cases the executives tend to flee rather than fight when they are faced with a disruption in what they consider “low profit” market in their definition. They tend to concentration on innovation which leads to sustaining their current profit levels.
The authors stress that while it is important to have “sustaining” innovations that will help the sustenance of the current business of an organization, it would be wrong to ignore the disruptive innovations which may appear low margin game from the perspective of the company, but can turn out to be big winners in the long run.

The authors classify disruptions into two types
a) Low End Disruptions. These are the ones like the mini steel mills which tend to serve the over served customers
b) New Market Disruptions. These are the ones that address the non-consumers of a product or service by making it more attractive and by improving the performance.

Summary of the Chapter

Disruption is a theory: a conceptual model of cause and effect that makes it possible to better predict the outcomes of competitive battles in different circumstances. The asymmetries of motivation chronicled in this chapter are natural economic forces that act on all business people, all the time. Historically, these forces almost always have toppled industry leaders when an attacker has harnessed them, because disruptive strategies are predicated upon competitors doing what is in their best and most urgent interest: satisfying their most important customers and investing where profits are most attractive. In a profit-seeking world, this is a pretty good bet.
Not all innovative ideas can be shaped into disruptive strategies, however, because the necessary preconditions do not exist; in such situations, the opportunity is best licensed or left to the firms that are already established in the market. On occasion, entrant companies have simply caught the leaders asleep at the switch and have succeeded with a strategy of sustaining innovation. But this is rare. Disruption does not guarantee success: It just helps with an important element in the total formula. Those who create new-growth businesses need to get on the right side of a number of other challenges, to which we will now turn.

What products Customers will want to buy?

This is a question that every business has to keep asking itself time and again. The typical way to answer this question is to do a market survey, look at their consumption patterns of other similar or competing products or ask the audience what kind of product they wish to have then to base the product or service based on the answers to these surveys.
The key aspect that the authors point towards in this chapter is that it is not sufficient to know what the customers want, it is to understand what problem are they trying to solve and which will be the best way to solve the problem. The authors cite a very very good example to illustrate this. The case study is about a quick service restaurant that sells milk shakes. This quick service restaurant wished to improve its sales. The first approach by the marketers was to segment the milkshakes based on its attributes and the customers based on their profile and try and find out which category of customers would buy milk shakes. Now they tried to figure out how they could change the milkshakes to satisfy the different profiles of customers. The possible options were to make the milkshakes thicker, more chunkier, or thinner, or less costly or more chocolatier etc. On the face of it, the approach seems fool proof. When implemented it did not yield any results. The sales continued to be flat.
The Restaurant then hired a new set of researchers to look into what can be done to improve the sales. These researchers tried to answer the query “Why are the customers buying the milkshakes? The answer they got was something as follows:
1. In the morning a customer buys a milkshake so that they can drink something on the way to their workplace. They need the milkshake such that it lasts them till they reach their destination which would typically be about half an hour. They were not hungry enough but would be so by the time they have been at work for an hour or two. They needed something that would sustain them till a reasonable lunch time. The container should be such that it is easy to handle in vehicle with one hand and should not create any mess as most of them would be in their work clothes.
2. Most of the other times it was found that the buyers of milkshakes were parents who were buying it for their children as an alternate to junk food. It was also found that in many cases these were dumped half finished as the children could not finish the drink fast enough for their parents to wait or were full by the time they finished it.

This indicated that the milkshakes need to be of two different natures depending on the time of the day and not based on the type of customer who purchased the drink. It needed to be based the “purpose” it was expected to serve. Based on this the restaurant started making thicker milks shakes in the morning and started adding fruit bits in the morning period and later made it lighter and packaged in in a smaller containers to cater to, potentially the same or similar customers, but to serve a different purpose.

Thus it is important to understand the problem that the product or service is to solve and not just the demographics of the people buying them. The same product or service may need to be packaged different depending on the purpose for which the customer is buying it.

The authors go on to say there are four reasons on why the managers fall back on attribute based segmentation of the customers:
1. Fear of Focus: When one is focussing on making a product or service a particular job well, it starts becoming obvious that it cannot be used to address other problems. And when this happens the audience that it can address becomes narrower which in turn means that the growth is going to be limited. So the only way seems to be to pack as many attributes as possible so that it can address a larger and larger audience. While focus helps make the product/service better it is also scary as it may narrow the set of customers who will be interested in the product or service.
2. Demand for Crisp Quantification: Most executives hire market research to streamline resource allocation based on the size of the opportunity, and not to understand how customers and markets work. IT systems gives teh ability to collect, aggregate and summarize data in various ways to help managers make better decisions. Typically these reports show how much if each product is being sold, how profitable each is, which customers are buying which products, and what costs and revenues are associated with servicing each customer. IT systems also report revenues and costs by business units, so that managers can measure the success if the organization for which they have responsibility. When managers look at this data and start building products and services the tendency is to build one-size-fits-all type of products and services. It does not take into account the variety of ways the product/service is being used under different conditions by the customer. The product/service tend to get feature rich which may still not be able to serve the purpose for which the customer is buying the product/service. The basic problem is that managers are fixated on understanding the ‘size of the opportunity’ rather than the customer.
3. Structure of Retail Channels: Many retail and distribution channels are organized by product categories rather than by the nature of jobs that the customer is trying to address. E.g. to make a shelf a person needs drills, sanders, hammers and saws. When the customer walks into a hardware shop they are looking for drills, sanders, hammers and saws. Now if an inventive company where to come up with a tool which serves as all of the above the retailer will be at a loss on which shelf to put it in. It will not fit either of the shelves that they are accustomed to. Also the customer has not been trained to ask, give me a tool to build a shelf. This limits the innovations to a certain extent.
4. Advertising Economics influence people to target products at customers rather than at circumstances: Advertisements are expensive and every company tries to use a cost effective way of advertising. It seems easier to device a communications strategy and to choose the most cost-effective marketing media if consumer markets are sliced along dimensions such as age, gender, lifestyle, or product category. The same seems true if the marketers slice commercial markets by geography, industry, or size of business. If one were to attempt to communicate to the needs of the customer it can get confusing. E.g. if the quick service restaurant were to advertise to the “office goer” to pick up the thick milkshake in the morning for the commute, and to pick up the “smaller and thinner” milkshake for the kids in the afternoon or evening and to pick up the “hamburger” for a quick lunch, the message can be confusing as the same restaurant is advertising different aspects to the same customer. Also it can end up sullying the brand value of the organization. On way the organizations address this is by creating different brands to indicate and mean different things. One example that the authors quote is that of the Marriott Corporation. They have created a brand architecture which tells the customer to hire a Marriott Hotel when the job is to convene a major business meeting, and to choose a Courtyard by Marriott when the job is to get a clean, quiet place to work into evening. We learned to hire a Fairfield Inn my Marriott when job is to find an inexpensive place to stay as a family, and Residence Inn by Marriott to find a home away from home. The Marriott brand remains unsullied by all of this, because the “purpose” brands make the job clear. If they had positioned “Courtyard” as a cheaper, lower-quality solution to the same job then it could have sullied the brand of Marriott.

Dangers of asking the customer to change jobs

The other aspect that the authors point out in this chapter is that “At a fundamental level, the things that people want to accomplish in their lives don’t change quickly. The improvements in a product or service that a customer can utilize in any application or tier of market tend to be quite flat. Given this slow growth of usage of new features, an idea stands little chance of success if it requires customers to prioritize jobs they haven’t created about in the past. Customers do not just “change jobs” because a new product becomes available. Rather, the new product will succeed to the extent it helps customers accomplish more effectively and conveniently what they are already trying to do.

Summary

Identifying disruptive footholds means connecting with specific jobs that people – your future – customers – are trying to get done in their lives. The problem is that in an attempt to build convincing business cases for new products, managers are compelled to quantify the opportunities they perceive, and the data available to do this are typically case in terms of product attributes or the demographic or psychographic profiles of a given population of potential consumers,. This mismatch between the true needs of consumer and the data that shape most product development efforts leads most companies to aim their innovations at nonexistent targets. The important of identifying these jobs to be done goes beyond simply finding a foothold. Only by staying connected with a given job as improvements are made, and by creating a purpose brand so that customers know what to hire, can a disruptive product stay on its growth trajectory.

Who are the best customers for our products?

In this chapter the authors try to give an idea of what kind of customers will be a good base to start with for a disruptive innovation. For this they refer to the earlier chapters where they have outlined the two types of disruptions:
a) Low End Disruptions. These are the ones like the mini steel mills which tend to serve the over served customers
b) New Market Disruptions. These are the ones that address the non-consumers of a product or service by making it more attractive and by improving the performance.
The first type of disruptions target the over served customers while the new has to try and find new customers. The first one is relatively easy while the later one is not so easy.
The authors give three examples of how the nonconsumer market was captured. The first example is of how transistor radios from Sony captured the market over the tube radios from RCA even though the transistors began its life in hearing aid then moved on to low end radio receivers. The low end radio receivers from Sony caught the fancy of the consumers who could not afford the expensive to buy and expensive to maintain tube radios. It was also attractive to carry around your radio. Soon the quality of these radios improved sufficiently enough to beat the tube radios and to drive RCA to shut shop.
The second example that is provided is the advent of angioplasty which is today preferred to an open heart bypass surgery as it is equally effective. Initially angioplasty was suggested only for patients with limited blockages and the process itself was carried out by relatively low end surgeons and not the cardio specialists. Over a period of time it has come to become the dominating technique.
The third example which the authors suggest is something that they are predicting and not something that has happened so far. It is the usage of solar based equipment over electricity dependent equipment. The authors suggest if the makers of solar powered devices target the nonconsumers in Africa and other developing countries there is a potential that they could attract a mass market. This is yet to be seen although there is some traction.

The authors have indicated that most companies shy away from capturing the nonconsumer market and try to make inroads into areas where there are already well established players. The authors suggest that taking on well established players is foolhardiness as they quite entrenched with their customers and it requires a lot of money power to steal the customers from them. One of the established players fail to take notice of the disruptions is that they are so smug in their current profit and the growth rate they feel that any low end disruption is not worth worrying about and when it gets worrisome, the phenomenon called “threat rigidity” sets in. The instinct of threat rigidity is to cease being flexible and to become “command and control” oriented – to focus everything on countering the thread in order to survive. This rigidity ultimately leads to the downfall of the organization. Instead if they see it as an opportunity there are chances that they will succeed in taking the right steps and thrive. As a solution to avoiding this “threat-rigidity” the authors suggest that the first way to get commitment the management is to use the threat as a lever to get resources and funding for the start up of countering the disruptive forces and then slowly present the opportunity and sustain the resources. The example quoted is the reaction of the newspaper publications to online publishing. The first course of action was to publish scanned copies of their newspapers so that their consumers could read the same newspaper online instead of the physical newspaper. Soon they realized the opportunity and spun off companies which would manage the online publications and now most of the publications are comfortable with online publications.
The other suggestion that the authors make is that reaching new markets requires disruptive channels. The example they quote is of how Sony’s distribution channel of using discount stores to sell their transistor radios drove out the appliance stores. The appliance stores sold premium goods had a good after sales service channel while the discount stores had no such after sales servicing capability. But the low cost of the goods meant that the consumers did not expect an after sales service.
The other example of a failure that is quoted involves join venture between Intel and SAP which tried to provide lower-priced, easier-to-implement ERP package to the market through the same channel that sold the high end ERP system which required complex implementation and provided high returns. This sales channel completely ignore the low end package as it felt that the returns were not commensurate to the effort that they would put in.

Summary

What kind of customers will provide the most solid foundation for future grown? You want customers who have long wanted your product but were not able to get one until you arrived on the scene. You want to be able to easily delight these customer, and you want them to need you. You want customers whom you can have all to yourself, protected from the advances of competitors. And you want your customers to be so attractive to those who you work with that everyone in your value network is motivated to corporate in pursuing the opportunity.
The search for customers like this is not a quixotic quest. These are the kinds of customer that you find when you shape innovative ideas to fit the four elements of pattern of competing against nonconsumption.
Despite how appealing these kind of customers appear to be on paper, the resource allocation process forces the companies, when faced with an opportunity like this, to pursue exactly the opposite kinds of customers: They target customers who already are using a product to which they have become accustomed. To escape this dilemma, managers need to frame the disruption as a threat in order to secure resource commitments, and then switch the framing for the team charged with building the business to be one of a search for growth opportunities. Carefully managing this process in order to focus on these ideal customers can give new growth ventures a solid foundation for future growth.
The four elements that can be used to determine the right kind of customers for nonconsumption market are as follows:
1. The target customers are trying to get a job done, but because they lack the money or skill, a simple, inexpensive solution has been beyond reach.
2. These customers will compare the disruptive product to having nothing at all. As a result, they are delighted to but it even though it may not be as good as other products available at high prices to current users with deeper expertise in the original value network. The performance hurdle required to delight such newmarket customers is quite modest.
3. The technology that enables the disruption might be quite sophisticated, but disruptors deploy it to make the purchase and use of the product simple, convenient, and foolproof. It is the “foolproofedness” that creates new growth by enabling people with less money and training to begin consuming.
4. The disruptive innovation creates a whole new value network. The new consumers typically purchase the product through new channels and use the product in new venues.

Getting the Scope of Business Right

In this chapter the authors discuss the wont of the companies to outsource what they consider is not their “core competency”. The authors argue that while this may be true in some cases, it need not be always true. They point out that while it may truly not be a “core competency” of the company it may be necessary for the company to make it, its “core competency” to maintain a healthy competitiveness the market.
The example given is that of IBM which invented the Personal Computer. For a long time IBM had the largest share of the mainframe market. The manufacturers who manufactured components for the mainframe had lived a miserable, profit-free existence while IBM rolled in profits precisely because they had outsourced the manufacturing of the components. IBM did what it was best at, assembly of the mainframes. When it invented the Personal Computer it adopted a similar strategy and it outsourced the microprocessor manufacturing to Intel and the development of the Operating to Microsoft. The rest, as they say, is history for everyone to see. Since manufacturing of the PC became so commoditized, IBM was superceded by others and it became a loss making venture for IBM.
The authors indicate that the two factors that determine this are the concept of “interdependence” and “modularity”. To quote the authors
“The architecture of any product determines its constituent components and subsystems and defines how they must interact – fit and work together – in order to achieve the targetted functionality. The place where any two components fit together is called an interface. Interfaces exist within a product, as well as between stages in the value added chain. E.g., there is an interface between the design and manufacturing, and another between manufacturing and distribution.
An architecture is interdependent at an interface if one part cannot be created independently of the other part – if the way one is designed and made depends on the way the other is being designed and made. When there is an interface across which there are unpredictable interdependencies, then the same organization must simultaneously develop both of the components if it hopes to develop either component.
Interdependent architectures optimize performance, in terms of functionality and reliability. This architecture may also be deemed to be proprietary.
In contrast, a modular interface is a clean one, in which there are no unpredictable interdependencies across components or stages of the value chain. Modular components fit and work together in well understood and highly defined ways. A modular architecture specifies the fit and function of all elements so completely that it doesn’t matter who makes the components of subsystems, as long as they meet the specifications. Modular architectures optimize flexibility, but because they require tight specification, they give engineers fewer degrees of freedom in design. As a result, modular flexibilty comes at the sacrifice of performance.

For success authors say that in a situation where the product is not yet “good enough” a proprietary architecture helps success as one can optimize the components to perform better and better. But once the product reaches a stage where the product has become too good for its own good, it is time to modularize and hand over the manufacturing of components to others who can manufacture it at a lower cost bringing down the overall cost of the product.

By the time this happens the company should have created another product which it can now take through the same cycle so as to sustain its revenue and profitability.

Summary

There are few decisions in building and sustaining a new-growth business that scream more loudly for sound, circumstance-based theory than those addressed in this chapter. When the functionality and reliability of the product are not good enough to meet customers’ needs, then the companies that will enjoy significant competitive advantage are those whose product architectures are proprietary and that are integrated across the performance-limiting interfaces in the value chain. When the functionality and reliability become more than adequate, so that speed and responsiveness are dimensions of competition that are not now good enough, then the opposite is true. A population of nonintegrated, specialized companies whose rules of interaction are defined by modular architectures and industry standards holds the upper hand.
At the beginning of a ware of new-market disruption, the companies that initially will be most successful will be integrated firms whose architectures and proprietary because the product isn’t yet good enough. After a few years of success in performance improvement, those disruptive pioneers themselves become susceptible to hybrid disruption by a faster and more flexible population of nonintegrated companies whose focus gives them lower overhead costs.
For a company that serves customers in multiple tiers of the market, managing the transition is tricky, because the strategy and business model that are required to successfully reach unsatisfied customers in higher tiers are very different from those that are necessary to compete with speed, flexibility, and low cost in lower tiers of market. Pursuing both ends at once and in the right way often requires multiple business units – a topic that we address in the next two chapters.

How to avoid commoditization?

History proves that all products become commoditized over a period of time and nothing much can be done about it. The authors indicate that history also shows that while commoditization is in progress somewhere in the value chain, a reciprocal process of decommodization is at work somewhere else in the value chain. They say that it is important to be able to figure out where in the value is commoditization is in progress and leverage that to reduce costs while at the same time identifying areas where decommoditization is in progress and catch the disruptive wave in that area.
The authors give the example of the PC assembly market. Some profits stayed with the assembler, while most of it flowed to Microsoft, Intel, the Disk Manufacturers and the DRAM manufacturers. Amongst the Disk Manufacturers IBM was in the forefront as the 3.5″ disk manufacturers. The performance of these disks were more than sufficient for the PCs in the 90s. This meant that disk assemblers like Maxtor and Quantum started dominating this field as the profits to be made in these disks dropped to such a level that IBM found it unsustainable. But IBM moved to 2.5″ disks which were to be used in notebook computers and these disks had not become as commoditized. Soon the makers of the disk found that improving capacity of the disks and bettering the read write head in the disk will yield more profit. Soon a set of companies which specialized in these two fields came up and provided the desired improvement. This lead to the reduction of profits of the disk assemblers and the head and disk manufacturers started profiting more. In similar lines Bloomberg started off as a company that provided simple data on securities prices, subsequently they integrated forward, automating much of the analytics associated with the security prices. By doing this they enabled a large set of people to access insights which formerly only highly experienced securities analysts could derive. They further integrated forwards by allowing portfolio managers to now execute trades from their terminals over their owned Electronic Communications Network without needing a broker or a stock exchange.
Intel adopted a reverse strategy. They started off as a microprocessor company, but soon found that it would be better if they created integrated mother boards as that would be a larger chunk of the profit and as there was demand for more performance from the motherboards Intel found it easy to grow up the chain to become a board manufacturer in addition to be a microprocessor manufacturer.
The authors highlight once again and say that “core competence” as is used by many managers, is a dangerous inward-looking notion. “Competitiveness is far more about doing what customers value than doing what you think you’re good at”.

Summary

These findings have pervasive implications for managers seeking to build successful new-growth businesses and for those seeking to keep current businesses robust. The power to capture attractive profits will shift to those activities in the value chain where the immediate customer is not yet satisfied with the performance of available products. It is in these stages that complex, interdependent integration occurs – activities  that create steeper scape economics and enable greater differentiabiltiy. Attractive returns shift away from activities where the immediate customer is more than satisfied, because it is here that standard, modular integration occurs. We hope that in describing this process in these terms, we might help managers to predict more accurately where new opportunities for profitable growth through proprietary products will emerge. These transitions begin on the trajectories of improvement where disruptors are at work, and proceed upmarket tier by tier. This process creates opportunities for new companies that are integrated across these not-good-enough interfaces to thrive, and to grow by “eating their way up” from the back end of an end-use system. Managers of industry-leading businesses need to watch vigilantly in the right places to spot these trends as they being because the process of commoditization and de-commoditization both begin at the periphery and the core.

The authors quote the “The Law of Conservation of Attractive Profits” postulated by Chris Rowen. This law states that in the value chain there is a requisite juxtaposition of modular and interdependent architectures, and of reciprocal process of commoditization and de-commditization, that exists in order to optimize the performance of what is not good enough. The law states that when modularity and commoditization cause attractive profits to disappear at one stage in the value chain, the opportunity to earn attractive profits with proprietary products will usually emerge at an adjacent stage.

Is your organization capable of disruptive growth?

In this chapter the authors discuss about how to create an atmosphere in the organization such that the employees can come up with disruptive products and these can be discovered, grown and sustained in the organization. They begin the chapter by stating that many innovations do not fail because of some fatal technological flaw or because the market isn’t ready, but because the responsibility to build these businesses is given to managers or organizations whose capabilities aren’t up to the task.
The three key aspects that can enable or become a bottleneck in the development of a disruptive product in an organization are “Resources”, “Processes” and “Values”.
“Resources” are human resources, equipment, technology, product designs, brands, information, cash and relationship with suppliers, distributors and customers. These tend to be flexible and can be easily transported across boundaries within the organization and also across organizations.
The authors stress that in growing a disruptive product the key is to identify the right manager. The authors go on state that typically when a CEO is looking for somebody to lead a new disruption the person picked up is somebody who has had a string of successes in the past, has been “decisive”, has “good communication”, has “good people’s skill” and is “result oriented”. The assumption is that past successes will translate into future successes too.
The authors argue while these skills may count for something these are not the only things that should be considered. They liken the experience that the managers have been through to an education that one has in the schools and colleges. They stress that it is important to understand what the managers have learnt from their past and see if that is good enough and sufficient for them to lead a new disruptive product rather than looking at if they have been successful at what they have attempted to do.
They argue that managers who have been very successful in a stable business unit are likely to have gained skills in sustaining and bettering the business unit. They will be ill-fit in a starting up something new because they have not had experience in doing something like that in the past and the skills required to setup something afresh requires a separate skill set.

As the companies grow the patterns of interaction, coordination, communication and decision making through which they accomplish the tasks in the company are “Processes”. These processes will a mix of formal documented processes and a set of informal undocumented processes which are unconsciously followed. These processes would have evolved based on the nature of the tasks that the organization carries out and these would have refined and honed over a period of time and would have reached a stage where anybody following these processes would be able to accomplish the task and the human factor takes a lesser importance in the accomplishment of the task.
Now when a new-growth businesses is to be started the tendency will be to reuse the processes that have been successful so far in running the mainstream business. This more often than not will turn out to be a disability than a capability for the new-growth business. The processes that are good for sustaining and growing an existing business are very unlikely to be suited for a new-growth business. So it is important to come up with the right set of “Processes” for a new-business growth to succeed rather than trying to use the existing processes.

The authors wish to stress that by “Values” they mean more than “Ethical Values”. By “Values” they man the standards by which the employees make prioritization decisions – Those by which they judge whether an order is attractive or unattractive, whether a particular customer s is more important or less important than another, whether a idea for a new product is attractive or marginal, and so on.
While Resources and Processes are enablers that define what an organization can do, “Values” are constraints which define what an organization cannot do. E.g. if the structure of the company’s overhead costs requires it to achieve a gross profit margins of 40 percent, a powerful value or decision rule will have evolved that will encourage employees not to propose, and senior managers to kill, ideas that promise gross margins below 40 percent.
Typically the values of successful firms get defined in two dimensions, the first one is along the profitability and the second is around the size of the returns or how big is the business. For a large company both these numbers would tend to be on the larger side. For a company with such values, it will be very difficult to launch a disruptive product as these will find it difficult to yield those profit margins and more importantly will not be able to show large revenues in the initial stages.
Given this fact the authors stress that it is important that disruptive business be given the right home where the “Resources”, “Processes” and “Values” are conducive to grow such a business are are not bulldozed by the existing “Resources”, “Processes” and “Values”.

Summary

Managers whose organizations are confronting opportunities to grow must first determine that they first have the people and other resources required to succeed. They then need to ask two further questions: Are the processes by which work habitually gets done in the organization appropriate for this new project? And will the values of the organization give this initiative the priority it needs? Established companies can improve their odds for success in disruptive innovation if they use functionally oriented and heavy weight teams where each is appropriate, and if they commercialize sustaining innovations in mainstream organizations, but put disruptive ones in autonomous organizations.
A primary reason successful innovation seems difficult and unpredictable is that firms often employ talented people whose management skills were honed to address stable companies’ problems. And often, managers are set to work within processes and values that weren’t  designed for the new task. Instead of accepting one-size-fits-all policies, if executives will spend time  ensuring that capable people work in organizations with processes and values that match the task, they will create major point of leverage in successfully creating new growth.

Managing the Strategy Development Process

In this chapter the authors describe how organizations can come up with the right strategy when building a new business. The authors argue that while executives are obsessed with finding the right strategy, they can actually wield greater leverage by managing the process used to develop the strategy – by making sure that the right process is used in the right circumstances.
The authors describe that there are two ways that strategies develop in any organization; the first one is the deliberate strategy and second is the emergent strategy. The first one as the name indicates is the dwell defined consciously defined strategy. The second strategy come based on the day to day experiences of the employees carrying out the tasks. These employees knowingly or unknowingly define these strategies based on day to day challenges that they keep facing.
The authors suggest that the Role of Resource Allocation is a key driver of Strategy Development. They suggest that as the employees take decisions to shuffle the resource allocation, be it cash, or human resources, or equipment, based on the daily situation, a new strategy emerges which transforms and refines the current strategy.
The authors illustrate this by giving example of Intel which manufactured DRAMS and EPROMS and microprocessors. Intel based its resource allocation based on the products that brought the largest profit margins. This was the process that was followed by Intel. Initially DRAMs were the ones that earned the maximum profit, but over a period of time the profit margins of DRAMs dropped due to competition from the Japanes manufacturers. Slowly the managers started allocating more resources to microprocessors. This was despite the fact that Senior management never mandated this and were in fact investing two thirds of the R & D dollars into DRAM business. It was only when crisis the company that the senior management realized their mistake and formally changed their strategy and evolved as a microprocessor company.
The advice that the authors have with respect to strategy is that while it is important to have a strategy for a new growth business, it is important this should not be too rigid. It should be flexible and should flex based on the feedback and the market reaction. The authors quote Mintzberg and Waters “Openness to emergent strategy enables management to act before everything is fully understood – to respond to an evolving reality rather than having to focus on a stable fantasy …. Emergent strategy itself implies learning what works – taking one action at a time in a search for a viable pattern or consistency”.
The two reasons why start up fail are; organizations spend money aggressively implementing a deliberate strategy in the nascent stages when the right strategy cannot be known; the second reason is once the strategy becomes known organizations that do not seize deliberate control of resource allocation and focus all investments in executing the race up-market.
To succeed the authors suggest following policies
1. Carefully control the initial cost structure of a new-growth business, because this quickly will determine the values that will drive the critical resource allocation decisions in the business.
2. Actively accelerate the process by which a viable strategy emerges by ensuring that business plans are designed to test and confirm critical assumptions using tools such as discovery-driven planning.
3. Personally and repeatedly intervene, business by business, exercising judgement about whether the circumstance is such that the business needs to follow an emergent or deliberate strategy making process. CEOs must not leave the choice about strategy process to policy, habit, or culture.
While the all points apply to an established organization the first two apply to a new startup as well.

Summary

Simply seeking to have the right strategy doesn’t go deep enough. The key is manage the process by which strategy is developed. Strategic initiatives enter the resources allocation process from two sources – deliberate and emergent. In circumstances of sustaining innovation and certain low-end disruptions, the competitive landscape is clear enough that strategy be deliberately conceived and implemented. In the nascent stages of a new-market disruption, however it is almost impossible to get the details of strategy right. Rather than executing a strategy, managers in this circumstance need to implement a process through which a viable strategy can emerge.
There are three points of executive leverage in strategy making. The first is to manage the cost structure, or values of the organization, so that orders of disruptive products from ideal customers, can be prioritized. The second is discovery-driven-planning – a disciplined process that accelerates learning what will and won’t work. The third is to vigilantly ensure that deliberate and emergent strategy process are being followed in the appropriate circumstances for each business in the corporation. This is a challenge that few executives have mastered, and is one of the most important contributors to innovative failure in established companies.

There is Good Money and There is Bad Money

The authors stress in this chapter that neither money from within the organization or from a venture capitalist is good or bad. It is only the circumstances that make the money good or bad. The expectations of the investor plays a big role in determining if the money is good or bad. If the investor drives the new business to grow fast then the money is a bad money. If the investor drives the new business towards early profits then it is good money. Note that profits do not necessarily mean growth and vice-versa.
The authors advice that one should be impatient for profit. This will drive the organization to manage the resources efficiently and hence keep the costs within control. If one is impatient for growth and is patient for profits then one may never hit profits as the resource allocation is unlikely to be optimal given the expected growth. Most large organizations fail to grow a disruptive innovation within themselves because then tend to drive these business towards a fast pace of growth rather than looking at possibly a small but early profit.
The authors describe the steps through which an organization go. This again reflects “The Growth Imperative” outlined in the initial chapter. In the first stage the companies are successful. In the second stage they face Growth Gap which they try to bridge by trying to bring disruptive innovations and put money. In the third stage company starts becoming impatient for growth of this disruptive innovation and now the money that it is putting in becomes bad money for the innovation. In the fourth stage the disruptive innovation experiences losses as it tries to grow without a clear strategy emerging and the executives tolerate losses for some time. In the fifth stage the losses mount and this triggers retrenchment of resources in the disruptive innovation, in effect killing it and a new management is brought in to stop the bleeding.
To succeed the authors suggest to following principles:
1. Launch new growth business regularly even when the core is healthy.
2. Keep dividing the business units so that as the corporation becomes increasingly large, decisions to launch growth ventures continue to be made within organizational units that can be patient for growth because they are small enough to benefit from investing small opportunites.
3. Minimize the use of profit from established business to subsidize losses in new-growth business. Be impatient for profit: There is nothing like a profitability to ensure that a high-potential business can continue to garner the funding it needs, even when corporation’s core business turn sour.

Summary

The experience and wisdom of the men and women who invest in and then oversee the building of a growth business are always important, in every situation. Beyond that, however, the context from which the capital is invested has a powerful influence on whether the start-up capital that they provide is good or bad for growth. Whether they are corporate capitalists or venture capitalists, when their investing context shifts to one that demands that their ventures become very big very fast, the probability that the venture will succeed falls markedly. And when capitalists of either sort follow sound theory – whether consciously or by intuition or happenstance – they are much more likely to succeed.
The central message of this chapter for those who invest and receive investment can be summed up in a single aphorism: Be patient for growth, not for profit. Because of the perverse dynamics of the death spiral from inadequate growth, achieving growth requires an almost Zen like ability to pursue growth when it is not necessary. The key to finding disruptive footholds is to connect with a job in what initially will be small, nonobvious market segments – ideally, market segments characterized by nonconsumption.
Pressure for early profit keeps investors willing to invest the cash needed to fuel the growth in a venture’s asset base. Demanding early profitability is not only good discipline, it is critical to continued success. It ensures that you have truly connected with a job in markets that potential competitors are happy to ignore. As you seek out the early sustaining innovations that realize your growth potential, staying profitable requires that you stay connected with that job. This profitability ensures that you will maintain the support and enthusiasm of the senior management who have staked their reputation, and the employees who have staked their careers, on your success. There is no substitute. Ventures that are allowed to defer profitability never get there.

Role of Senior Executives in Leading New Growth

The authors state that the key role that Senior executives should play is to help the new business grow. They need to clear any processes or resource impediments standing in the way of the teams trying to grow a disruptive innovation. They should be shielded from the revenue demands of the market. The senior executives should also be responsible for ensuring that emerging good practices in the disruptive innovation is being applied to the rest of the organization.
One point that the authors highlight is that in most organization senior management gets involved only when maqnitude of money at stake is beyond a particular level. It is believed that below this level the lower-level managers can take a decision. The authors state that in most organizations the senior management get answers for the questions that they ask. and sometimes senior management does not know what questiosn need to be asked. Senior people in organizations cannot know much beyond what the managers below them choose to divulge. Worse, when the midlevel managers have been through a few senior management decision cycles, they learn what the numbers must look like in order for senior management to approve proposals, and they learn what information ought not to be presented to senior management because it might “confuse” them. Hence a good portion of middle manager’s effort is spent winnowing the full amount of information into the particular subset that is required to win senior approval for projects that middle managers already have decided are important. Initiatives that don’t make sense to the middle managers rarely get packaged for the senior people’s consideration. SENIOR EXECUTIVES ENVISION THEMSELVES AS MAKING THE BIG DECISIONS, BUT IN FACT THEY MOST OFTEN DO NOT.
The authors stress that since the senior executives cannot participate when decisions are taken, decision making processes that work well without senior attention are critical to success in circumstances of sustaining innovation. It is important to follow the gospel of “driving decisions down to the lowest level”, and of “making the lowest level competent”.
The authors suggest that the organizations should have “growth engines” embedded in them to be successful in an on going basis. They suggest the following four policies for creation of this growth engine.
1. Start before you need to. Again referring back to the earlier suggestion of not waiting till is really required to grow.
2. Appoint a Senior Manager to shepherd ideas into Appropriate shaping and resource allocation process: This executive should be trained to and empowered to take decisions counter to the current organizational processes when required.
3. Create a team and a Process for shaping ideas: It is important that is a team which will collect the disruptive innovation ideas and run them through the viability process and then if viable help them shape the future of the innovation.
4. Train the troops to identify disruptive ideas: The rank and file of the organization should be trained to watch out for disruptive innovations so that the they can be brought to the notice of the right set of people to be taken forward.

Summary

Senior executives need to play four roles in managing innovation. First, they must actively coordinate action and decisions when no processes exist to do the coordination. Second they must break the grip of established processes when a team is confronted with new tasks that require new patterns of communication, coordination and decision making. Third, when recurrent activities and decisions emerge in an organization, executives must create processes to reliably guide and coordinate the work of employees involved. And fourth, because recurrent cultivation of new disruptive growth business entails the building and maintenance of multiple simultaneous processes and business models within the corporation, senior executives need to stand astride the interface of those organisations – to ensure that useful learning from the new growth business flows back into the mainstream, and to ensure that the right resources, processes, and values are always being applied in the right situation.
When an established company first undertakes the creation of a disruptive growth business, senior executives need to play the first and second roles. Disruption is a new task, and appropriate processes will not exist to handle much of the required coordination and decision making related to the initial projects. Certain of the mainstream organization’s processes need to be pre-empted or broker because they will not facilitate the work that the disruptive team needs to do. To create a growth engine that sustains the corporation’s growth for an extended period, senior executives need to play the third role masterfully, because launching new disruptive businesses need to become a rhythmic, recurrent task. This entails repeated training for the employees involved, so that they can instinctively identify potentially disruptive ideas and shape them into business plans that will lead to success. The fourth task, which is to stand astride the boundary between disruptive and mainstream businesses, actively monitoring the appropriate flow of resources, processes and values from the mainstream business into the new one and back again, is the ongoing essence of managing a perpetually growing corporation.

Passing the Baton

In the last chapter the authors summarize their advice in the following points:
1. Adopt a strategy that will be unappealing to the competitor so that you have a smooth sailing. It should not be attractive enough for the competitor to copy.
2. Address nonconsumption rather than trying to improve something for the existing consumers.
3. If nonconsumptions is not an options try and find overserved customers.
4. Try and find out a way to help the customer do something that she is currently doing more conveniently and inexpensively.
5. Instead of segmenting the based on available data, try and figure out what the customers are trying to achieve and try and help them address that in a simple way.
6. Do not assume that the competition is always going to be the same.
7. Do not pursue modularization prematurely.
8. Do not swayed by an idea because it gels with the “core competency” of the organization. It is important to have resources that can help succeed. The processes that we have should not be an impediment to the development of the new idea. And our existing values should not hamper the development of the new idea.
9. Same questions must be asked about the venture’s channels as well. If the channel company’s processes, values and their methods and motivations do not gel it can cause the venture to fail.
10. Do not blindly trust the managers that you have trusted in the past. Consider the learning that the manager has been through before deciding who will lead the new venture.
11. Be sure that in the beginning years after a venture is launched, the development team remains convinced that they aren’t sure what the best strategy is, in terms of products, customers, and applications. Insist that the team give you a plan to accelerate the emergence of a viable strategy. Call a halt to decisive plans to implement any strategy before there is evidence that it works.
12. Be impatient for profit and patient for growth.
13. Keep the company growing so that you can be patient for growth. Disruption – and competing against nonconsumption in particular – requires a longer runway before a steep ascent is possible.

Summarized from http://ptgmedia.pearsoncmg.com/images/9780137081073/samplepages/0137081073.pdf

The code written should satisfy the following criteria:
1. The code must work consistently and satisfy the requirement of the client
2. The code must solve the problem set for by the customer. Many times customer’s requirements do not solve the customer’s problem. It is upto the programmer to negotiate with the customer and ensure that the problem is solved.
3. The code must fit into the existing system without destabilizing or making it fragile or opaque.
4. The code must be readable by other programmers.

Preparedness
The author says “Coding is an intellectually challenging and exhausting activity.”. So one should be in a state of preparedness before writing the code. Some suggestions that the author provide are as below:
1. Do not write code at 3AM especially after having already worked for 18 hours and having put in 60 – 70 hour week.
2. Do not write when some personal matter is bothering you. Try and resolve that matter before coding.

The Flow Zone
Some programmers feel that they get into a hyper productive zone known as the “flow”. They do not stop programming as long as they feel they are in this state. The author suggests that it is not a very good state to be in for long. This zone is not infallible and not necessarily productive. Step away from this state and write code when you are more under control.
Listening to music while coding may actually be a distraction, depending on your disposition. The author found himself writing lyrics from the songs he was listening to when coding in the code comments.
Be prepared for interruptions when coding. It is important to attend to the needs of the others too. Keep a time period when you do not wish to be disturbed, while at the same time providing time for others to disturb you. Author also suggests getting into pair programming so that one of the pair can maintain the thread while the other answers to the interruption.

Writer’s Block
There will be times when one will just not be able to code. The author suggests adopting pair programming strategy will help melt the block.
Do things that brings the creativity in you. This will depend from person to person.

Debugging
Write code such that you do not have to debug the program. This is the best form of coding. The author suggests adopting Test Driven Development will help reducing the time spent in debugging.

Pacing YourselfThe author suggests that coding is not a 100 metre dash, but a marathon and so it is important to pace oneself. One needs to ensure that one needs to conserve ones energy so that one does not end up hurting oneself.
The author says “Can’t go home till you solve this problem? Oh yes you can, and you probably should! Creativity and intelligence are fleeting states of mind. When you are tired, they go away. If you then pound your nonfunctioning brain for hour after late-night hour trying to solve a problem, you’ll simply make yourself more tired and reduce the chance that the shower, or the car, will help you solve the problem”

Being LateThe author says it is difficult to avoid being late. He suggests that what is bad is to keep the stakeholders in the dark about the delay. The earlier they are briefed about the delay, the better they will be able to be prepared for the final outcome.
The author suggests do not give hope that the thing would be finished when it is known that it will not be. Do not hesitate to say “No it cannot be done”. There is no point in saying “I will try” and give the stakeholder a feeling of safety which you are not confident about. Do not say “I will try” unless the stakeholder has a backup plan.
What if your manager sits you down and asks you to try to make the deadline? What if your manager insists that you “do what it takes”? Hold to your estimates! Your original estimates are more accurate than any changes you make while your boss is confronting you. Tell your boss that you’ve already considered the options (because you have) and that the only way to improve the schedule is to reduce scope. Do not be tempted to rush. If you try to rush you will end up taking shortcuts which will lead you to a destination other than where you wish to be.
Avoid overtime. Overtime for a short time may be OK. But continuous overtime does not help anybody. It is as bad as a rush job.
Do not say something is done before it is actually done. Define “done” when you say “done”.

Help
Do not hesitate to ask for help. Do not hesitate go give help. Do not hesitate to accept help.
Mentor: Mentor the juniors so that they become better programmers.

The book is about how to be a “Software Professional” and not just an “engineer”.

Here are some excerpts that appealed to me from the book Sita – Ramayana by Devdutt Pattanaik.

Yagnavalkya’s statements in Janaka’s court based on his learning from Surya

The fear of death makes plants seek nourishment and grow towards sunlight and water. Fear of death is what makes animals run towards pastures and prey. At the same time, yearning for life makes animals hide and run from predators. But human fear is unique: fuelled by imagination it seeks value and meaning. “Do I matter? What makes me matter?” Every human creats his own imagined version of the world, and of himself. Every human is therefore Brahma, creator of his own aham. Aham Brahmasi, I am Brahma. Tat tvam asi, so are you. We knot our imagination with fear to create aham. Tapasya and yagna are two tools that can helps us unknot the mind, outgrow fear and discover atma, our true self.
Atma is the brahman, a fully expanded mind, Atma is the mind that does not fear death or yearn for life. It does not seek validation, It witnesses the world as it is. Atma is ishwar, also known as Shiva, who performs tapasya, is self-contained and self-sufficient. Atma is bhagwan, also known as Vishnu, who conducts a yagna to nourish everyone even though he needs no nourishment.
The traditional Advaita interpretation of Aham Brahmasi and Tat Tvam Asi is “I am God and so are you”. This is a completely different interpretation of the same quotation.

Kaushika becomes Vishwamitra

Vasishta refuses to part with Nandini, a cow similar to Kamadhenu, which is capable of feeding any number of people to the king Kaushika. Kaushika tries to take it away by force of his army but fails. He realizes that he has to become a rishi like Vasishta to be able to gain access to Nandini and sets about doing tapasya to gain siddha. During this time a man called Trishanku managed Kaushika’s kingdom. Once Kaushika attained a level of siddha he tries to send Trishanku to heaven as a gift, but Trishanku is pushed out by Indra and Trishanku finds himself hanging between the two worlds. Now Kaushika performs austerities with the aim of toppling Indra, who sends Meneka and Kaushika falls for her and his austerities is broken.
He resumes his austerities, but is disturbed by a king called Harishchandra. When he is about to curse the king and his family, the king offers his entire kingdom as a compensation. Kaushika accepts is but demands a dakshina for liberating him from the karmic obligation of his crime. With nothing to give the king sells himself and his wife and son as salves and gives the money thus collected to Kaushika.
The king is bought by a chandala and is asked to help in burning dead bodies at the crematorium. The queen were bought by a priest who has made them servants in his household. The son dies of a snake bite and the queen brings him to the crematorium. Harishchandra asks for a fee for burning the body. Having nothing to offer the queen offers the clothes on her body. Harishchandra accepts that and cremates his son. In the light of the funeral pyre, Kaushika sees that naked queen and the stoic king, weeping for their son, but neither blaming nor reproaching anybody for their terrible situation. Kaushika asks the king “Wherefrom comes this wisdom that enables you to be at peace even in tragedy?” and Harishchandra answers, “From my guru Vasishta.” Hearing Vasishta’s name engrages Kaushika even more and he goads aman-eating rakshasa to devour Vasishta’s son. The grandson of Vasishta seeks revenge, when Vasishta tells him “Every action has consequences. Why blame the instrument of karma for what is determined by our own past actions? By denying Kaushika the Kamadhenu because he did not deserve it, I ignited rage in his heart, which led him to goad the man-eating Rakshasa to kill your father. I am as much responsible for your father’s death as are the Rakshasa and Kaushika. I wish I had more sons that Kaushika could kill until he has his fill of anger”.
Hearing this, Kaushika realized that it is not siddha that makes a man a rishi, it is the ability to care for others. To care for others, we have to first see them, understand them truly.
Kaushika realizes that the purpose of yagna and tapasya is not to increase the wealth and power. It is to make one unknot one’s mind, move from aham to atma, see the world from another’s point of view. Only then can one be a Rishi.
With this realization Kaushika stops being a Vishwashatru and becomes a Vishwamitra.

Vasishta to Dasaratha

When Vasishta tells Dasaratha that he will try his best to make the princes brahmins, Dasaratha says that his sons need to be warrior princes and not brahmin. Vasishta explains.
Vasishta: “You confuse brahmin-jati with brahmin-varna. He of brahmin-jati is a priest, transmitter of hymns, rituals of the Veda. He of brahmin-varna is one who inspires the Brahma of limited mind to move towards being brahmin of limitless mind. Whether priest of warrior, farmer, herder or trader, man or woman, everyone must expand their minds, rise from the shurdra-varna, the mindset of a follower, to vaishya varna, the mindset of a trader, to kshatriya varna, the mindset of a master, to brahmin-varna, the mindset of seer.”
Dasaratha: “How can a king be a servant or a trader or a master or a seer?”
Vasishta: “A king is a servant when he mimics other kings without understanding. A king is a trader when he uses rules to get all the things that he desires. A king is a master when he uses rules to impose his thoughts on those around him. A king is a seer when he understand the thought behind the rules and so appreciates the many reason why a rule is followed and why another rule is not. For a king with a mind of a brahmin, rules are merely functional, they are never right or wrong, and like all actions they have consequences. For them rules are not tools fof power to dominate and control. For him rules are merely instruments of society that enable even the weakest to have what is otherwise cornered by the strongest.”

Vasishta to Rama

Conduct your yagna as only a tapasvi can. Ignite the fire, tapa, which needs no fuel, within your mind. Light the outer physical fire, agni, which demands fuel. Tapa will transform you while agni will tranform the world around you. Tapasya will burn your hunger. Yagna will feed the hungry. Tapasya will reveal fear that generates aham. Yagna will hep you discover love that reveals atma. Tapasya works on self so that we can focus on others. Yahna focuses on others so that we can work on the self. Tapasya helps you impose rules. He who understands this walks the path of Vishnu.

Rama is asked if theoretical knowledge or practical knowledge is more important

Rama replies “Neither is better or worse. The pursuit of theoretical knowledge develops the mind, while practical knowledge develops the body. Both have value and both come at a cost. It is aham that creates notion of better or worse. Atma observes it all, and smiles.

Categories