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: , ,

Live Earth 2007 – Post-mortem

July 9, 2007 By

It was a bright and cheery Saturday. I had an unexpectedly wonderful afternoon in the art museum (which is another story), and had already decided to check out what Live Earth program aired on the local TV network.

I watched a few minutes of the program, and decided that I don’t really know any of the musicians and that I’d be better off doing something else. Like reading.

Alright, fine, I surfed the Internet. I checked out the Live Earth web site again. And I finally noticed it.

The organisers are obviously not fans of the Law of Attraction. What you focus on, expands. Concerts for a climate in crisis, will keep the climate in crisis. I suggest “Concerts for a greener planet”.

I also found this interesting little nugget:
I have a sensitive nose and lungs. Anytime I see or hear “incense” or “smoke”, I try to stay far far away.

I thought burning stuff will contribute to the rising global temperature. Why do I need to light up an incense stick?

There has got to be a better way to check for window drafts. Forgive me for asking, while we’re here, can someone tell me why we need to check for window drafts? I live in Singapore, and if anything, I’d love a draft, because it’s unbearably hot here.

Filed Under: Offtopic Tagged With:

Save our Earth

July 6, 2007 By

Tomorrow, on the 7 July 2007, is when Live Earth, a huge music event is held. The event is held separately over 7 continents, and many musicians will be performing. The objective is to raise awareness about our planet’s climate crisis, and to get people to take action.

I am moderately pro-green, reusing plastic bags when possible, taking public transport, and rarely buy and drink from cans or plastic bottles. I switch off lights when they’re not in use and turn off my computer when I’m done at work or at home. (If you’re one of my colleagues reading this, please, turn off your computer when done. Saving the couple of minutes for Windows to start up is a ridiculous reason.) But I’m not an extremist.

Saving our Earth. Can we do it? If all of us make a concerted effort.

I’ve read some negative comments about Live Earth contradicting the very message it’s conveying. The argument is that top musicians and artists will need certain comforts, such as private jets, and these comforts will cost the Earth. And concerts consume an insane amount of energy, what with all the lights and sound equipment. And concerts bring huge numbers of people together in one spot. I’m quite sure there will be food, there will be trash, there will be human waste to be disposed of, and not necessarily in that order.

These are all valid arguments. I also want to point out something else. Remember the concerted effort part? To bring people together, with the same purpose, with the same ideal, is hard. As hypocritical as the arguments make of the Live Earth concerts, these concerts will do one thing: align a large number of people on the same wavelength. They just start out with music as the connecting frequency. Everyone sings along and dances with the rhythm. Which brings us to a secondary effect of concerts, that people are energised during the performance. People are enthusiastic, excited and eager, all very positive and supportive qualities for mass ideal alignment.

I’ve played a game, Final Fantasy VII, where the fate of the planet was at stake, the Lifestream of the planet was slowly depleted by inconsiderate acts. Then there’s the scene in Matrix, where Agent Smith was interrogating Morpheus, and Smith says that humans are considered a disease, a virus, because we destroy and consume anything in our path. We latch onto our planet like a parasite and sap the life out of it.

The question is not about whether Live Earth concerts are hypocritical. It’s not about giving up all the niceties that modern technology has brought us, and go live in a cave and eat only produce from our own gardens.

The question is, are you doing anything about it?

Filed Under: Offtopic Tagged With: ,

So much for web safe colours

July 5, 2007 By

Whenever I’m faced with a web design decision, it almost always involve the issue of colour. I will test and tune the colour theme and combination of graphics, page elements and text colours. Then I’ll have to switch to a low resolution setting with a colour depth from the early 20th century. Why do I care about this unthinkable and ugly setting?

Because some of my users still live in prehistoric times.

They are totally fine with Windows applications running on drab grey backgrounds, icons that seem to be straight out of a 3 year old’s art experiment and hideous colour combinations such as bright green, blinding yellow and depressing slate blue. And they are absolutely comfortable with web applications looking like those grotesque behemoths of applications they use every day.

I’ve studied proponents of web safe colours, and I say “Enough!”. We have to embrace our gift of sight. The human eye is capable to distinguishing many colours. Computer hardware and web browsers have evolved to the point where there are colours displayed which the human eye cannot separate with accuracy. We. Have. 32. Bit. Colour. Experience all the colours.

Now, the .Net Framework provides the KnownColor enumeration, so I’ve used that as a base. I wrote a C# program to generate a reference HTML page with the colours and their names and hexadecimal values in it. Every time I’m stuck, I’ll pull up this reference page and look for the closest colour I desire. Then I’ll dump that hexadecimal value into my image processing application for finer adjustments.

So much for web safe colours.

Filed Under: Curiosita

Order in chaos

July 5, 2007 By

My desk is a mess.

My computer takes the centre position. That’s about the only place with some semblance of serenity. Surrounding this electronic piece of equipment, chaos reigns. Files are stacked and shoved to one corner. My bag and other personal belongings are packed to the other corner. I’ve got a C# reference book practically acting as my permanent armrest for my left hand. I don’t even have space to put my other three reference books, and I have to put those on another desk. And the pieces of paper scattered all over, covering every centimetre square of space on my desk.

And I can’t work without this mess. I need this chaos around me to function. That pile of paper there? That’s my programming reference pile. This pile here? My immediate-tasks pile. The one beside it? Oh, the project-just-over-but-keep-in-my-face-for-emergency pile, which slowly joins its comrades in the so-long-ago-I-forgot pile. Then there’s the scribbles, where I scribble down stuff like thoughts, notes, user interface prototype drawings and shorthand of user queries.

The apparent haphazardness of my desk actually has an order to it. Like handing a value smaller than 1 to the “minus x square” function, the chaotic disarray goes one way and then another. And as you continue, you find everything slowly settles into order.

The function eventually goes to zero. And my desk arrangement finally makes sense.

I’ve peeked at my colleagues’ desks. Their files and papers are all neatly stacked into rectangular blocks, with nary a sheet out of place. I can also see large parts of their desks’ surface. My mind is capable of pulling seemingly disparate ideas together. The natural way for my work desk to manifest is by being a mess.

I can’t tell you how many times I’ve wondered if a high level manager walks by my desk and judges me to be anything less than competent, based on the condition of my desk. I, am afflicted with NADD. This is who I am. I will be listening to music, while I’m feverishly jamming the keyboard, wishing the code will appear as fast on screen as it is in my mind, and tapping my feet in tune to the rhythms. Then I’ll be writing some comments because that piece of code will probably confound anyone else who reads it, and midway through the commenting, I’d think of some funny expression and I’ll check my English on Merriam-Webster. And oh yeah, I need to check that SQL expression to do string manipulation, and then Google it. Then the phone will ring, and I’ll drop my earphones, and I’ll wait a while to clear my throat and then pick it up, to attend to the needs of some user. I’ll then clasp the phone between my right ear and shoulder (because research shows the right ear is connected to the left side of the brain, which is better at deciphering voices than music), while opening up a document to confirm some details. And after I finish answering the user’s query, I’ll think to myself, “what the heck was I doing before this?“. Ok, what was I talking about? Oh right, so I find it unbelievable that anyone can have a neat desk, and so I decided to ignore the high level manager and just do what I do to produce results.

I usually have half a dozen applications open on my computer desktop at any one time. I thought this to be bad. Then I saw one of my colleagues have so many windows open (yeah we’re in the Windows camp. Hey we telnet to do some *nix work too), that the taskbar had to double up in width (I’m starting to do that too these days…) because there are too many taskbar icons.

I also know of some of my users who have ten Excel spreadsheets open. Or two of the same application open because they think it’ll work faster. Or they’ll give the impression of being multitasking. STOP IT! Multitasking is a fallacy! David Allen uses the term “rapid refocusing”. Some people can bring chaos into order. Some people can’t. If you need to have that many windows opened to gather information, and you’re a user, your IT department is slacking off. Go pester them.

If you are someone who thrives on being in the eye of a tornado, who finds peace in chaos and who can bring peace from chaos, I salute you. Welcome to the real world.

Filed Under: Work Stuff

Just say hi

July 3, 2007 By

As of this writing, I have worked in a corporate environment for just over four years. My colleagues are great and I (usually) like my work. There’s something missing though. A pervading miasma of human frigidity saps the friendliness out of the air. Teams don’t really talk to other teams, let alone between departments.

The sad truth is we form cliques and this will ruin creativity. Innovation will then only come from ideas within the clique, and let’s face it, one can only come up with so many ideas in isolation. With my main job role as a programmer, this “island clustering” means I’ve got few people to bounce ideas off of.

How do we bridge the gaping maw present in corporate human interaction?

Just say hi.

I read about this advice from New Rules @ Work by Barbara Pachter. She wrote a short chapter about it, covering topics such as the greetings used (“hi” or “hello”) and at what distance between you and the other person you meet should you say or do anything (5 feet minimum and you must say something).

The experiment.

So I tried it. Several weeks ago, on one blustery morning, as I was walking along the side of a row of cubicles, someone was also walking towards me. I quietly cleared my throat, looked her in the eye, and said “Good morning”. She just breezed right by me without giving me a look. Oh this is gonna be hard…

For the next few days, I tried really hard. I said “Hi” or “Good morning” to anyone I met. Along the cubicle aisle. On the way to the pantry. Not one single person responded. Then something magical happened. Some of these people started noticing me, that I’ve been greeting them. They turned and looked at me when I greeted them, but still they said nothing.

Then one fine morning, as I was walking back from the pantry after getting some water, I greeted another person. I was pretty much discouraged by now, and my heart wasn’t really in it. There came a feeble “hi” from that lady. I nearly jumped for joy. I got another person to respond! It was unbelievable. I walked back to my seat, smiling all the way. I could have clicked my heels in the air, but I thought that’d look ridiculous.

It’s still hard now. Sometimes. Sometimes they are looking away from me. Sometimes they have a scowl on their face, and I was afraid they’d bite my head off if I waved and said “hi” to them. And sometimes, I just plain forget. And sometimes, some of them says “hi” or “Good morning” to me first. That’s just awesome.

Do not discriminate. 

Let me give a piece of advice. Greet everybody. I don’t care if the person is your boss or your boss’s boss. I don’t care if that person is the cleaning lady. Greet everyone. Especially the cleaning lady. You do not want to slowly find that your trash bin is almost always never cleaned out, or your desk not wiped.

Now go say hi to your boss.

Filed Under: Work Stuff
« Older Posts
Newer Posts »