Rusty Divine

Live, Love, Learn, Teach

Top 10 Holiday Gifts for Geeks

Next to kids, out of all the categories you can wrap around groups of people, geeks have got to be the easiest to buy for. I wonder what would happen if like having age-appropriate ranges on toys there were geek-appropriate ratings on gadgets and goodies? We might see labels like, "For any cubicle penned techie", or "Object-Oriented Only", or maybe "Phor Phreaks".

Anyways, I've made a list of 10 uber cool gifts that I personally recommend for myself; i.e., if you've enjoyed my columns the last few months, consider sending any one of these items to me in gratitude.

10. The Spork - There's nothing I heart more than efficiency. Why should I have to put down my spoon and pick up my fork when switching from Dorito Crumbs to french fries? No More!

9. Soda Machine - Mountain Dew is the nectar of the gods. I used to work for Pepsi Co. you know; it was a sweet job. Remember those Pepsi points they put on their 12 packs as a total rip-off of Camel points? Well, every stinking soda machine I filled that year, I cut off those points and turned them in. I got duffle bags, bean bags, various paraphenalia, and to top it off - a Pepsi Mountain Bike - now that's styllin!

8. Digital Pen - It's a pen that writes in ink and, later, you can download all of your pages! I might actually prefer to remove the ink cartridge so that it looks like I'm not writing anything - that will keep those nosey coworkers scratching their heads at your next meeting! Plus, you'll be able to write what you're really thinking as Jane from marketing banters on about how Microsoft Word is the greatest database ever invented.

7. Hot Dog Toaster - Whoa, when I saw this baby I thought, "What would Homer do?" Nuff said.

6. Book Gift Cert - Now that Joel has updated his recommended reading, we'll all be scrambling to be the first on our block to read "For Days with Dr. Deming." Only four? Alternatively, a subscription to Books 24x7 might suffice - they probably have all those books in eTree form (note: if you live in Seattle, you have a free subscription to this through KCLS)

5. or RC Helicopter or Plane - Coders are very controlling, but we also welcome crashes as learning experiences. What says controlled crash better than indoor RC flying objects?

4. IMMORTALITY - If you've got some creepy love going for your geek giftee, then nothing beats giving the gift of everlasting life. For a slightly more romantic gift, turn your favorite geek into atree with floppy-disk fruit (5.25" or 3.5").

3. Ambient Orb - wireless wonder that changes color in response to the stock market fluctuations, IM notifications, new blog posts, and more.

2. Eco Orb - 98.5% of all Geeks' passwords consist entirely of these three letters in this order: g-o-d. Now, let your egomaniac geek friend have a dream come true with this little gem that is a self-contained enviroment that thrives for years.

1. Binary Clock - Separate the script kiddies from the top tier with a clock face that displays time in binary - hours, minutes and seconds! After all, "there are 10 types of people, those who read binary and everyone else."

Wrap Party

The final installment; part six of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.

Six weeks go by quickly, and the project is complete. Now it's time to take a look back to see what we can learn about what went well and what did not.

As one measure of the project, I'll use Joel's test of a good software development environment:

  1. Do you use source control? + 1 (We used VSS, shoulda used Subversion - we had some VSS hiccups that cost us time, although, last time I checked Subversion had some problems with ASP.Net projects, too.)
  2. Can you make a build in one step? +1 (no automated script, just hit build in VS)
  3. Do you make daily builds? +1 (Not too applicable to our little web app, but we essentially did this)
  4. Do you have a bug database? 0
  5. Do you fix bugs before writing new code? 0 (didn't use a bug database and didn't really pound on the code)
  6. Do you have an up-to-date schedule? +1 (used Joel's format)
  7. Do you have a spec? +1 (used Joel's format)
  8. Do programmers have quiet working conditions? +1 (got the Team Palace)
  9. Do you use the best tools money can buy? +1 (Good dev machines, latest software & 3rd party components)
  10. Do you have testers? 0
  11. Do new candidates write code during their interview? +1 (I instigated this one)
  12. Do you do hallway usability testing? 0 (shoulda, woulda, coulda)

Our Total: 8 - Not great.

We really should have been using a bug database, and I should have made the declaration that we need to find and fix bugs before writing new code. The project was a bit of a whirlwind, and it felt a little out of control at times, but that's all the more reason to try to confine the chaos.

The project could have supported a tester - we even had a young (read: cheap) guy that was light on work who could have done the job. He left for a vacation to his homeland - Nepal - early on though, and wasn't around for most of the project.

We easily could have done some usability testing - it was even in the original scope. Our usability lead left the project early on for maternity leave, and that loose end just didn't get tied up.

We did have a great team room though, and that was really the hallmark of this project. It was a big breakthrough for us because it was the first time a development team had requested their own room, and it caused some ripples throughout the office which will hopefully start to bring about change in how developers are perceived.

We overcame some early team friction, and in the end we jelled very well. I feel like I've made some new friends during this project who were just coworkers before.

We had a good up-to-date schedule thanks to Joel's spreadsheet (I've even been asked to give a brown-bag presentation over lunch to our division), but the original estimate wasn't exactly realistic. The problem always boils down to not knowing enough about the scope of the work at the time we submit a bid for the project. We aren't given a cushy business development budget to really nail down a scope prior to bidding on it, and frankly, our client likely would have been put-off by us if we tried. When I originally priced the project, I came up with $92K. The business analyst who knew the customer well balked at that figure - unfortunately, he is a business systems analyst and doesn't know by experience what goes into a software project - so I cut the cost down to $62K by making some major assumptions. In the end, the project cost about $75K, and we were able to ask for the extra $13K from the client due to out of scope requests; it remains to be seen if they'll actually pay us for it though. I now regret having bent to the pressure to reduce the original estimate. I think it would have been spot-on for a quality web site that was well debugged. Instead, we produced a fast and cheap application that sacrificed accuracy.

We had a problem with entangling priorities. I was being pulled in two different directions by critical dates on this and my other project. I don't think its realistic to expect to focus on just one project in my line of work, but I can't avoid saying that dividing focus does reduce quality.

The spec documents were a big hit - we wrote them with a sense of humor that was a welcome change for our readers. The clients and the project manager all appreciated the specs, and it was obvious that they actually read them in entirety.

The end product is finished, and I'm glad to be moving on. Getting closure is one of the benefits of a quick job, and if you've ever been unfortunate enough to work on a job that drags out indefinitely with constant scope changes and no schedule, I'm sure you appreciate closure, too!

Thanks for all who have read and commented on this series. I hope it has been an entertaining read - it was fun to write. I'll be switching back to a more technical style for a while, but I may revisit this novel-style periodically.

Beta max

Part five of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.

"Can we add a link for Trip Reports under the Correspondence section?" Brett, our client on a small web application project, asked during the alpha demonstration.

"Of course," was my gut reaction, "Do you want it below the link for Meeting Minutes?" And with that, the scope crept incrementally.

Overall, the alpha demonstration went very smoothly. We used Live Meeting to share our desktop with the client, which worked great, even through the firewalls. Brett was happy with the progress we had made in short order, and besides the few new features they asked for during the demo, we were right on schedule.

Those few innocuous-seeming feature requests, though, would be starting to threaten our deadline if it weren't set in stone - instead, usability and quality will take a hit, or other features would be dropped. I was using a variation on Joel's schedule tool that included release version, and a column for date added, and one for notes on scope creep.

After updating the schedule, it was obvious that we had more features than we could finish. What should we do? Cut features? Skimp on quality? Add more developers? From cheap, fast, and good, we needed to pick two. Robert decided to call the client and ask what their preference was. We knew they had some money in reserve for contingency. Meanwhile, we'd finish the core features.

Continued next week...

Down to business

Part four of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.

It was Monday, and I was finally starting to feel at peace with my job and personal life. Friday's confrontation with Robert ended amiable enough with an agreement that we were basically on the same page; the problem was that we didn't know each other well enough yet for trust and understanding to develop. Even the confrontation started building our understanding of each other and brining us closer together as a team instead of driving a wedge between us.

I took the elevator up two stories to the fifth floor where Robert's office is, and waited for him to finish a phone call. While sitting in an adjacent common area staring at a wall-sized white board scribbled with notes, I took stock of my feelings. Although I had harbored waves of viewpoints taking me from angst for my career, to self-righteousness, to apathy, and back again over the weekend, I had finally found the calm of melding them in appropriate proportions.

"Are you finished?" I asked, as I stood in the doorway. Robert had just finished one call, but had a dial tone buzzing out through the speaker phone.

"Sure, come in, I will just be a second," he replied as he dialed a number and had a gave an answer to someone on the other end before promising to call back later.

I had come up to discuss the plan for brining in two developers from the Portland office to help out with the DTX and CPUD projects. Before we got into that though, Robert tested the water with his toe, "I just wanted to say that I think you guys are doing a great job on CPUD. I think we will cut into our profit a little on this job, but instead of asking for the extra $12K," money that we knew they had in contingency for the project we were working on, "I want to show them our integrity and not grab that cookie, even though I think they are waiting for us to do so."

I nodded and agreed. "I think we can really show them what our IT department can do on this project," he continued. "They've worked with our company's other departments, but this is the first experience they've had with us, which is why I want to impress them by brining this project in on schedule, too."

Understanding the undertone referring to last Friday's conversation about working overtime, I answered to his meaning, "Yes, I've been thinking about that. I think the reason I was so upset was because you were asking me to enforce your schedule," a schedule that I had objected to during our internal kickoff meeting as way too tight, "If I made the schedule, I would feel more comfortable asking people to stick to it," as I said this I wondered if I would ask people to stick to my schedule even if it meant overtime, and realized with a tinge of disgust that I would; the difference being whether I had bought into the schedule or not. "I think since it's your schedule, you should ask the developers to work overtime."

"Well, it's not my schedule either," Robert replied with a chuckle as I remembered he was right. Robert had been brought into the project after that schedule had been set by the client and to a lesser extent, our analyst who closed the deal. Feeling somewhat sheepish, I acknowledged that it wasn't. "But I understand, and I will ask them, no problem."

"Thanks," I said, "I realize now that it wasn't your schedule; I'm sorry that I had forgotten that it wasn't. Now, let me fill you in on Janet and Jon from the Portland office."

We talked and decided that Janet wasn't needed to help out on DTX; instead, I would finish the project myself and Jon from Portland would stay this week to help Ryan out on the CPUD project while I stayed on the periphery to answer questions.

I was relieved with how everything shook out, and headed back down to the team room to get to work on completing DTX. About a half hour later, Robert did come down and talk to Ryan and Jon about working overtime, and somewhat to my surprise, they both seemed eager to do it.

The rest of the week went very well for both projects. Ryan, a brand new employee at our company, had shown he could work independently and efficiently. He wasn't one to pester me with trivial questions; instead he had shown he was perfectly capable and competent to make all the little decisions that are necessary to bring a web application into being, from choosing colors to deciding the best way to implement a feature.

Jon showed a quiet and understated personality. He would ask probing questions like, "Do you want a person to be able to belong to two organizations?" And I'd start out answering, "Yes, some people may work out of two offices, which will each be treated as their own organization," and then sometimes I'd realize what he was getting at, "Ohh, I see, but then we'll need to do multiple templates for each," or some such realization, but usually he would then shine the light in on the problem.

On Robert's suggestion, I brought in some Krispy Kreme donuts one day for the crew, which were a nice perk for all of us. The next day, the guys gave me a coffee order and I went down to the café to get them their drinks. After that, I considered it a standing order and filled it every morning on my way to the team room.

Our team was really starting to jell, and the projects were both benefiting from it. By the end of the week, we were well prepared for the Alpha demonstration scheduled for the following Monday. We would use Net Meeting to do share our desktop with the client and walk through the application to get their comments.

Continued next week...