Applying squeeze theorem to software project management

July 13, 2007 By

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.

Filed Under: Work Stuff Tagged With: , , ,

Public speaking for programmers

July 12, 2007 By

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…

Filed Under: Work Stuff Tagged With: , , ,

Debug like a CSI

July 11, 2007 By

It is a morning like any other. You’ve got your tunes, you’ve got no one around in the office yet, and you are cranking out code like you’re on fire. Until some industrious user calls you and drags you out of your zone. You smile and nod as you listen to her explain that there’s been a tragedy, a terrible program error has occurred and she desperately needs your help. Time to debug like a CSI.

Document the scene
You ask her what exactly happened and you listen attentively as you jot down notes of her concerns, providing gentle affirmations and guiding her to the answers you seek. She’s practically in tears and just manage to tell you some name of the program she was using and a brief mention of the error itself. Then you ask her to provide you the most powerful piece of evidence she has: the screen shot of the error.

Gather evidence
So you’ve got an image of the error, and whilst you have every confidence in her statement, sometimes users just don’t see the difference between “An error occured” and “A Error occurred”. Her statement is probably something short like “I click Save button and there’s the error!”, so you don’t really have much to work on. She also probably sent you a 3 megabyte attachment of the screen shot and practically blew up your inbox. You note down the exact error message, and from her statement and the screen shot, find out the pertinent program responsible for making her life (and yours) miserable.

Evidence analysis
You open up the program code and use the Find function of the editor to track down the places where the exact error message occurred. You also retrace the steps taken for her to get that error. Hopefully, the error is documented in the code. If it’s a system error, then you’ll have to rely on her statement to pinpoint the exact location of the offending line of code.

You find out why the error occurred and if it’s actually correct that it happened, according to the business logic behind the program, then you give the user a call or an email to explain that everything’s fine and the error is supposed to happen. You might get more questions, such as the reasoning behind the business logic. But that’s another story.

Crime scene reconstruction
If you can’t find anything wrong, it’s time to reproduce the error. You have got to do exactly what the user is doing. It can be tedious when it’s production data you’ll be handling, and you have try out on a test environment. The test environment may not be identical to the production environment, some database tables might be missing from the test environment, and you’re starting to get cranky.

Somehow, you reproduce the error, and finally figure out the reason. You correct the error, recompile the program and send it to the user. You sigh as you are reminded of how poorly your department fails in the software management test you’ve read about, but that’s life.

Postmortem
Taking in a deep breath, and another swig of coffee, you settle back anxiously into your rhythm, half-expecting the user to call you to say that the error came back. After a few minutes, you slip into your zone again, the error forgotten like an ephemeral whisper…

Filed Under: Programming Tagged With: , ,

We should call them improvement reports

July 10, 2007 By

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?

Filed Under: Work Stuff Tagged With: , , ,

Chalcography, Die Hard and Gamberetto

July 9, 2007 By

The arts

For the past few weeks, I had passed by this bus stop where a post on the signboard had this alluring picture. It was Mona Lisa. It was also done in pencil, or so I thought (I was on the bus, and couldn’t see clearly).

So one day, I peered really closely, and discovered there’s an exhibition going on in the Singapore Art Museum on chalcography. Interesting…

Too bad that’s the only picture I could take. Galleries are off limits. Here’s what I found out during my tour of the chalcography displays:

  • Chalcography is engraving on copper to make templates to print paper (or some such)
  • Some of the prints are very detailed (individual tree branches, hair)
  • There are a lot of nude or semi-nude models in the prints (must be the Renaissance)
  • I find myself scrutinising at prints a lot (the backdrop, not the nude)

The exhibition is held at the Singapore Art Museum from 4 May till 22 July 2007.

Entertainment

I also caught the latest installment of the Die Hard series, starring Bruce Willis. Aside from the subtle nation protection messages, the bad guys used a lot of work from hackers, with the movie’s emphasis on the surviving whiz kid’s algorithm. Mathematical encryption program. Oh, that just warms my heart…

New experience

When I visited my favourite local pasta restaurant, they were offering a new selection. Thinking that it’s about time for me to try something new, I decided I could go for a gastronomical one. I chose the “Creamy Herb Gamberetto”. Normally, I prefer a tomato-based pasta, but since I’m going for new… It’s good. Oh, so gamberetto means shrimp or prawn. I think mine were tiger prawns.

I think I’m getting a headache from all the new experiences…

Filed Under: Offtopic Tagged With: , ,
« Older Posts
Newer Posts »