Rating software teams

It's getting to be "that" time of the year again -- annual appraisal season. Organizations agonize over the best way to appraise software teams, with terms like "scientific", "objective", "measurable", "bell-curve" and "quantitative" resonating everywhere.

Here's what *I* would do. I would measure software teams based on their ability to keep the customer happy. In other words I would look at timeliness and quality of delivery. The *entire* team (managers, analysts, developers, testers and others) would be responsible for and rated on those two metrics.

This would lead to multiple outcomes, some of which are:

1. In order to deliver software on time, the team would make a conscious investment in automation builds, deploys and scripts.
2. In order to deliver quality software, the team would make a conscious investment in testing (necessarily automation if 1 also needs to be satisfied)
3. In order to deliver quality software on time, development standards would be followed like religion.
4. Last, but the MOST important, the team would go out of its way to identify and eliminate deadwood, irrespective of "role".

A lean, mean fighting machine software team :-). Of course, this would work for a *small* organization, not a mid-sized, getting to be large organization.

Improve QoS (Quality of... Sleep)

This post is all about how I improved my Quality of ... Sleep!

One simple change. About 45 minutes to an hour before I sleep, I turn off the laptop/computer, no TV and no cellphone chats either. Nothing that can work to stimulate my brain cells. Instead, that time is spent quietly -- reading, listening to music, practicing music, ironing clothes,winding up the kitchen, or any other non-stimulant activity.

I now sleep the same hours, get up at the same time, work at the same job, do the *same* amount of work that I did earlier. I just feel *much* more fresh all day!

I don't shop at Spencers, Food World, More/Smart

At various points in the recent past, I've had "interesting" experiences at retail chain stores.

1. I walked in to do my regular groceries at More/Smart. I went to the refrigerated section and hunted high and low for butter. No luck. I called one of the support staff to ask if they had any. The reply was, "Sorry madam, out of stock". Out of stock? Essentials -- at a grocery store?
2. I wanted to buy non-toxic Holi colours for my son. The day before Holi. Not too early, right? I saw a colourful "Holi Hai" sign at Spencer's "Hyper" and (erroneously) interpreted it as a sign that they would sell colours. I walked in and asked the support staff for colours. They sniggered at me and said, "Holi powders madam? No, no". So I asked to speak with the manager and find out why they put up a Holi poster and not carry Holi basics. The manager's reply was "Madam, we put the poster to wish people, we WILL get Holi powder stock later." When? After Holi?
3. I checked the Food World next door for Holi colours and got the same answer. "No madam".
4. At the same Spencer's "Hyper" mentioned above, sugar was on "discount". Rs 215 if you bought a 5 kg pack, down from Rs 245. That worked out to Rs 43 *per* kg, if you bought 5 kgs. *1* kg of sugar at MK Ahmed was Rs 39 on the *same* day. I know this is what people call a "free market" but somehow the words "stop, thief" keep ringing in my ears.
5. Another time, shopping at Food World, I found myself in a checkout queue, that had more than 5 people in front of me and growing.Why? There was *only* one checkout counter open of the four that they had. Obviously no one in the store was particularly concerned about customer experience. Maybe they thought that shopping at Food World was such a charm that I wouldn't want to leave the store in a hurry.
6. Billing errors. Typically this happens when price of an item rises and the store has both old AND new stock of the same. They update the price in their system so that irrespective of what whether you pick old or new stock you get billed at the new higher price. The way to stop yourself from overpaying is to keep checking prices as your items are being billed and point out errors, which will then be manually corrected. For the customers who don't notice, no prize for guessing who pockets the extra money. For some reason it makes me hear voices -- voices that say "stop, thief".

Ok, so ... do I shop at all? ;-)? I shop either at MK Ahmed, or MK Retail, both of which are local stores of Bangalore. These folks *know* how to run a grocery store such that:

• They never run out of essentials. I mean *never*. And for all of you stores mentioned above, it's not rocket science -- just inventory management.
• They don't treat customers like fools -- selling discounted sugar at Rs 43 if you buy 5 kgs. You can buy a kg for Rs 39.
• They stock Holi colours so you *can* get them the day before Holi (non-toxic ones from Pidilite,  organic ones from another company *and* local ones as well)
• They *always* have enough checkout counters open so that even on the busiest shopping day, you have a short wait.
• There are no billing errors. I've seen the way they handle price differences. For the same item, if they have stocks at different prices, their systems show up all the price ranges available, and they quickly choose the correct one.

 This blog post is my good deed for the day :-)

I *still* read Malcolm Gladwell's work

I became a fan of Malcolm Gladwell's work after I read Tipping Point. I couldn't wait to lay my hands on Blink -- which I enjoyed although I didn't think it had enough continuity to justify being more than an accidental book. Outliers was a good read until I found out that MG hadn't spoken to *anyone* with *any* real flying experience before expounding his theory of why Korean planes crashed more often than American ones.

So why did I still pick up What The Dog Saw?

Do I believe that MG is a great writer who comes up with path-breaking hypotheses that connect seemingly unrelated dots? No. He isn't a great writer; I find him verbose and eager to describe things orthogonal to the topic at hand -- color of lipstick, size of room, nature of blinds, and other trivia. I find the "connections" that he makes tenous at best and the theories that he expounds weak and in-effectual.

So, why am I not putting down his work? I got my answer when I started reading What The Dog Saw.

I read MG's work because it puts together information that would otherwise be completely out of my orbit. To the extent that I would never expend energy trying to dig it up. The history of hair-colour in America, for instance. Does it impact my life? No. Do I agree with the conclusions MG draws? No. Did I get to know some fact that I did not know earlier? Yes. Did I enjoy reading it? Kind-of.

To sum up, for me MG's work is a collection of easy-to-read trivia, with maybe one or two facts that I save for future reference. Wikipedia-lite may be a good description for the way I treat his work ;-).

Blogging reminds me of school

I remember a dreaded task in school language examinations -- reading a "comprehension" passage and then being asked to write a "title" that appropriately summed it up.

Well, each time a write a blog post, I am *very* verbose, right till the point I need to hit "Publish". I don't like publishing untitled work and finding the right title is sometimes hard. Each time I struggle to title my work, I am taken back to the examination hall and I still remember my thought process -- why should *I* have to write a title, why couldn't the author title his own work?

*I* am the author now ... :-)

Startups need a senior "voice of testing"

The lead visual designer of Google quit recently. He made an interesting point:

"When I joined Google as its first visual designer, the company was already seven years old. Seven years is a long time to run a company without a classically trained designer. Google had plenty of designers on staff then, but most of them had backgrounds in CS or HCI. And none of them were in high-up, respected leadership positions. Without a person at (or near) the helm who thoroughly understands the principles and elements of Design, a company eventually runs out of reasons for design decisions." "When I joined, I thought there was potential to help the company change course in its design direction. But I learned that Google had set its course long before I arrived."

This logic is sound and can be carried forward with ease to my current field of work -- software testing. 

The mistake I see startups (in India) make is to begin work without *any* voice of testing at all, i.e., no one is entrusted the task of understanding and being the custodian of the "principles and elements" of  testing.

Somewhere along the way the startup realizes there are "quality issues" and hires a junior tester, usually a "fresher" who helps discover the most obvious glaring-in-your-face errors. The founders are pleased, and as time goes by, "augment" the test team with more resources of the same profile.

Unfortunately, although the most obvious bugs are found (fixed, and then *usually* manually re-tested), this model begins to break down after a while for a number of reasons (in random order):

1. It is not scalable (manual testing never is in a startup not dedicated to providing testing "services"). Bugs are found, fixed, manually verified and then creep back in ever so often.
2. No one mentors testers to look beyond finding the most obvious bugs and open their horizons to varied testing that a robust application necessarily needs.
3. Junior testers are usually too inexperienced to help clarify product workflows and find long-chain faults/failures. This leads to seemingly random errors being reported by customers which are are very hard to replicate in-house.
4. Often junior testers are unable to voice concerns about the extent of testing required and get pressured into doing a hurried one-hour-before-release smoke testing. Needless to say this leads to problems in the field.
5. Specialized testing such as performance testing and security testing (to name just two) get completely left out; only "functional" testing gets done with this model.
6. The "negative" aspects of testing get ignored. Testing gets reduced to a validation activity -- verify that the system works as stated, rather than look for ways to break it.
7. It is hard for junior testers to voice their opinion on usability -- they are either too raw to spot usability issues or get shot down quickly owing to their position in the pecking order. When the voice of usability is missing, software starts to calcify in ways that disallows usability from being injected later.
8. Building testable systems requires time, skill, effort, and most importantly, a champion. Since there is no custodian -- testability, building the system so that it can be tested with ease, gets completely ignored.

After some time, the startup realizes that "something" is missing, and hires a "senior" "quality" person. This is usually the second mistake -- getting a QA Manager who is a process/quality/ISO/CMMi Manager.

The QA Manager comes in, looks around and deems that problems exist due to "lack of process". He (I will NOT use "she" here :-P) starts to point out the benefits of "say-what-you-do", "do-what-you-say-you-do", and begins to put in place a process/quality/metrics regime, the bedrock of which is usually the infamous timesheet. Testers are made to report to this person, and are "scientifically" appraised using metrics such as "number of valid bugs raised". You can see where *that* will lead, don't you?

The testers *still* don't get mentored (except perhaps in the fine art of corporate politicking), and performance testing, security testing, etc. *still* don't happen. We didn't say we would do those and we didn't -- 100% process compliance ;-).

Bleak. So, can something be done? Here's what I have seen works.

Get a software professional who has worked in the field of software "developing", "defining" and "managing" software projects and get her to don the Testing Hat. Right from the beginning.

Wearing her Testing Hat, she will quickly figure out that manual testing is "a crime against humanity" (Martin Fowler). The minute a testing team begins to regard test automation as non-negotiable, doors open for performance, security and other kinds of testing that *cannot* be done manually. This person will also figure that paid software testing tools do not offer significant value-for-money, and introduce open-source tools within the testing organization (thus saving you a lot in license costs ;-)).

The experience that this person brings, having built and used software in the past, will be handy when taking design decisions that impact usability.

THEN hire the fresh graduates and have her mentor them. The way such a person mentors is by initially working WITH them. So she *has* to be able to do EVERYTHING from writing test scenarios to manually testing to creating test automation. Oh, and manage the team -- ranging from work allocation to perception issues that tend to regard testers as lesser mortals.

Over time, the team will get savvy enough to put in place automated builds, deploys, regression and all the other good stuff that help prop error-free software.

Such people *do* exist. Trust me :-) :-).

Duh!

So I was in an accident today. A car *suddenly* stopped on a high speed road. No brake lights, no hazards, no warning. I slammed my brakes, but couldn't avoid the right side of my car hitting against its bumper. That car was a Taverra and escaped unhurt, but my poor car broke a light, apart from some denting on one side.

Turns out there was a lorry in front of the Taverra and it dropped a huge package in the middle of the road, right in front of the Taverra, causing the driver to come to a dead stop, causing me to ...

Well, so who should turn up but the friendly neighborhood cops, who assured me that as per the police manual it was all *my* fault since I was the one right at the back. I asked whether the police manual had anything about lorries being allowed to drop *huge* parcels (3 ft * 3 ft * 3ft) in the middle of high speed roads. Their interest levels in the rules of the police manual suddenly plummeted, and their reaction actually left me speechless. Honestly. They chased down the lorry, got hold of the driver and made him stand in front of me. Now, madam, they told me -- here he is. What do you want to do?

Duh? What do *I* want to do? Why would *I* want to do anything to the lorry driver? Wasn't it *their* job to figure out what happened, file paperwork accordingly and enable all to claim insurance as required?

Maybe they thought -- oh here's a woman, she will surely be stupid enough to get scared and then we can "help" her (at a price no doubt) to end the matter?