Undersized development team – Are you in one?

Are you in a software development team with less than ten members? Less than five members? Just three, including you?

In a small sized team, priorities and responsibilities may start getting mixed up, where each member can generally take the place of another. This is fine, and there’s an additional condition. Each member must also be extremely well-versed in an area of the team’s responsibilities.

For example, in a team of three, one member (usually the team leader) takes on documentation, business logic and the overall big picture. One member takes on the back end process flow, making sure the backbone of the project is running smoothly. And the last member takes on the front end application design.

Why is this segregation important? Let me contrast this with a larger sized team first. With more people, a task may be assigned to several people, and the collective knowledge of this group is used to solve the task. Any team member can also more or less take on roles and responsibilities of another team member in this smaller group.

As the team size gets smaller, this collective knowledge and role flexibility shrinks. When you’re dealing with a small team, every member counts. Each member has to be an expert in their own circle of responsibility, or the effectiveness of the team suffers. Treating each member in this situation like a plug-and-play component is a disaster waiting to happen.

So how can you help yourself? Learn to say no. Multitasking with other team members’ responsibilities is the fastest way to drain your energy and compromise your own output quality. In the event that you have to take on another person’s tasks (say the person’s on leave), then prioritise. Find the tasks that helps the team most, and then do those, even if they aren’t originally your responsibility. This way, the team moves forward, the project gets closer to completion, and the users are happier with the support.

If you can, get good help. Even one or two more team members can help the overall effectiveness of the team (try these for some hiring arguments). This is different from adding people to projects to make them go faster. What you want the additional members to do is alleviate some of the independent tasks off the existing members. Then slowly spread out tasks more evenly amongst the team members.

Pitfalls of a polymath programmer

I’ve talked about how a polymath programmer can greatly benefit any software development team. So, what’s the number one advantage of being a polymath programmer?

Polymath programmers are skilled at many programming related tasks.

But do you know the number one disadvantage of being a polymath programmer?

Polymath programmers are skilled at many programming related tasks.

The story of that fateful day…

It was a morning like any other. The sky was a soft blue, the morning air crisp with a hint of the Singapore afternoon heat, and I was friggin’ tired from the programming frenzy the night before.

I reached the office, greeting people along the way, and sat down in my office chair. The subtle difference? There’s no one in a 5 metre radius from my seat for the entire morning.

By a fluke of coincidences and emergencies, all the members of my team were not around. I would be the lone contact, the singular representative for matters directed to my team for two whole days. Some of you might think, “Wow! Power! Command!”.

No such thing.

My team was already small in size, so each member begun to take on more specialised areas of the team’s effort. I’m primarily in charge of most web application development, as well as a few complete systems, a few servers, software installation… anyway, I’m in charge of a lot.

What happened? Like a uncanny manifestation of Murphy’s Law, things started falling apart rapidly on my first day alone in the office. Users started to barrage me with requests and queries. Programs started to fail for the most unfathomable reasons.

Being the sole point of contact for my team members, the users who usually bug them, now bug me. They started with the innocently enough “Hi Vincent. I sent an email to so-and-so, but he’s not around. His out-of-office autoresponder email says to look for you. Can you help me?”, which escalated to the “You. Clear data. Now”

For the entire day, I did everything that my other team members would be reasonably expected to do on a normal work day (serendipities, misfortunes and all). This was in addition to what I would do on my normal work day. Programs failed, files weren’t sent, so I debugged C programs and shell scripts. A user asked for web application assistance, so I helped. Some users got new computers four times better (hard disk and RAM) than mine, and they’d be positively unproductive without the software programs developed by my team, so I went to install the programs.

Because I knew enough of my team members’ work, I filled in their shoes and covered for them. It didn’t make it right or wrong. It was just unfortunate. I was plug-and-playable, and that day pushed that quality to the limit.

It was a very tired and dejected man who stepped out of that office in the evening. That man used every ounce of whatever energy’s left to write this post too…

Just because you can do everything, doesn’t mean you should.

Laptops, Meetings, Nostrums

Laptop My department shares just one laptop. Sure we don’t often need to travel and work at the same time. Sure there’s a budgetary constraint. Still, it sucks when my users get new laptops every two or three months, when my work computer is struggling to compile source code.

While I’m not exactly jealous of the ability to work whenever I have to, it sucks when I go to a meeting and everyone’s got a laptop but I’m just carrying notes and scribbling on spare pieces of paper. And I’m supposed to be the IT guy.

That’s in the past. My users still get new laptops every two or three months, but I’m cool with my situation in meetings. Now I have a faint disdain for people typing away when someone’s talking in a meeting. I’ve had experience where I’m conducting a training session and someone’s softly tapping away at the keyboard. I think it’s rude. But I’m at the lower rungs of the corporate food chain in that room, so double suck.

I have witnessed some people actually composing and sending emails, and fleshing out Excel spreadsheets during a meeting, which were not related to the meeting. Go do them at the work desk! I’m sure it’ll be more productive.

Meetings should be used to rapidly whittle down objectives and issues. The faster the whittling, the faster everyone gets to work on whatever was discussed. Problems creep up and might need more time for discussion. Take a note of it and move on. I agree some people function better when taking notes on a laptop than with pens and paper. Those people had better be typing at speeds of at least 60 words per minute, and adept at using their note taking software of choice.

Personally, I prefer pens and paper for taking notes. Since I listen and think through the speaker’s words, I rarely get to write anything. And during lapses, I’ll quickly scribble a few choice thoughts.

Recently, I attended a seminar with Allan Pease as one of the speakers. There was an interesting point he made. Most men can only do one thing at a time. One of the examples Allan gave was that of communication. When a man speaks, he cannot listen. And when a man listens, he cannot speak. A man changing focus away from listening, cannot listen!

So what’s the cure?
I honestly don’t know. Doing a non-meeting-related work task during the meeting might have saved you a few minutes, but if you missed something important, you’re going to waste someone else’s time. The more people in the meeting, the more time wasted.

We can try banning laptop use during meetings, but I’m sure somewhere in the world, someone is having an apoplexy from not being able to multitask writing emails, doing Excel spreadsheets, modifying a Word document and attending a meeting all at the same time.

Tackling problems with indefinite answers

In your programming career, have you ever faced a problem where there’s more than one answer? Or that you don’t even know if there is a right answer? Let me tell you one of mine.

Recently, one of my colleagues came to me for advice on a validation condition he faced. It turned out to be mathematical in nature. Wow! Anyway, in his database he stored number_of_days, month and prorated_fee. The stored data contains records of the results of prorating calculations.

What is prorating? Say a customer was charged a monthly fee for a service, and the customer had just signed up for the monthly service near the end of June. And he had the service for only 5 days, June has 30 days, and the monthly fee is $20. Prorating means he’d be charged 5 / 30 * $20 = $3.33. You will have noticed that prorating often has inexact results because the calculated values are rounded to 2 decimal places.

Back to my colleague’s problem. Suppose that the records from the database looked like this

days  month  prorated
5     30     3.33
8     30     5.33

I’ve translated the month into the number of days in that month for easier visualisation.

The problem was, given those records, could he prove that the prorated fee was calculated from the same monthly fee?

For this example, the monthly fee used was $20, so the results match. What he needed from me was, was there a way to programatically determine if there was a correct original monthly fee?

My initial instinctive answer was no, because all precision of the calculation was lost when the final value was rounded. Then he said, he’s not looking for precision. He just wanted to know if there was a possibility that the records were calculated using the same monthly fee. Aaahhhh, now we’re talking. So I told him to give me some time to work out an equation or something. Then I went to work.

Mathematically formulating the problem, I got:
Given d, m and p, where
d is the number of days in service
m is the number of days of that month in service
p is the calculated prorated value
find f, the original monthly fee, such that abs(fd/m - p) < 0.005

The equation is fd/m = p', where p' is the exact calculated value. Then p' is rounded to p.

The abs(fd/m - p) < 0.005 condition was because of the rounding. The difference between the calculated value and the stored value must be less than 0.005 for the rounding to be correct. And the error margin is 0.005 because 2 decimal place rounding means the value to be rounded is less than half of 0.01.

Rewriting the condition, we get
-0.005 < fd/m - p < 0.005
=> -0.005m < fd - pm < 0.005m
=> -0.005m + pm < fd < 0.005m + pm
=> (p - 0.005)m/d < f < (p + 0.005)m/d [d is always positive, so division is fine]

Substituting our first record's values into the inequality, we get
(3.33 - 0.005)(30)/(5) < f < (3.33 + 0.005)(30)/(5) => 19.95 < f < 20.01 Substituting our second record's values into the inequality, we get (5.33 - 0.005)(30)/(8) < f < (5.33 + 0.005)(30)/(8) => 19.96875 < f < 20.00625 Now if there were more records, we'd continue substituting, and we'll end up with a lot of inequality ranges. So what's the solution to the problem? If there was an f such that it satisfies all the inequalities, then the prorated values could have been calculated from the same monthly fee.

I went back to my colleague and told him that even if the inequalities could be solved, he might still have a range of values that could have contained the original monthly fee. So there's still no exact answer. He said that was fine. He rephrased his objective, that he wanted to know if the records from the database could have been calculated from the same monthly fee within reasonable limits.

Ohhh. Ok. I told him if he could find a range of values of f satisfying the set of inequalities from above, and that there was a value in that range with at most 2 decimal places, then he's done.

Example, a range of (19.956, 20.00) would be valid, because the original value could be 19.96 or 19.97.
But a range of (19.956, 19.959) would be invalid, because there were no values that had at most 2 decimal places. The reason for this was that the original monthly fee was at most 2 decimal places.

So, how do we find that range of values of f satisfying all the inequalities?

Let L be the set of the left hand values of the inequalities. Let R be the set of right hand values of the inequalities. Then there's a range of values of f satisfying the inequalities if and only if the maximum value in L is less than or equal to the minimum value in R. Stated mathematically,

max(L) <= min(R)

I gave him the piece of paper where I scribbled my notes, and he copied some of the important formulae. What about determining the solution programmatically? What, are you kidding? I wracked my brain for a mathematical solution, distilled it into understandable logic steps. How to implement this was up to him... *grin*

Multitasking is a fallacy

Half an hour after arriving at the office, and Jared’s already fixed a nagging bug from yesterday. Feeling happy, he continued typing away at the keyboard. Until a small window slowly popped up with a “You have mail”. He pointedly ignored it… for about 30 seconds because his eyes kept flicking to the bottom right to stare at the innocent email letter icon at the taskbar.

Jared breathed in deeply and sighed, wondering what the interruption was. Oh, it’s Evil Email Ellen. This time, she had trouble logging in to a web site (3rd time this week!) developed by Jared, and asked for help. She’s also emailed her colleagues, her boss and even her boss’s boss. Jared’s surprised she didn’t let the cleaning lady know about it.

Since Ellen gave only an “I cant log in!! Pls advise.” with no screenshots and no error messages, Jared calmly composed an email query asking for more information. As soon as he clicked the Send button, the phone rang.

Picking up the phone to say “Good morning”, Jared began listening attentively to the rational and reasonable requests by Tenacious Tester Tammy. She was done with her current tests and required Jared’s help to reset some data. “Ok, no problem,” said Jared, and put down the phone.

“Uh Jared, can you come over for a sec?”

Othello the Obnoxious Oaf had stood quietly behind Jared, waiting patiently for him to finish the call. Already undergoing a mental meltdown, Jared forced an “Ok”, and followed Othello to his desk.

“I can’t seem to get this to work,” Othello pointed indignantly at the mess of code shown on his monitor. Jared gave the code a quick glance and found the error. As he began contemplating the choices of strangling Othello, patiently explaining the cause and cure for the error, or simply taking over the keyboard and just type in the solution, Jared’s conscience intruded and Jared began pointing out the parts of code to be changed. Halfway through the explanation, Jared heard his phone ring. Finishing with a “follow this example, and copy this chunk over here”, Jared walked quickly back.

“Oh hi Ellen, how can I help you?”
“Hi Jared, I tried logging in just now, and it worked! What did you do?”
“I didn’t do anything.”
“Oh you must have! I really needed that analysis report, and I got in!”
“… Yes, I did fix something… Was that report okay?” Jared sighed, eager to end the conversation.
“Oh yes, thank you!”

Jared breathed in deeply, and was about to go back to his code when he remembered about Tammy’s request. And Othello came back with “Uh Jared, it’s still not working”. The innocent email icon also came back. Jared checked his email. It was Tammy, politely asking for her data reset. Ellen’s there too (Jared’s heart gave a lurch), replying with a “Thank you for your help” (sigh of relief).

Deciding quickly, Jared led Othello back to Othello’s computer, and proceeded to give him explicit instructions on how to solve the error without actually typing the solution for him. Smiling at Othello’s “Thanks Jared!”, Jared turned swiftly and went back to his desk to prepare the data for Tammy.

After executing the final update statement on the database, Jared called Tammy to let her know her data’s ready. The now irritating email icon came back, with the lethal combination of Othello standing innocently close by. Jared glanced wearily at his watch. 11:37 am. This was going to be a long day…

Psychological studies suggest that multitasking undermines human efficiency, that we weren’t made to multitask. Despite anything you hear from managers, friends or job descriptions, multitasking is harmful. Being able to handle several things just means nothing gets done, just “handled”. Joel gave an excellent multitasking debunker example for programmers.

Stop multitasking. Your brain will thank you.

5 simple tips to meet project deadlines

Jared was halfway through developing that unbelievably cool application. The specifications were complete, the customer was pleased with the prototype of his user interface and everyone was doing what they did best. There was just this teensy little problem. Sometime ago, Jared had to go help out that fellow colleague with a programming task. Then there’s the time when his users seemed to conspire against him, and decided to take turns calling him with technical queries throughout the day.

Whatever the reason, Jared made a brief calculation and discovered that he’s starting to run out of time. Then he remembered some tips he read from an incredible web site.

1. Shut down your email
Outlook can be detrimental to your productivity. Having to constantly glance at the bottom right of your monitor to check if a new email came in will sap the focus out of you. Ignore people who call you up and say they’ve sent an email 5 minutes ago, and demands that you explain why you haven’t responded. Try checking once in the morning, once after lunch and one last time an hour before you leave work.

2. Go to the toilet often
It matters little if you have a strong bladder. Just go. Walk slower than usual on the way. Have a good look around the office. Take your time while washing up. Your goal is to get away from the computer, away from the task. Your body gets a little exercise and your mind experiences different sensations. All good impetus for igniting your creativity.

If you really want a good reason to go, just follow the next tip.

3. Drink more water
Your brain is already working at hyperspeed. Your body is aching from holding your special fast and furious typing stance. Drink more water. Eat proper foods. Cooling your brain and taking care of your body is important, because you can think better when you can physically keep up with your mental processes.

4. Wear a scowl
Monarch butterflies advertise their distastefulness with contrasting bright colours. Soldiers deter intruders with barbed wire fences. You can achieve the same effect with people who absolutely must bother you with some insignificant detail. Put on the meanest, angriest and most unforgiving scowl you can muster, and note the dropping number of unwanted guests.

5. Leave on time
This may seem counter-intuitive, but leaving work on time forces you to make the best use of your time while you are in the office. You are a responsible programmer, and so you will make sure that the project is still delivered to the best of your abilities. What you want is maximise your throughput instead of increasing the amount of time spent.

After Jared followed those simple tips, he was able to crank out tons of flawlessly elegant code. And lunch with his colleagues. And leave work on time. And manage to catch up with the latest tech news and blogs of his favourite authors.

As Jared was leaving work on the eve of the project delivery, he saw the unfortunate programmers a few cubicles away, mindlessly and desultorily going about their work, having forgone their lunch and now working overtime. Jared laughed (silently of course, as a form of respect for the others), shook his head and left with jaunty steps.

5 reasons why you need polymath programmers on your team

A polymath is someone who is knowledgeable in a wide variety of subjects or fields. And polymath programmers are people whose interests and knowledge cover programming and related subjects. In this age of information overload, let me tell you the 5 reasons why you absolutely must have at least one polymath programmer on your software development team.

1. They are fast learners
Their natural curiosity compels them to find out more about anything that interests them. Fueled by unwavering discipline, they quickly master the basics of a topic, and attain above average to advanced proficiency. Technology moves fast, and your team will benefit if at least one of you can keep up.

2. They are embracers of the unknown
You can only innovate if you are willing to step out of your comfort zone. To stand out means trying something no one’s done before. To create simple software solutions means seeing what cannot be seen. New ideas are born out of the darkness of the unknown. And polymaths are skilled at bringing them to light.

3. They are idea connectors
Their breadth of knowledge enables them to link seemingly disparate ideas and create new ideas. Sir Isaac Newton discovered the law of gravity from a falling apple. Archimedes found a way to calculate the volume of an irregular object when he was bathing in a bathtub. Fresh perspectives are a premium. The answer to your problem can be sitting just a few cubicles away.

4. They are role contortionists
They’re flexible. Polymath programmers know how to program in C. And C#. Probably Javascript too. Some Unix commands. ASP.NET. Connect to a database. Network stuff. Why a float or double is a very bad choice for storing monetary values. Write technical documents. Liaise with users. Answer technical questions from customers.

And when your star database administrator goes on leave, your polymath programmer can smoothly take on the duties. Your genius web developer has a cold and takes the day off? Let your polymath programmer handle that small but business critical graphic change.

This may sound degrading, but it’s true. Polymath programmers act like plug and play components. They can become whatever role you need them to be, whenever you need them to be.

5. They are autonomous agents
Set them an interesting and challenging task, and watch them work at it with little intervention from you. Amassing knowledge from different sources require self discipline and organisational skills. Let them know what you need, and stop bugging them. Your job as a manager is to stop other people from bugging them.

There you have it, the 5 reasons why having polymath programmers on your team can help with your bottom line. So how do you find them? That, my friend, is another story…

Applying squeeze theorem to software project management

It was a sleepy morning. I was tired and hungry, and in the lecture room, listening to the professor on freshman calculus. He was going on and on, and I was struggling to pay attention, and he mentions the squeeze theorem. Also known as the sandwich theorem. That perked my ears. I was just a tad disappointed when there’s no food involved…

One of the uses of the theorem is to prove that something is equal to something else, say x is equal to 5. If you happen to know that A is less than or equal to x, and that x is less than or equal to B, then you have this

What if A is equal to 5, and B is also equal to 5? You get this

When A squeezes upwards, and B squeezes downwards, by the squeeze theorem, x must necessarily be equal to 5!

Ok, the explanation is a little simple compared to the actual theorem. What I want to point out is that this happens when I’m doing a development project. You see, this is what happens

The customer rarely need everything that they state as a requirement. And the project manager rarely know enough about the software development involved to fulfill what is really required. Three scenarios arise out of this.

They never meet

What happens is I will have to do some serious creative thinking to fill up the gap in the understanding between the two. The customer might want a feature that is hard to implement, but an easier alternative can be done to solve their real concern. The user requirement given to me might have ignored certain software limitations or restrictions, and more effort is actually required. So not only do I have to program a listed feature, I have to make it satisfy both parties when they have different views on the feature.

They overlap

This one is tough to handle, because both parties have their own views on how to do it. My challenge is to prise them apart and convince them that my way will be the best solution. And I have to coerce them in a way that it looks like they are the ones who came up with the solution.

They shake hands

This is the situation I strive for. I have enough specifics to plan the coding, yet have some room for creativity, so as to pleasantly surprise both parties. I have the best chance of success when I am actively involved in the project discussion, or that I can provide preliminary analytical input to one or both parties. Thus will I be able to influence the final requirement.

Sometimes, I have little control over the direction of the software project. Sometimes, I can influence the people involved so that goals are met and everybody is happy with the output. Regardless of the result, I’m going to be squeezed.

Public speaking for programmers

It was a big project. Product managers were running around confirming details. Sales staff were calling their clients to do pre-launch informing with materials obtained from the marketing department. And management wanted a briefing on every aspect of the project given to every staff involved. This meant there would be people talking about how the product worked, the terminology used in the technology, the major companies involved… and the web application for supporting this project.

So I was happily coding one day, when my team leader came over to my desk to tell me that, since I was the one who single-handedly developed the web application for that big project, I would be the one to present it. I nearly freaked out. The last time I did any presentation in front of an audience was when I did my thesis dissertation. There were only a handful of people then. The number of people for this briefing was about 50. They range from customer service, sales, middle and upper management, marketing, technical, and of course the other speakers who were well versed in the business itself.

I was to present the workings of the web application, so that customer service would know how to retrieve information, sales people would know what to tell their customers and so on. And I’m supposed to be on stage for about 20 minutes. Oh my goodness.

Be prepared
It doesn’t matter if you’re a manager, or a technical support or a programmer. Prepare the material for presentation. In my case, a flow of the links and how they were connected to each other. But I made a fatal error.

When I finally reached the crux of my presentation, I couldn’t get any data to appear. There wasn’t any “Server application error” (which would be disastrous to my reputation). When I clicked the “Retrieve” button, there just wasn’t any data. The audience started to fidget. “Oh no, I’m losing it!”, I thought. Then it hit me. I didn’t put in enough test data! I readjusted my retrieval criteria, and finally got the result I wanted, and I breathed a sigh of relief. I might not be well versed in the business knowledge as my fellow speakers, but I darn well know everything about the web application.

The sequel
After that briefing, I thought I was out of it. Then I was informed that there would be an official product launch, and customers would be invited. And I was to present the web application. It’s no black tie affair, but is still formal enough to give me butterflies in my stomach.

I practiced my presentation. Over and over and over again. I prepared enough test data this time. I went through every single web page and thought of something relevant (or clever or funny) to say. I imagined how an actual customer would hear me, and I’d have to tone down the technical jargon so they could understand and relate to me.

On the day itself, I went early to prepare myself. I had my tie on, which I don’t normally have to wear, so it’s a little uncomfortable. I was to speak near the end of the entire event, so I had a chance to listen to the other speakers. When it was my turn, I clipped on the microphone and faced the audience. Oh dear, that’s a lot of suits. Alright, focus, focus… The web application was essentially a business tool, which meant it’s boring. I injected some humor, radiated every bit of charisma I had, and basically wove a story around the application. I even tried to sell with a story of how the customer can benefit from the product (even if it was wildly imaginative).

TIP: Do NOT crack any jokes that are sexual, political or religious in nature.

So everything was going fine. Until I saw the event organiser making hand gestures at the back of the room. “Lengthen! Lengthen the presentation”, she mouthed. I managed to present for about 20 minutes, and the flow of event items was such that we were early by about 10 minutes. I needed to add about 10 minutes more.

Luckily, I had some backup stories. Unluckily, one of them wasn’t too well prepared (I made it up just before my presentation), and I blurted out something that didn’t quite come out the way I wanted. I violated the tip I gave above. It might have been construed as a sexist remark, and it was a good thing I breezed right through to my next story.

The end
So what have I learned? As a programmer, I may not be business savvy, but I do know my stuff. Being prepared was my best defence against the fear of public speaking. I learnt how to continue talking, keeping the audience informed, while waiting for the web application to load the next page. This seemed very important to me. I’ve seen speakers who just stop talking and wait for their application to load, or their PowerPoint slides. The flow of your speech becomes halted, and the audience can feel disconnected because of the silence.

Well, until next time then. Maybe I’ll have to speak to an even larger audience. Wait, oh dear, I think I’m gonna be sick…

We should call them improvement reports

My career as a software developer has always been fraught with danger. I’ve been involved in several software projects now, and they all come with their challenges. The development cycle would involve the gathering of user requirement, planning, development and testing. The testing here refers to my testing. Where I work now, they have a whole department just to test the resulting applications of developers.

The gathering of user requirement is fairly simple. A couple of meetings, a few phone calls and some emails usually do the trick. Smiling helps. The simplicity of planning will vary, depending on deadlines (users will always say “as soon as possible”. Smile some more.), complexity of tasks involved and available manpower. For me, development is usually a breeze. I’ve shook my hand in the air (and mentally swore words that cannot be repeated here) whenever I do work with PowerBuilder, but that’s a different story. The internal tests are also easy. Enter a few values, make sure they are calculated and stored in the database correctly, and check that the reports are designed according to the user’s requirement.

The tests done by the dedicated testing department are, well, nerve-wrecking. I’ve had to duplicate the production environment onto the test environment. I’ve had to upload data, download data, change data and massage data from text to Excel and vice versa. I’ve got to refer to the finalised user requirement document to confirm (and defend) the veracity of my code.

There’ll be phone calls and emails to and fro, to confirm this, to help set up that, to ask why that number is supposed to be that number. I’ll probably be working on another project while smiling on the phone and scribbling notes on my already messy desk.

And I haven’t even gotten to the fun part.

At the end of the test period, I will be sent *drum roll*, defect reports. These evil documents contain what the testers had deemed unforgivable deviations from the righteousness of the user requirement document. They would identify the defect in my program, point their righteous fingers at me, and cackle “You made mistake. *dance around* Your program doesn’t work. *dance around some more* It’s all your fault”.

The thing about defect reports is that, well, they contain defects. When I pointed out that testers only focus on generating defect reports, I was faced with blank stares, with the implicit “Of course they look out for defects. That’s what they are supposed to do!”.

What you focus on, expands.

When the appraisal of a tester is determined in part by the number of defect reports the tester produces, what happens? That tester will produce tons of defect reports, on whatever bug or however slight the program misbehaviour was. This skews the perception of the accuracy of the program. Then when the defect report came to me, I would do whatever it took to downplay the report, to deny the existence of the purported defect, uh I mean inconsequential oversight, where I try to skew the perception back into balance.

This sparring of responsibility is damaging to the project, unhelpful to the user, and definitely a waste of the company’s resources. “Are you telling me you spent two hours typing that report about why there should be an ‘s’ for plural, when you could have been giving suggestions on how to improve the user experience?”. “Are you telling me you spent two hours going through every display message in the program code to make sure the ‘s’ was appended correctly, when you could have been implementing better features?”

Instead of keeping track of defects, we should be focusing on improvements. Yes, there are bugs. And yes, I will eliminate them. I also appreciate being told about them. I’m just a programmer. If you are a tester, you’ll be closer to being a user than I’ll ever be. Other than complaining about how lousy my program is, can you add anything to improve the user experience?