Don’t do that !!!

If I were to summarize my experience in Software development, that I have gathered over the last 10 years or so, it would be more of a collection of “Don’t do that” rather than “Do that”.

In other words, I have learned more from doing things incorrectly rather than doing correctly. Why? I guess simply because the affects of mistakes stick for a longer time than the benefits you get from doing things the right way.

I may not know the best way to get to New york from Boston. But i can tell you what highways to avoid and what the rush hours are…

So today, I want to “confess” three mistakes that I did and the valuable lessons that I learned from them.

1) Don’t stop listening when you tell.

This was very early in my career, I was young and restless. At that time I was working on the authorization module of a Swing based CORBA client. Roughly put, it worked as follows: Users had permission to either read or create or modify information. Our trick was to have a semantics based naming convention for the button variables. Then using reflection, the buttons would get disabled, thus denying access to parts of the application

Sounded simple, but in practice- the implementation was quite a disaster. To start with, having to name their buttons in a certain fashion was just an irritant for all.Then, there was lots of grey area- Is calculate a read only operation or update ? I held meetings, gave presentations, drew on whiteboards, wrote documents- but never got through to the team on how to name the variables correctly !

The final solution we came up with was – I would cross check the variable name of every button that was added to the application. I have no idea what they did – after I left the organization.

I remember, at that time I felt that everyone was too unconcerned about MY problems. But i was missing the whole point.I kept on concentrating on sending my message across ,but was too busy to hear their message that the design was too complicated-  Think of something better !

2) Don’t do what Netscape did.

This was much later in my career. I got bang in the middle of a major refactoring project. It was something like this- Product A was using bunch of components and we realized that if we changed those objects a bit, they could be used by our other products as well . So we started talking to all product teams to understand what they need , so that we could provide APIs which would work for everyone  This was all good.

But then…we decided to write the interfaces from scratch- going as far as breaking even the compilation dependency that Product A had on those components.

I often wake up at night feeling guilty about how we did this . Feels good to get it off my chest !!! A much saner approach would have been to get the new interfaces in places- bit by bit without breaking Product A.

The funny thing is- when my manager asked me- what I would do different on that project if I had to start all over again, I talked about everything including dual monitors but something as basic as this escaped my attention. Sometimes you have to get out of the problem to see things clearer.

3) Whoa ! Did you delegate that ?

At that time, I was responsible for Production operations where we used to service short term projects for fortune 100 customers. One such implementation got pretty ugly. We had one critical defect which we were unable to fix in a timely fashion . Our consultants ended up doing bunch of stuff manually. The customer was displeased. Everyone was anxious and it was one of the longest week of my life.

But everyone was happy to see that project come to an end- one way or other.And yes, we had managed to fix the defect just before the project closed, even though the solution never made it to production, as it was not necessary any more.

But after 6 months or so, I got an email from my manager asking the status on the defect. And from the email chain, I gathered the customer was considering our services again and had asked the account executive for assurance that we wouldn’t run into same issue again and in his words-”we are looking at a possible law suite if we do”.

He has sent the email to our CTO who had sent the email to my manager and he to me. I duly forwarded the email to my colleague who managed the developer directly who had fixed the defect. He then forwarded that to the developer and the QA member who had tested it. Next day the developer and QA replied “All is well. ” My colleague forwarded that email to me. I then forwarded the same to my manger- who I am sure sent it up the food chain.

A week before the project was due to start, I started getting restless. I decided to test it myself ( it was quite simple to test actually). And boom ! there was the Java exception trace staring at me- same as the one that had haunted us that fateful week. I nervously sent that to my friends who then fixed one scenario that we had missed and all was well once again.

Phew ! Delegate you must. But delegation isn’t as simple as forwarding emails.

So these were just three of many mistakes that I have made.I am not afraid of making mistakes but making them again and again – would worry me

Be Sociable, Share!

•