On debugging and maintenance

IMO- One of the most challenging skill needed in software engineering is debugging.

Debugging is an art.
And its possible to learn this art and get better at it.
And if done with a right state of mind can be as rewarding as other glamorous roles in software engineering.

What you learn from this indispensable stage of software development pays you back by making you a better better designer or a better coder.
One way of debugging is to fix a bug and move on to another
Another is to fix it and learn from it.Understand Why did this bug happen in the first place.Was it a case of a typical programming mistake ?Was it a bad design ? A problem with the functional design ? A miss by QA ?
Learn for the mistakes done by others (or maybe you) so that you can skip those and do some new mistakes rather than repeat them.


Many programmers - I come across - try to shy away from debugging and would rather write a new applications.
In fact I have also seen some programmers switch jobs because they didn't want to maintain software.
I do understand their emotion and probably find this as a lack-lustre task and perhaps not as mentally rewarding as wring new application.

Having spent last few years maintaining Production code for a mission critical application- I can vouch this to be as challenging task as writing new application and personally I found it very rewarding.

While debugging you are more than often reading and changing code written by others.
More than often its poorly documented or even worse- the documentation has not been kept up to date- making it more confusing
Circumstances are different.
Requirements have also changed possibly
And often you have a have an impatient client breathing down your neck.
and then you could have a complete shut down of the system held ransom to the successful fix of the problem you are working

The greatest programming aid

The greatest programming aid ever made was - comments.

Now don't get me wrong- i don't mean comments used to document the code
Tut- where would the programming world end up with an approach like that
I mean comments to remove the code without removing it at all

Take your pick
Two slashes ?
or open and close with a slash and an asterisk

Need to change a method signature?
No worries !!!
we recommend the two slashes for you
simply write a new signature header right underneath
you can always see for the next few years what the previous signature looked like

Need to rewrite the for-loop and change it to a while?
we recommend the open close comments
you can always refer to the old logic for ages to come.

Need to pay the electricity bill ?
Well why don't u put a reminder note for yourself in the code
You will be conveniently reminded the next time you work on this file
The compiler will never know ;). HA!

// Need to take out the recycle bin this week

What are your design considerations?

What do you like to keep in mind when designing a software ?

I like to remind myself the following - in no particular order though

1) Avoid ripple affect
One of my friend who was implementing a software project for a major Car manufacturer was asked (in all seriousness)-by one of the associate at the site , who was an end user- and not a technical savvy individual :'I don't understand one thing about your application. If I have flat tire- why do I have to remove my windshield ?'

While designing - Ask questions like- What if I were to change the UI to Swing from a web based application- what all components will get affected ?
If i were to change the database from oracle to Informix- would I have to change any JSP ?

2) UI will change frequently
The user interface is bound to change frequently during the life cycle of the product-In fact even before the application is released perhaps.
The changes can be cosmetic like changing color etc or more impacting as changing the navigation sequence
.Such changes always seem trivial to the person requesting it
And should be unless this has not been accounted for during the design phase

3)Don't leave performance for last
Performance should be on the table right from Day One
A good design will keep performance as one of the fundamental aim for the product delivery rather than squeezing it in as a last minute requirement


4)Keep room for changes
In the ideal world there would be short lines in the airport on Christmas eve- and requirement phase would always end neatly before the design hasstarted.

In the imperfect world new or adjusted requirements do show up at unaccepted time or in any case in later versions of the application

Avoid rigidity in the application which would make bringing in these changes a mammoth effort

Planning the unforseen

How do you plan the unforeseen ?

What are the essential ingredients for a good project plan?

- A Strong project manager. Someone with authority who can put his concerns ,demands across to other parties who influence the execution of the plan. A good ship is of no use unless its captained by a strong Captain.I don't mean a smart project manager but someone who carrier weight in the organization to be able to make his voice heard

- Describe the journey . The purpose of a project plan is to describe the journey before it has begun. It should have all the twists and turns ,speed limits on different roads, time needed for refueling , rest period and so on. List them all.
A project plan doesn't have to be politically correct. It has to be factual and bold.
Any project plan which simply paints a rosy picture and doesnt talk about the potholes hasn't probably been thought through completly

-Room for the unknown. No matter how well you plan and forecast the next few months.
There are bound to be surprises. Issues with software on which your software runs. Someone key member may quit or simply fall in love and get married.Sudden change in requirements

Summarized as

"In preparing for battle I have always found that plans are useless, but planning is indispensable."
Dwight D. Eisenhower

Its all about quality

Very often while making a software- we tend to forget the whole purpose behind the effort- that is to deliver a (quality) product.

While its conceptually possible to make a software with zero bugs- its as unlikely as possible that it will have ever happen
A probabilistic uncertainty in fact.

But we can all try...

IMO- this is what is needed

1) Its the quality and not the quantity of testing that matters.
Its not about bombarding the application with zillion tests.Its about intelligently drafting a QA strategy and executing it successfully.

2) The QA team needs to understand the technology and the design
to better explain with an example: Consider a product which uses home grown component library .A bug in the library may cause some features of the application to malfunction. After the defect has been identified and fixed- the QA team cannot test it successfully unless they knew where the problem was and how it was fixed.

3) Think like customers
Know your customers. Think like them. When testing - test not as QA determined to complete the testing- but as customers using the application with only one aim- finish today's task and go home.Th end users are not using the product to blow it apart. They simply want to be able to do what they want to do.