Thursday, November 24, 2005
1. Believe in yourself, be confident and be hungry to learn. Get involved in your work to widen your horizon.
2. Everyday, do an honest days work. Get connected to the overall vision/goal of the company and follow through with actions. Don't vile away your time...There's lots to do, just go do it.
3. For you to make a significant contribution in any sphere, and also for you to gain something worthwhile from this engagement, you need to spend substantial amount of time in the company. I feel that 2.5 to 3 years is a bare minimum. If you retire from the company, that's great.
4. Trust the company you work in or else quit. Don't hold resentment within yourself towards the management or hold feelings of being cheated or short-changed of opportunities or start indulging in politics like forming them v/s us groups. If such feelings arise, discuss with your manager candidly and sort them out. After that if discomfort still persists, it is better to leave. By continuing, you are creating more harm than good to yourself and to your company.
5. If you must leave, do it with grace and dignity. (If you are leaving for better opportunity, it's perfectly all right. Be forthright about that, rather than hide behind some farce of blaming the company for non-issues just to avoid feeling guilty. I feel that you don't have to feel guilty if you have adhered to points 1 and 2 in spirit.) Complete all unfinished work, discuss with the manager a suitable leaving date so that you don't leave in a lurch (we've had people who come in the middle of a product release and desire to leave that very day with no concern about their commitment to completing the job) and leave behind your contact details in case you are needed in future for some help. Also remember that this globally connected world is getting smaller, with technology enabling easier and wider communication (e.g. this blog to share my thoughts), good as well as bad references can make or break your career.
6. Stay in touch, since you never know when you may need to ask for some help/references from old contacts.
Wish you all the best.
Friday, November 18, 2005
Of course this story has been oft repeated in textbooks with different characters and situations but all point to the same basic thinking of what engineering is all about. Minimum effort = maximum output. Our job as engineers involves
- Continuously improving and simplifying the production system to deliver top quality products with minimum effort, minimum waste and a fast response.
- Present simple & accurate interfaces for the end user to use the product to minimize the learning curve, increase the adoption rate and reduce operator errors.
- Simplify the serviceability of the product to ensure quick turn around for customer support.
Any of the above mentioned items could take years to achieve and 1 or all of them can easily become the source of competitive advantage for the company (in today’s time I think we need all 3 in place to even survive)
I believe that any problem that you face will have multiple alternative solutions and in your process of choosing the solution to be worked on, please put simplicity of the solution on a high score. A simple element has fewer connections, less deviations, is cohesive and is simply easier to produce, use and maintain.
Saturday, October 01, 2005
Traditionally product development plans a release, draws up specifications, developers work on these specifications, build and use the product inhouse continuously (hopefully) before releasing the pruduct after a few months/years.
Most companies trying to reach the elusive version 3 (Version 3 is where the product is deemed to have sufficient maturity to cater to a vast set of users - Maturity shouldnt be confused with stability, reliability, which is a given even in version 1 of the product) of the product (where it starts a snow ball effect and can pick up steam with its capabilities), cant afford the long cycles of product releases.
At Mithi we set up an architecture, build on it with short frequent releases of features required by our direct in touch customers (always trying to get in the feature at version 0.001 and building on that in next releases), while another team creates the next level architecture (to allow for easier development, easier testing, easier addition of features, better integration etc) in parallel. Typically we try to never go beyond 3 months of work for the next nevel architecture (again with the same idea of improving the architecture incrementally).
Whats the flip side of this? There is never any respite for the team...They are always on their toes since releases are continuous and deliveries to customers are continuous. But, yes I think that we all enjoy the noodle soup...
Tuesday, September 13, 2005
The answer to this depends a lot on the type of business or the objectives. E.g. if you look at a specialty medical clinic, a specialty fitness center, etc, these places need full time experts to handle the inflow of business on a one to one basis. To scale, these business will need more experts at the different locations. If the expert leaves, it is possible that he would leave a void n the business. Whereas when we talk of a software product business, do we need experts? The answer is of course YES. These experts provide the domain knowledge, they bring in their experience from other jobs, they can crack through problems quickly and they are extremely useful in providing the breakthrough ideas. This is especially very true for a startup trying to bring out its idea to the market. But be warned, working with experts in a startup company is a double-edged sword. For a startup in version 1 or 2 of its product, it can get very easily carried away by seeing something working in the R&D lab (read a very early 'prototype') and be tempted to offer it as a solution to the early customers (in an effort to gather the mind share of maximum customers quickly). In such a situation, depending on the complexity of the software, you may need the very expert, who 'prototyped' the solution, to go and deploy it at the customer location.
This model may work if you limit this exercise to learning from a few deployments (real life scenarios, with the customer's consent) and feeding it back into the prototype and then towards completion. However this very model can backfire if you do too many of these 'prototype' deployments without 'heat treating' the solution within a controlled environment. For all such live deployments, you run a risk of discovering bugs on the customer server (some of which could be dangerous), you always need the expert to maintain these deployments (God only knows what else he did on the customer's server while he was onsite doing the deployment), and you run the risk of overloading the customer support group with emergencies which could well have been avoided in the first place (customer's expectations are not set right and for the customer this is a finished product).
My advice to startups in this mode is to use experts in the research lab to discover solutions, break it down into small & complete deliverables (you don’t want to put out a very mature solution which may not have been tempered enough by customer feedback), do a thorough in house test of the solution or at least the first deliverable (any product you make should be used in house from day 1 - eat your own dog meat), test in a live situation for a few select customers by interacting with them on a one to one basis (don’t put up these solutions on your marketing material unless they are heat treated) and then incorporating it in your product for replication.
So, YES we need experts to provide answers BUT we need systems and processes to capture their output in the business flow for replication and scale.
Sunday, September 11, 2005
this series but its just that I have been caught up in two back to back product releases which kept me away from my blogger (and mostly on my desk). BTW I am still caught up in these releases, but I am just squeezing this one article in for now...I had a gentle reminder from a few readers about my promise to expand on my previous blog "It's not just about the code".
I have learnt over the years that besides code, there are a lot of considerations (technical and
non-technical) that can affect a project (positively and negatively). We are not just talking about
schedule, but also about the density and quality of a release. Some one wisely said that "a project schedule slips a day at a time right from the time that the project starts (extend that for quality slippage also)".
So what should be done and what should not be done in order to deliver more than required? I am not going to try and structure these thoughts...like in a book...but just let my thoughts flow in any order that it occurs to me. My suggestions/advice about issues (tech and non-tech) come from my experience and learning on the job and in life. Please use discretion while following my tips and if necessary get help from a consultant about the subject. So here goes...
Recently while I was dropping a programmer colleauge of mine after work, he mentioned during our conversation, that he had a pretty unproductive day and was a little depressed since he really couldnt pinpoint the reasons for the same. In my attempt to help him overcome his depression by finding out the root cause of his unproductive day, I reviewed his activities during the day. I found that he was fine with the tech side of the work on that day...clear specs, simple direct issues, also got a checkin done...etc.
From my own experience, I decided to probe about his health and lifestyle habits. I realized that it would be getting personal, but I know that a lot of people in this world are oblivious of their own body and mind condition. They just go from day to day like robots and feed their physical and mental self with "toxins". They live in what I call a state of "unawareness". Many people dont stop to reflect on what they are getting out of life and whether they are putting their health at a risk to "achieve". I have found that even a distant nagging headache, fatigue, pain, simple stomach ailments, not reading good soul stirring stuff, etc can make you perform at sub-standard levels and you may not even realize this.
Sure enough, my friend had consumed a fair amount of fried goodies at the lunch party, followed by a cola, and cake. Also during the day, he had had more his normal share of tea with sugar and milk. Bingo, his body was full of toxins, making him dull, sleepy and probably a little acidic. All said and done, to "consistently" perform at your peak with a razor sharp mind and a fit body to endure the stresses of todays hyper-competitive world (in any field/profession), one of the most important ingredients is to be in good health, eating well, sleeping well and being moderately active. So is this possible in todays pressure cooker world or fitness and health is a phase in life which comes only after we "achieve"...Watch out for my next blog for some answers...
Monday, August 22, 2005
1. Issue entry (incomplete, unclear, wrong specifications leading to the wrong development and therefore the mother of all bugs i.e. useless development. In some cases, after careful analysis, we have observed that the issue is best fixed in a non development area like devliery, or sales commitments etc. No code=no bugs)
2. Issue design (Plan and details of how the issue will be tackled. The seeds for bugs are sown here, if the design is lacking clarity, simplicity, proper integration & is improperly or not reviewed by multiple people for perspectives)
3. Issue development (Bugs are introduced here, due to improper code maps, missing or incomplete dependancy charts, improper reviews, carelessness, etc)
4. QA (Bugs are missed here, due to improperly documented test cases, insufficient automation, etc)
As part of any product development model, it is imperitive to find and fix bugs as early as possible and definitely before it reaches the customer. Its a no brainer (and a mantra in software development books) that we have to move towards a right first time build. Our endevour should be to nip the bug in the first two stages where it is cheapest to fix. So to all developers, I suggest a more concentrated effort to Perform aggressive specs and design reviews with more than one person.
Saturday, July 30, 2005
Last saturday, I happened to get visited by an ex-employee of Mithi who used to be a developer on my team. I was asking him about their development processes, systems and tools since they were serving international fortune X clients with their product. In the course of our discussion I discovered how much 'code' focussed their team was. They didnt have any formal processes to track issues, resolve issues, perform reviews, test case documentation, feed the documentation team, perform releases, automated testing, etc. The whole system was working on 'heroics' with ad hoc processes and arbitrary checkins. The QA team also always started from scratch without any documented test cases & reported issues via email. If an employee left, he left behind a legacy of unmaintainable code. Basically kind of chaotic. Of course they have managed to get some order from the chaos by "systemizing the chaos/arbitrariness".
But it got me thinking. I analysed that their user base is very small (their niche product is sold to a few large corporates where a few users will use the product, totalling maybe 30-40 users), hence they are dealing with a small end user world. Its possible for them to get away with their current way of working and even handle error/bug reports from these customers one-to-one. But when your product starts to reach out to larger number of customers and is used by an even larger number of end users, then the need for a formallised process and system kicks in.
Without a formal issue tracking information system, templates for design/fixing bugs/closing issues, a process for review, a process for documenting test cases for regression, an automated testing system, a source control system, a release engineering team, a formal release process... one is asking for serious trouble in the quality area. Even if the code is perfect, the process and systems around it can break the whole delivery and support of the product. If the inflow of issues from the customers is high, the whole team can get locked into support, letting the future growth of the product languish.
In my future blogs I would like to share with you how we handled rapid growth in customers and users. I will share how we put some of these systems in place, at a very low cost to up our efficiency, consistency and reliability. Putting in systems/processes also reduces dependance on human resources, so the company is better equipped to handle attrition.
BTW, the latest news from my ex-employees company is that their latest release wasnt taken too well by their customers. So much for a systemised chaotic system breaking down.
Monday, July 25, 2005
I feel that very large organizations are primarily process and system driven, to the point that any body (satisfying basic criteria of intelligence, academic qualifications, aptitude) can come in produce almost immediately and be of value. These people basically run the system/process (created by others), part of which is monitoring and reporting to ensure that these guys are doing a good job. The system ensures that they produce. Such organizations can recruit in large numbers, get work done, and it doesn’t affect them too much if there is a regular and heavy turnover. In fact many such organizations have perfected the art of selection, recruitment, induction, and exit. (Infosys recently had 730 people join on a single day…to get so many people through the security itself is evidence of how process driven the organization is.)
Unfortunately for small companies & startups, who have to first struggle to find the right product, strategy and business model before putting corresponding processes/systems in place, they need to find people who will go through this struggle and set the system/processes, which will be ‘run’ during the growth phase by the type of people described in the previous paragraph. In such an environment, a heavy turnover causes slowdown in the companies progress and can push the start of the growth trajectory. For such companies the primary selection criteria could be people with the right attitude & character, having desire to create something of lasting value, risk taking ability, have deep belief and confidence in their own abilities and possess a natural drive. Such people know that even in the worst-case scenario of the company failing, they will be only be better off personally.
I have to admit that such people are rare…No wonder that only 1 out of 100 guys make through our (Mithi’s) selection process. BTW, we took a tough call and let the 9-month guy go.
I've been following the Tour de France closely for several years now and have watched how Lance Armstrong has improved year after year to win the worlds most demanding race 7 times in a row. At age 33 he is peaking as an athlete. One would think that a younger, stronger, energetic and more aggressive athlete would have bettered him. And there were many in the race and several of them even won individual stages (battles) but the war was won by the wholistic athlete. Its the cumulative learning from successes & failures, controlled aggression, sustained exposure to competition, and team work (read trust in others) that are required beyond physical strength, genetic ability, and a deep desire to achieve. Thus it has been observed that athletes peak in their early thirties.