Pushing Energies in the Right

Direction
Satya Dillikar
 Disclaimer

Following observations may not apply to some

of you but everyone can absorb few of them
to help to deliver quality product.
 Minimize defensive code practices.
• Rather than fixing crashes with NULL-checking the
pointer, try to root-cause the actual scenario
where the pointer has become NULL.

• Instead of NULL-check, try to verify why the same

pointer is freed twice.

• Initialize variables always & then use them. This is

very important if the data-struct is not obvious.
For example bitmap has to be initialized properly
before usage otherwise it will Assert.
 Component Boundaries
• Respect component defined boundaries. Do not
modify files if you are not the owner of that
component. Try to involve the component-
owner/team to fix that issue for you.

• Everyone is not necessarily be aware of the

underlying assumptions in other components,
hence seek the owners comments before you
modify them yourselves.
 Unit testing
• If the amount of unit testing to cover all code
paths seems excessive for a particular project
then request for more time.

• It is ok to ask for more time from your

manager rather than compromising on quality
and produce more bugs.
 Post-mortem analysis
• Try to populate ‘show tech’ or any other internal commands to
extract as much info required for doing postmortem analysis of the
bug.

• Our QA is very humble friend. They re-create the bug for us any
number of times and helps developer to use they setups.

• Consider if the same bug shows up in customer setup, we may not

have the luxury to ask for re-pro the defect. We have to fix it just
based on the info provided.

• Don’t put bug in “I” state just to buy time or avoid fixing some “un-
reproducible” defect.
 Track a list of improvements
• Try to evaluate at every stage and track a list of
improvements per your component in a separate file.

• The improvements can be very small like

– “removing dead code”,
– “add comments for every API”,
– “removing unused variables or API” or big like
– change the interaction between components” or
– “modify current complex behavior with more common sense
behavior…”.

• Get the list and make it into project plan for at least next
release.
 Maintenance cost of the product
• Consider “adding any single line of new code is
going to increase the maintenance cost of the
product”.

• Get every bug fix reviewed thoroughly to make

sure that it does increases quality of the code and
not bug count.

• Add sufficient notes in the bug-resolution, so that

we can reference back the history of fix if
required.
 Avoid going round in circles
• Avoid going round in circles with bugs getting punted
between components.

• Have sufficient debug info and evaluation notes to support

your analysis.

• Do not consider punting bugs to other components as a

means to buy time. Ask or call for meeting to resolve the
corner/race conditions.

• Follow practice of “Validating input /output to component

APIs.” to raise syslog message /debug message to help QA to
assign the defect to right component.
 Do things Right the FIRST time itself
• Don’t go with the beliefs like
– “The code snippet was working before…”,
– “I am just cut/pasting the already existing code…”
– “Some component does it that way….”
– “Some code behavior is like that ….”,
– “Let me fix the current bug now … I shall do similar fix or
improve fix (which is required) sometime later as I do not
have time…”
– “Somebody in the meeting said API1 () has to be return
success…”,
– “I did not have that box or card, so did not tested it…”
– “I have not been asked to do so I am not doing it…”
 A hack
• Try to avoid writing code for temporary sake. For example :
– a hack for current release to meet timelines,
– a patch in some component-1 to fix some other component-2
issue because component-2 is complex and don’t want to
disturb its current behavior,
– a fix which works for current customer or QA setup and
developer understand that it will take some long time like
couple of years for QA to change the setup/topology or a new
customer to deploy the code and hence developer don’t want
to fix it thoroughly in the first phase itself).

• Every hack should be reworked in next release to give a

properly design solution.
 Code Reviews
• Don’t take review-comments from your peer
personally. They are only meant to improve
the code-quality.

• Everyone is expert in they own style and

passion.

• Take it is an opportunity to look at the same

thing in different angles.
 Stronger Dev team
• Invest time in Design Phase. Involve all the experts to
validate the FS/DS.

• Try to streamline the opinions. Bring everyone in the

meeting to the same page. So that they can provide
comments/suggestions . Don’t let meetings to end up
as one-2-one discussions between two dominators.

• Development will be stronger than QA when every

suggestion or minor enhancement found in QA/Field
was already brainstormed by developers and properly
documented it’s pro and cons in the past.
 *Quality* QA
• QA is not just Testing. They have all right to enforce quality
practices and procedures.

• Validated against documentation (FS/DS)

– Don’t ask developer “is this an expected behavior or is this a
bug” just raise a defect if you & your team-lead think something
does not makes common sense.
– In the least case let developer to update the docs and close the
defect.

• Verify defects
– Not just the code but also the “Resolution Notes” and its
impact.
 Thanks for Listening
• Thanks for Listening & helping to improve the
quality.

• This is one of the highest energetic teams

which have passion to work. KEEP IT UP.