makeshiftmind

Last week was difficult for me because my development team at work pushed out our first release of NAWS business software, which turned out to be less than glamorous. I worked far more than 40 hours, and even stayed overnight in the hotel next-door to the office (partly because of bad weather, partly because I worked very late and needed to be at work early the next morning). Hopefully this will be better, but it is already shaping up to be another frustrating run at dealing with all the problems native to software development.

But I have learned something that I think is important to share, and that is: it’s all about options. As a developer, I don’t get the luxury of putting my head into my hands when things go wrong and wishing away my problems. When a company’s profit margin (read: lifeblood) is on the line, I can only really do one thing when problems surface: analyze problem situations, and enumerate my options for correcting them. Sometimes the solutions are less than ideal; sometimes they require me to use metaphorical duct-tape to fix a problem that would have been a mute issue if more planning had occurred. But no matter what, the problem still remains, and I am still responsible for fixing it.

In high-stress situations, it is easy to get provoked by rising temperaments and accusatory clients. Today a member of our administrative staff was having a problem doing her job, and promptly called me in to help her. When I arrived, she explained to me what her problem was, and I began to explain *why* the problem was occurring. She got a rather smug grin on her face, looked at me as though I was the most stupid person she’d ever met, and said “No. That’s not the way it’s supposed to work.” For a moment, my blood pressure rose very noticeably, and I was tempted to squint my eyes, get very close to her, and whisper, “I can replace your ass with a very small shell script if I want to.” – but I didn’t. Instead, I kept my calm, and patiently explained to her that I had implemented a work-around for her particular problem, and showed her how to use it.

The problem had surfaced earlier, and I had decided that my best option was to develop a small, yet inefficient user interface for her to manually correct the data she was working with. I do not enjoy developing “work-arounds” for problems that could have been corrected in the design phase, but often I must resign myself to the fact that for all my idealism, I cannot change reality simply by wishful thinking. The company must move forward, and I must “fix” the problem by whatever means necessary – often with code that makes me cringe because it is so utterly horrid.

So the moral of the story is this: reality often poops on our parade, and the best thing we can do is analyze our situation, come up options to correct our problems, and work forward in incremental steps until those problems are eliminated. We may need to revisit the problem more than once, but that’s ok – it doesn’t have to be perfect the first time – it simply has to work.