Monday, 29 November 2010

Is your code demanding Euthanasia?

Been a while on the blog... I am spending some of my time reviewing the styles and mistakes developers do while coding. The blog post was awaited, but the only reason I write it over today is the movie I saw 2 weeks ago. The topic revolved around Euthanasia - Mercy Killing . No I don't advocate it nor I have any reason to promote it. The only reason I write the blog post is the reason defined above... During my review of the code and coding standards and general mistakes programmers do while writing the code, i found places (bunch of them) where thoughts limited to today and tomorrow are aligned. This unfortunately is true for some really popular open source frameworks too. With all this in action I am forced to say that their code sooner or later would demand a Euthanasia...Though I want to say that every single line of code needs to evolve... there is a huge difference between refactoring and re-writing.

Many of the products undergo re-writes, many of them between 2-5 years of the first line written... I remember of one that happened 3 years ago[I don't want to discuss it in this forum]. When these products undergo the process, they are simply killed, there is no scope of donations of working organs too. When you speak to people whose code may be on a verge of death, they may well stand to defend it, there will be several excuses and arguments but the reality is... in the fast paced product development we are building a baby who years down is going to ask for Euthanasia. So what really determines your code needs that? What makes you realize it is moving towards that? How to stop it? How not to add to its troubles?

So many questions... here are a few of my cents, for the coders, product owners, stake holders, technologists

Your code will demand Euthanasia if :

1. You are writing your code for today or a feature limited to today.
2. You are a coder and you only see the SRS document and nothing beyond..
3. If you do not follow coding standards, just so you can deliver in time..
4. You are not re-visiting some legacy code in pieces once every few weeks or months at the least.
5. You believe in quick development and no code reviews
6. You only talk about code quality, but when it comes to writing it... you are arguing about the if's and then's...
7. You think

Email.from = "";

is what you think a good way of writing code.
8. The elements of your program are requirement document and hard work only.
9. You have not evolved it more than once over a period of time. Be it days, months, weeks, years.
10. You think scalability is only adding servers, robustness is writing interfaces doing same things, re-usability is copy and paste.

Many many more , small but such things... lead your code to Euthanasia.. today or tomorrow.

So what should you do to help your code?

1. When you write it, make sure you see the future of it and past of it
2. Make sure you review it yourself, and then get it reviewed by at least one another eye
3. Make sure you create robustness by checking boundaries
4. Make sure you evolve, refactor
5. Make sure you sandwich it in multiple test scenarios and unit tests.
6. Make sure you document it, so when some one discovers your dinosaur age code, he wont run away from your company.
7. Make sure you have applied the best possible standards.
8. Make sure you own it. Re-visit it some times just to see if you can improvise it, even if it is not most required.

Well We all are responsible to save our code from asking for a Mercy killing... our hard earned credits to best performing features deserve a long lasting code too...

Monday, 15 November 2010

Hire - Only if you find the fire

Hiring is always a challenge, You never are sure if you have found the right guy or not. This quest of convincing yourself that you did not make a mistake in hiring someone, never ends. never ever ends. Its not just about the technical skills or the ability to deliver in a person that determine whether you have found your right guy... its the attitude...A few weeks ago we have been doing rounds of interview to fill in positions in our teams for some products , believe me this is the toughest part of the life cycle, finding and hiring.

All through these weeks you would see
1. Those glossy resumes - That lack lustre of talent
2. The tremendous talent on paper - That crumbles like dust, the moment you ask a question
3. The terrific blabbering that gets one shortlisted through the HR cycles but the answer you are looking for is lost in those rounds and rounds of talks without meaning

ufffff... so much really. Yes its hard to find the right people... specially when you have to think of building a future with and for them... so then what should we look for in those 2 - 4 hrs of discussions we have with someone who we don't even know? while we know that we are thinking of building foundations of great future with them...

When we go hiring... we look for the following:

Will vs Want
Is the person willing to work on what you work or wanting to work on what you work... makes a tremendous difference... if somebody is just going to take working with you as a job, he may be looking out for a change in next 2 yrs. So then how would one WANT to work with you if he doesn't even know what you do? Leave it to the person, let him find about you, let him explore you... I like those interview's very much where after we are done with our part of discussions the candidate grills us about the product, company, role , challenges , what's and how's...

How much you know v/s How well you know
We had a chat a day before about a candidate not knowing certain frameworks that we use, question arised because one of our team members asked a question "He doesnt know X, Y and Z, so what is he going to do then?" . My belief is that it doesn't matter on how many frameworks or technologies you know... if you know the ones you have been working on very well then you are fit to do a task as long as you can begin with those skills. Eventually I remembered that even our architect's were not aware of certain frameworks that we use, when they joined us...

Want v/s need
Again... a lot of guys want to work on new technologies... it doesn't matter what you want... because every one wants matters on what you have done so far to fulfill that want... that passion determines the fire within you. I hate people who claim that they are switching jobs because there current products / companies do not let them work on new technologies... "If your passion is your own liability, how are you going to be an asset for the team you work?"

Cool v/s Calm , Fire v/s Heat
How cool you are with the attitude, yet how calm you are when it comes to patience? How much fire you have to make something happen is important than how early you start cribbing.

A few of the things that form critical element on our evaluation when we hire... a few more things that we look at are listed here..... HOW TO FIND A RIGHT GUY just in case you want to read through....

But just before you release your offer... take 5 mins, think over , rewind the interview process.... and find if this person has the fire that can help your Team shine... I also think that it makes sense to video record the meeting so you can go back and view the video again and again and find out if the guy you are going to hire is the one with most and best FIRE within.

Sunday, 14 November 2010

Teach you Customer Services rep to help your product succeed

Triiiiiiiiiing Triiiiiiiiiiiiiiiing... "Hello, Good Evening. I am XXXX speaking from YYY, How may I help you?- From the other end

"I am Sameer, and I am calling to enquire about the letter I received from your company about the added bonus for my holiday package, that I have to confirm...
blah blah blah... several questions later.. a simple answer "I am very sorry Sir... we are not informed about this package or bonuses, I will check with my Senior and get back to you in a few days"
I said OK. 3 days later.. I make another call... A different CS rep, but the same answer... the system however shows that I have made a enquiry and am awaiting a reply... today morning I make another desperate call and this time after speaking to 3 levels of CS I am still un-answered... as the CS reps and their seniors are not aware of the product they have launched and the several features around it.... I was a happy customer a few weeks ago, now I am seriously thinking if I am in SAFE HANDS or I am using the RIGHT PRODUCT or not.

Is this the same experience you get when you get in touch with a Customer Service representative? Well maybe yes.. So what's the deal about CS representatives not able to detail features of the product, explain or answer your queries around the feature? The answer is really simple.... While various companies are using SOCIAL MEDIA to improvise the customer services experience for their customers a major set of products and companies still choose to go with the traditional mode of handling customers... The CS still relies on a user manual, a support call, an online help.. many times they are there on the hot line just to SOLVE CUSTOMER problems. But can they solve customer issues if they themselves are not aware of the product?

Well the answer is NO... Your customer services dept needs to know, How to use the product, what it is made for, and provide tips and tricks to the customers when they need it. It's very important that the CS knows the in's and out's of the product and is more or less as close to the development and Product teams as the computers are close to Geeks. So how does one really get their CS to know what's and how's of their product?

1. Discuss requirements with them, pre development phase
2. Involve them in early stage demo's, right when the product are in the design phase, even wire frame phase
3. Have a development stream for the issues they face.. A set of developers that work only on problems that they face as hot calls. These are not bugs.
4. Free them up from regular hot line's, Ask them to explore the product. A weekly session where a product wire is discussed with product Management, CS and Development teams is the ideal way to help explore to correct details.
5. Ask them to write user manuals, online help
6. Ask them to conduct demo's for the customers..
7. Plan 2-3 product demo's for the customers... so as many customers and end users get trained on your product
8. Wire them with super roles, so they can learn to get around.
9. Ask them to write a FAQ of issues and resolutions.. half of the CS time can be saved and knowledge shared if the CS teams shares the data of problems and resolutions.
10. Swirl the CS Teams on project set ups, so they know and document how and what customers use it....

Well these are very few but individual ways of getting your CS Teams to know the best of your product... so the next time they receive a call from an angry customer... he keeps the call, just to open his mailbox and write back to say..."We love your product"...

I thought of putting a few case studies of some successful models, where end users were very happy about the products they use, and I am sure the CS plays a very important role here...

1. Amazon : Amazon has a very aggressive development model, they begin writing a release note. Of course the release notes are not key here, what is key here is that the documents attached with the release notes of the product feature is definitely a part of the CS Training material. So if your CS is writing the user manuals, online help, training material even before the product is ready.. your CS is surely an empowered Product Team.

2. Oracle - Autovue : I have always received emails about webinars conducted by Oracle's Autovue team.. many times these webinars feature very specific training to end users on how to use certain features of the product. I realised in one of the webinars that one of the CS Team members I was dealing with earlier was a part of such webinar.. Amazing isnt it?

So does your CS Team know your product well? Can they also sell Happiness to your customers? Can they convince the customer that they can quickly solve their issues and even if not.. they dont let them go unanswered? Well if the answer to any of your question is NO... You need to work on a strategy to make your CS aware of your product... Go rush, cause you are very late. After all they are the face of your company....

Wednesday, 10 November 2010

Where is your Chief Happiness Officer?

I started my day today answering a phone call from an old time friend, who was pretty unhappy about his current job and was re-locating in search of a great new job to another city. I was forced to think about the general unhappiness that gets created in the day to day cycle at any organization... some people unhappy about work, some about roles, some about compensations, some about environments, some about everything and some about nothing... with me recently having the performance appraisal reviews with most of the Team members, I understand how for certain member a small piece of unpleasantness leads to unhappiness...Then it forced me to review my role into the Team and company.... I see that every company has

CEO - To Manage the Executive actions
CFO - to Manage the Finance piece
CTO - To Manage the Technology piece
COO - To Manage the Operations piece...

Why do organizations not have the CHO? The Chief Happiness Officer? The Executive who can make strategic decisions to keep the employees Happy... Yes.. a role strong enough to do things that would work towards improvising the behaviours, attitudes and help support the employees be Happy... Some argued that the Human Resources should take of this... I strongly disagree.... Human Resources is purely designed to handle recruitment, resource policies etc a few of the tasks that Human resources do, keep them so busy with these tasks that issues related to people and their happiness is not even close to get attended... Smaller companies can afford to have their Sr. Managers take care of Happiness and HR things... but for bigger organizations... a must have is a role that will strive to create Happiness against all odds in the Team.

So then what is this role going to do? Lets define the responsibilities of the Chief Happiness Officer :

1. Responsible to ensure Team delight.
2. Should be organizing a chart and a plan for Team events, including Lunches and Dinners and Parties and outings and workshops
3. Should ensure work place and work culture is kept pleasant
4. co-ordinate effort to organize cross location and Team integrations
5. Primary responsibility is to bring smile on faces in the company
6. Organize sessions for Team building and delight spreads...

Want to add more? Now do you find anyone in your Team who does that? Well you dont need to Hire a new person right away for this.... but if you want to work the way great companies work... its important that you keep your people Happy..... and compensation, benefits, perks and goodies are not the only way to keep people Happy.... Go make one of your team members who is passionate about spreading happiness.. and make him your CHIEF HAPPINESS OFFICER... if you dont have one.... BE ONE

Monday, 8 November 2010

Build to the end and decide when to Release....

Attended the iDilute meeting last weekend, a meeting with some 6-7 odd highly energetic and intellignet brainstormers... One of the topic of discussion was around the success of various startups and products in todays competitive markets. While brainstorming products , methodologies , product management and development teams.. we discussed the best approaches that work for each of them. One of them i couldnt just stop myself from wiring over here... A topic that gets you in the war zones... How to decide your release dates...

Release dates Huh?, I believe a very instrumental element in the success of Product Management and ofcourse development teams.. So how do most of the products or companies define what they are releasing and when? Simple... They analyse the market, they find the feature that their customers like / need / want , They define the spec, they estimate , they plan a release date, they create a WBS , they scope and descope the features and wants and must haves, they start working on it and on the scheduled release date they release it[Most times this is a changed date]. In the middle a lot of things change... sometimes requirements, some times markets, sometimes products and sometimes visionaries... most of the time its time that changes, its customers demands that changes... a major killer in this approach is that the expectation changes... I realise when we started working in August '09 on the product we launched this year.. the expectation was to have a JUST new UI, when it reached towards its mid-phase the expectation changed to a MOST POWERFUL UI, when the delivery date neared the expectation was we are building THE MIRACLE PRODUCT. In the end satisfaction when compared with expectations is always 1: 1 milion , and you know which way it goes.... So then how do companies like Facebook work? How do they keep up to the expectations of their customers? How do they bring great features consistently and effectively... This meeting enlightened me of a smarter way they work... One of the attendees who also happens to be an ex-employee of #FB explained the approach of "Build to the end and release" i.e. Work on your product/module till it has neared the completion and then decide when to release it.

Smart, isnt it? pull a roadmap, punch an estimate for every feature [As a project] start working with the plan, be as much agile as you can, define requirements , evolve and once it is ready.. go ahead and say it is going to be ready in XXX days... then let the product team plan the communication and the release date.. Well so much of headache's it avoids for strong , disciplined agile teams...where features are built by what they are meant to do and not by how much we can fit in to the neck of development time available... The quorum debated over this, almost half of the attendees been the traditional managers for whom the only way to complete the thing was to plan it to th end... yet.. I found some real good points in this approach...

1. We all know that our poject costs overshoot the budgets - If you tell me you have always managed within budgets, I have to say you are lying.
2. We all know requirements change - Even if your spec writer is your own customer who wants what he writes.
3. We all know that we like to change and tweak , sometime reform what we built - Even if we say that there exists a CR procedure
4. We all know that we change scope, time or cost to achieve what we planned - Even if we say we did it right.
5. We all know that there are a bunch of angry , unhappy customers sitting there - Even if we write testimonials on our websites.
6. We all know we are atleast 10 years late - Even if we claim we are the first to reach there

When we know we do all of this...then isnt build until you done and then fix expectations a better approach? I remember how much i cursed this approach when one of the Product contact we use was not telling us the release date for the third party viewer software we were using for the Version 20 of their release... I wondered how they managed millions of users and hundreds of big clients... only to learn this year, that if you have to give out quality, you have to accept facts of development attitudes.

Now.. back to reality? Will this approach be adapted by smaller companies? By companies who has a shouting customer who will not renew their contract if X thing is not delivered by Y date? Well the decision is not on can this be done... the decision is Do we want quality....

I wish to trigger this some day, maybe not today... tomorrow definitely.

Thanks to the iDilute forum.