JohnnyCoder » Management

Don’t Choose Option 2

Ben Griswold — Sat, 14 Aug 2010 00:32:27 +0000

Does this ever happen to you? You finish coding something up and the very second before you become pleased with yourself you suppress that wonderful feeling and wrestle with the fact that coders aren’t exactly impartial when it comes to judging their own code. You realize you have two options. 1, you can accept the fact that a second pair of eyes can’t hurt and you can go around the office in search of that nonbiased someone who is willing to sit down, review your code and provide honest feedback. Or 2, you can say “to heck with it” and just move on to the next thing.

I’ll leave you with this – there is value in every code review. Whether it’s you, or the reviewer, or the project, someone/something is always better off because of a code review. Next time, don’t choose option 2. And who knows? Maybe you’ll get that chance to be pleased with yourself after all.

Learn Lean Software Development and Kanban Systems

Ben Griswold — Wed, 26 Aug 2009 21:38:43 +0000

I did an in-house presentation on Lean Software Development (LSD) and Kanban Systems this week. Beyond what I had previously learned from various podcasts, I knew little about either topic prior to compiling my slide deck. In the process of building my presentation, I learned a ton. I found the concepts weren’t very difficult to grok; however, I found little detailed information was available online.

Hence this post which is merely a list of valuable resources.

Ramblings About Scrum

Ben Griswold — Tue, 21 Apr 2009 04:51:42 +0000

Over the past few of months, Scrum has taunted me.

It started with two excellent Thirsty Developer Podcasts – The Thirsty Developer 14 with Ed Chaltry talking about “an Agile process” that can be used to manage and control complex software and product development using iterative, incremental practices and then The Thirsty Developer 28 with Sean McCormack talking about how Scrum and Agile principles can be applied to the enterprise. These podcasts provided such a detailed overview of Scrum that I couldn’t help but get excited.

Next, a co-worker did an excellent presentation on Scrum after successfully introducing Scrum into an organization where he was consulting. The presentation both piqued my interest and left me questioning the merits of Scrum. Actually, it had a lot of folks in my group asking questions. Maybe-not-so-coincidentally this was right around the time Martin Fowler’s Flaccid Scrum article was published.

Shortly thereafter we started using Rally Software to help manage a couple of our in-house projects and I found myself in the role of Scrum Master. The Rally tools are great. Scrum or no scrum, I’d recommend the product.

Since I was now a “Scrum Master” and under-qualified, I figured I should learn more about the role so I finished up Agile Software Development with Scrum (Series in Agile Software Development) by Ken Schwaber and Mike Beedle which I had been working on for a couple of months. I also read Head First Software Development by O’Reilly Media. Though it is an awesome resource which touches upon a number of Scrum-like processes and I recommend it to any developer (especially a junior developer on their first week on the job) it mostly through me off track as it didn’t truly define Scrum.

Which brings us to last week….last week I watched Uncle Bob Martin’s presentation at Chicago ALT.NET on XP: After 10 years why are we still talking about it? Though Uncle Bob paces in and out of camera throughout the entire one hour presentation, he’s one heck of a speaker and the presentation is a gem. He provides a really nice overview of why Scrum has hit the mainstream whereas XP certainly has not. He talks about Scrum being a subset of XP – Scrum took all the project management aspects of XP and left all the technical processes like continuous integration and TDD behind – and why this, Flaccid Scrum, ultimately fails over time. The heart of Uncle Bob’s talk is craftsmanship which is a powerful message in it’s own right but it really brought my learning of Scrum full circle.

I had my half-yearly review last week. Under the goals I listed for the next evaluation period, I included my desire to become Scrum Master certified. I’m not sure there’s much merit in this certification; however it certainly is a means to better learn the Scrum way of doing things. Perhaps surprisingly, Scrum certification was one of the easier goals for the next six months. I think I’m going to be busy. Wish me luck.

Introducing Lightning Talks

Ben Griswold — Tue, 29 Jul 2008 17:54:56 +0000

The folks I work with are wicked smart. Go back and read that first sentence again. This time read it like you are Ben Affleck in Good Will Hunting or one of the guys I used to play summer ball with outside of Boston. Fun right? Anyway, the point is I work with really smart people and I like to push random characters voices into the heads of my readers.

Tip Number 1: If you have the means, I suggest you plant yourself in a similar environment. There’s nothing you can do to better for your career than surround yourself with talented, smart people who are passionate about their work. It doesn’t matter if you are a junior coder, manager-type or CTO. It’s just good sense.

The problem with my current environment is we are scattered amongst many projects, across many clients and the opportunity to collaborate doesn’t knock very often. We do have a weekly team meeting, but it generally focuses on business/management stuff. I do find that software development talk often surfaces at lunch but arousing conversation around grass fed vs grain fed cattle is equally as likely. There really was no venue to really talk shop and harness the collective software development knowledge of my coworkers.

So, I suggested we start hosting Lightning Talks… The immediate response was very favorable (everybody likes to hear themselves talk, right?) and this week we held a very quick business/management team meeting and then the development staff started our first round of *modified* Lightning Talks. I emphasis the word “modified” because we broke a rules. Read on. We kept things very informal and, in the spirit of lightning talks, intended to host a number of very quick quick 3-10 minute presentations. Unfortunately, we kind of blew it with the time allotment as my two talks, one on AnkhSVN and the other on Inno Setup, took 5 minutes and then 45 minutes respectively. All the same, everyone seemed genuinely interested in presentations and the pseudo-lightning talk concept (although you never know because I work not only with really smart people they are also very kind.) Perhaps the best evidence of the Lightning Talk success was at least one coworker volunteered to do a presentation next week and our internal Wiki already has a section dedicated to presentation notes.

Tip Number 2: Introduce a similar practice to your workplace. No matter what you call the meeting, getting coworkers talking about technology is one of the best ways to get introduced to new ideas and sharpen your existing skills.

Wish us luck on future talks. Let’s hope my brain doesn’t get too big.

What’s the Level of Difficulty?

Ben Griswold — Tue, 17 Jun 2008 21:45:34 +0000

My customer recently asked me if my current coding assignment is difficult. I believe his exact question was, “On a scale of 1 to 10, how technically difficult is this project?” If you have been in the software development business for more than 2 hours, you know this is a loaded question. Quickly reply with “It’s highly technical and super hard” and you may be perceived as being over-your-head or even incompetent. If you say “It’s super easy” the customer may wish to speed up the product delivery or wonder why your code hasn’t been delivered already. Say anything in between and, well, your client may think you’re keeping something from them.

Fortunately for me, I’ve built up a good working relationship with my client (who’s a very reasonable guy) and I have gained trust through regular status and deliverables. We’re both happy with the current state of the project and therefore I took the question as he merely being curious. I have given the benefit of the doubt and I don’t believe the question was loaded at all. Time will tell…

Notwithstanding, as uncomfortable as the question is when coming from your customer, project manager or project lead, it is still a great question to ask yourself. A number of factors should play into your answer but I’m willing to bet there’s an aspect of your effort which factors in the most. For example, my biggest factor is the sheer number of components. If you have worked with me for any duration of time, I hope you know I keep my architecture as simple as possible at all costs. My ego doesn’t like it but my tiny brain and my clients tend to thank me for it. Though I whole-heartedly stick by the architecture I’ve put in place for my current effort, it is made up of a dizzying number of components — certainly more components than the typical, single-developer, 3-month assignment. Specifically, I am hosting a web application, web service and a SQL 2005 DB. I am also distributing a Windows application, Windows service and a third party application to client machine’s using custom installers. The web site features online order/purchasing and reports using Adobe Flex. All development (other than Flex) is using .NET 3.5 Framework and I’ve opted to use WPF for the Windows application. With the exception of Flex (which I’m hoping goes away soon) and WPF, it’s all stuff I’ve done before although it has been an awfully long time since I built a desktop application. Each piece of this puzzle isn’t overly difficult on it’s own, but collectively I think this solution is quite complex. If I could, I would dumb it down, but I can’t. I simply have to acknowledge the complexity and mitigate what I perceive as a risk.

So, on a scale of 1 to 10, how technically difficult is your project? If it’s high, is there anything you can do about it or are you kind of “stuck” like me?

Good Estimates Despite Bad Process

Ben Griswold — Thu, 14 Feb 2008 02:18:32 +0000

Are you involved in your company’s project estimation process? If so, let’s pretend. Let’s pretend that your company has internal constraints which makes estimating rather difficult. For example, let’s say you were required to completed all of your 2008 estimates towards the end of 2007 despite the fact that very few requirements were known. Don’t get me wrong. There were a few requirements but they were very high-level or what I would equate to a vision document or merely a great idea someone thought up while taking their morning shower. Of course, no one should expect these estimates to be all that accurate, but just for fun, let’s pretend that some felt they would be good enough to use as a basis to determine the entire budget for 2008. Kind of scary, eh? Well, I’m familiar with such a process and it is really scary and frustrating and, in my opinion, a tough way to end and start a year. You do learn to deal and make the best of it though.

It goes without saying but estimation is an art. It is hard enough if you have all relevant information at your fingertips. The thing is we rarely do have everything we need. Now, I recognize the provide example is a little to the extreme, but it happens. Believe me, it happens. Again, you do learn to deal and make the best of it though. But what if one wanted to improve on the process summarized above? What could be done?

I think the first step is determine the key factors in providing a good estimate which I believe included the following:

You Need Good Requirements: Good requirements have the greatest impact on an estimate. As requirements become more complete and detailed, estimates become more accurate and our confidence increases. Period.
You Need An Appropriate Estimator: Estimators should be chosen based on their understanding of the requirements, their knowledge of technology and possible solutions and their past estimating experience. The decision of whom should estimate one’s projects should not be taken lightly.
You Need To Know The Implementer: To provide a good estimate, it isn’t really necessary to know who will be performing the work, but since no two developers have the same skill set or experience, knowledge of the implementer can help firm up an estimate considerably. If nothing else, you need to know the candidate’s assumed skill set and domain knowledge.

It should be noted that we often think that timeline and/or budget have an affect on our estimates. This is only true because these factors affect scope, which in turn affect requirements, which are ultimately reflected in the estimate.

Once the key factors are identified (maybe there’s more than listed above), a better process needs to be defined. Assuming the company absolutely has to continue estimating and budgeting for the upcoming year prior to having solid requirements, I would suggest breaking the estimation process into three stages in order to continually firm up one’s numbers as additional information is provided:

SWAG: This high-level estimate is based on the limited requirements offered in the project request. Since this estimate is typically provided by management, and is based on few requirements, it should come along with a fairly low confidence level. Unfortunately, the allocated budget is tied to these estimates. Since none of individual estimates will be accurate, the best case scenario is to end up with estimates balancing themselves out. In other words, for every over-estimated effort there will an under-estimated effort. If the majority of efforts are under-estimate, you are screwed. If the majority are over-estimated, you are bound to have some awesome launch parties.
Detailed Estimate: This estimate can be produced once detailed requirements are offered. This requirements would come in the form of a BRD or FSD. Who produces this estimate? People with knowledge of the product and the technologies who will hopefully be involved with the project until it is released. This estimate becomes the foundation of the project plan and is the basis of all staffing requests.
Developer Validation: Once development assignments are distributed, each developer will validate the provided estimate against his/her associated tasks. Adjustments to the project plan and staff plan will be made if necessary.

In theory, one should expect estimates to change as scope or staff fluctuates — if we follow the steps above.

In no way is this high-level plan a silver bullet. It isn’t necessarily realistic for all shops as I, for one, can’t remember the last time I was asked to estimate a project AFTER I received firmed up requirements and I can’t think of a single case where scope didn’t change between a project’s inception and its end. I guess that’s why estimation is an art. You must leverage whatever process you currently have in place, search hard for few facts and then provide your best guestimate all the while knowing that things may very well change tomorrow. I do believe if one respects the key factors and overall process above, there’s a better chance of success than if these core ideas are disregarded.

Best of luck with your next estimate. By the way, what did I miss?

Question Everything

Ben Griswold — Thu, 07 Feb 2008 04:57:22 +0000

You may have noticed the recent attention given to TDD and whether it has been proven effective or not. I think the entire “conversation” is great. I appreciate everyone’s position primarily because the parties appear to be presenting their opinions and the interpreted facts with open minds. If I were to take sides, though, I think I would be in favor of the “Not” argument mostly for the reasons I commented about on a recent post by Jon Galloway:

You know, it is pretty easy to read the popular blogs (especially the ones which make references to “alpha” programmers) and think their way is the right way. I take a lot of pride in [dev stuff], but if I hadn’t been in this business for a while, what-every-developer-must-know type posts could really get me off track.

Please do not interpret this as a knock on the “popular blogs.” I like them a lot, but what I love is the fact that Jacob Proffitt took the time to challenge the TDD effectiveness evidence. It isn’t for a lack of trust, it’s just that as developers it is our job to question everything. Equally, it is our job to validate everything.

I literally just wrapped up a meeting with one of my lead developers. We are just over a week away from rolling Version 2 of an application to our Production environment and today — one day after our final QA release — he discovers where Version 1 of the product lives and what it is *really* doing. Why did it take so long to find out the real story? Well, he (really we, I am equally responsible) trusted documentation and what past developers shared with him…and now we are in a bit of a pickle. If only we verified earlier. Fortunately, this kind of thing doesn’t happen often, but I’d be willing to bet that something questionable crosses each of our paths every single day.

Back to the TDD effectiveness conversation. Here’s my semi-confirmation bias story as it relates to TDD…

I worked at a shop where fingers were pointed towards Development no matter what the technical issue. The web server lost connectivity to the app server. Database XYZ hasn’t been backed up for 8 weeks. The L Drive has only 97KB available. Two new defects were just introduced into the Production Environment after four months of testing. A third party web site is down. Quick, call the Developers. Don’t call Networking. Don’t call the DBAs. Don’t call the NT Admins, the QA group or the third party site owners. Call the Developers. Maybe you are familiar with such a place? Anyhow, since Development clearly had to straighten up its act, we needed to provide evidence (there’s that word again) that we were putting more care into our code and validating our applications prior to release. Thus, TDD was introduced to my shop. We found the perfect guinea pig project — an Enterprise Messaging System (read: glorified email engine.) It was simply a service which sat around waiting to complete requests issued by a handful of web applications. For this app, we did true TDD as we actually wrote the tests before the code. All the tests passed and we rolled the service to QA and, lo and behold, not a single defect was logged against the Enterprise Messaging System. It was deemed perfect. The greatness of TDD was soon shared at the quarterly IS meeting using the first-ever defect free application as evidence of its brilliance. I think those who pushed for TDD were hoisted on shoulders and paraded around the conference room as Development had finally had gotten their sh*t together.

If truth be told, instead of praise and congratulations, everyone should have been asking a whole bunch of questions. Was TDD really the reason for the bug free code — directly or even indirectly? Was a superior product released because time was taken to validate all of the tests? Perhaps merely taking the time to write the tests before coding gave Development a needed boost? Well, these questions certainly couldn’t be proven either way. What about the zero defect count providing evidence that TDD was our saving grace? Very simply, there was no relationship between TDD and bug free software at all. In fact, the service had bugs, but no one other than the developers knew it. All bugs were logged against the calling web apps (as testers couldn’t interpret the difference between a web app failure and a service failure) and fixes were applied to the service unbeknownst to the folks looking for the last great Development hope. It was all a matter of sharing only the information which supported Development’s case as well as stretching the truth a bit.

If you look hard enough this stuff happens every day whether it be accidental or intentional. Though it is exhausting, it isn’t a bad idea to question everything — or not. The choice is yours.

Change is Good (Or Not)

Ben Griswold — Tue, 05 Feb 2008 02:26:58 +0000

I have a friend who has been involved in multiple reorgs over the past couple of years. He used to say “change is good” with enthusiasm and some conviction, but now he merely speaks those words under his breath in a feeble attempt to convince himself it is so. My friend chooses to think that the changes are made with the best intentions and for valid reason. He also chooses to think the changes must be for the better good and if a mere engineer could only see the “big picture” they would agree.

Yet the reorgs have become discouraging. He has said that one reorg is survivable — even welcomed. A second reorg is bearable yet questioned. A third reorg is laughable. Additional changes are, well, the joke’s over. Of course, it would be naive of my friend to think a business — any business — can survive without some element of change, but to his point, continuous change to roles, responsibilities and reporting structures can not be made without a cost.

When it comes right down to it, there are a number of factors which should be highly considered when mixing the personnel pot. For example, how much weight should team chemistry get? I mean, the team building, the earned trust, the relationships…it will be lost quite literally overnight. How about continuity and stability? How long does it take to get comfortable with your boss or your boss with you? All of the conversations on expectation setting, career planning and personal growth need to start back at scratch. It’s doesn’t say much for job stability, or job satisfaction, for that matter. Then there is the knowledge lost? How about when all of the application knowledge goes along with a person who has been assigned to other things? Somewhat devastating, I suppose. And when you shuffle around players someone ultimately has to do an awful lot of learning before they are a positive contributor in their new role. That can be a pretty big hit when an existing team members need to pick up the slack until the newbie is up and running. This list goes on and on…

Maybe breaking apart teams, swapping managers, disrupting continuity, weakening stability and losing knowledge is a small price to pay when you have a positive, end goal in mind. My friend isn’t sure, but he’s choosing to think that way…for now.

The Difference Between 5 and 6 Nines

Ben Griswold — Wed, 23 Jan 2008 01:32:57 +0000

We will occasionally pepper in a few brainteasers at the end of our interviews. Yes, they are sometimes the you-don’t-bury-survivors type questions. And then there’s the cube question which I have written about previously. One of the guys on my team likes to ask “port association” questions. He gives a port number and the candidate provides an answer. It is kind of fun to hear “80.” “HTTP.” “443.” “HTTPS.” “21.” “FTP.” “789″ “Pardon me?” The other evening a co-worker was sharing a past interview experiences. He was interviewing for a technical business analysis role and they asked him, “Is the clock on your VCR blinking?” To this, he replied, “What is a VCR?” Not a bad question and not a bad answer in my book.

Joel Spolsky translated uptime percentages to allowable time/year outages in today’s Five Whys article. For example, an SLA stating something like 99.99% uptime allows for 52.59 minutes of downtime per year. Where am I going with this? How’s about this for an interview question: “What is the difference between 5 and 6 nines?” This question will probably generate some interesting answers. There will be a good number of individuals who are familiar with the term and they will be able to speak to the question. Some might provide the difference between 99,999 and 999,999. Others will perform the translation in their heads, give the correct answer down to the second and knock my socks off. If you find yourself sitting in on an interview with me, look out. This question is coming — or not.

DBTalk

Ben Griswold — Sat, 04 Aug 2007 20:10:23 +0000

Over the past 6 months, I’ve subscribed to the “DBTalk” distribution list at work and I’ve really been enjoying it. Here’s are my top 2 reasons:

1. Though I know there are many .NET coders who also happen to be very capable database designers and developers, I believe that the many of us still have a lot to learn. I would say that we all know at least the basics, but there’s an awful lot of DB knowledge that has eludes us over the years. If nothing else, the “DBTalk” distribution list has proven to be a non-intrusive way to educate an entire group of developers on SQL Server Best Practices and a few Tips & Tricks.

2. The moderator does a really nice job of getting everyone involved. Those of us who frequent technical blogs know this isn’t always easy — especially when your audience isn’t necessarily comfortable with the topic. Fortunately, the moderate provides information on varying topics for all levels and he throws out carrots all the time. For example, he’ll present a Tip of the Day and ask if anyone has an alternative solution or he will simply submit a problem and ask for possible solutions. It seems with most conversation at least someone on the distribution list is willing to bite.

Anyhow, with permission, I’ll be posting a number of the topics and tips which have been discussed over the past several months. They may come all at once, in chunks or one every once in a while. I haven’t yet decided.

Recognizing Programmer Breeds

Ben Griswold — Tue, 30 Jan 2007 00:19:02 +0000

Last week’s post about The Anti-team by Jemery Miller reminded me of a book I picked up a while back: Herding Cats: A Primer for Programmers Who Lead Programmers by J. Hank Rainwater. In his book, Rainwater offers tips and management techniques on everything from code reviews to managing a distributed workforce. With good humor, he discusses dozens to topics which relate to a software manager’s every day.

Per Amazon’s Editorial Review:

While many titles on software engineering and management lean toward the theoretical, this bookâ€™s candid and practical focus help distinguish it from the crowd. It also helps that the author is a good writer and mixes quotes from a variety of sources (including Jack Welch and Andy Grove). This is one of the few titles to concentrate on the all-too-common problem of good programmers promoted to project leads, where management and people skills, rather than raw programming chops, will often determine success.

I recommend this book to software development leaders with a request that special attention is given to the section entitled “Recognizing Programmer Breeds.” Here, Rainwater “stereotypes” developers for the purpose of understanding and identifying ways to work with them. He groups the breeds into three categories: major, minor and mongrel. Majors refers to the most common types you’ll find in the workforce. The minor breed are sometimes seen, but not as frequently as the major ones. Mongrels, are not very desirable, but the do exist in the workplace, and as a result you need to recognize them. Mongrels can work out fine, as long as you help them build up their skills to overcome the weaknesses they inherently bring to the coding process.

As Rainwater notes,

Any individual can be an amalgam of the characteristics identified with a breed — this makes working with that person a challenge but well worth the effort. Programmers are a wonderfully complex people. Relish the differences and unique styles of each breed. You’ll probably recognize many of these traits the next time you look in the mirror.

Here are the developer personality types which Rainwater dissects in his book:

The Major Breeds
The Architecture
The Constructionist
The Artist
The Engineer
The Scientist
The Speed Demon

The Minor Breeds
The Magician
The Minimalist
The Analogist
The Toy Maker

The Mongrels
The Slob
The Intimidated
The Amateur
The Ignoramus
The Salad Chef

You may recognize a few (without having to pick up a copy of his book.)

Update: You’re in luck. As Jon Rowett points out, Recognizing Programmer Breeds may be found at Apress.com for free.

The Cube Question

Ben Griswold — Mon, 29 Jan 2007 22:53:24 +0000

If I had to guess, I would say I conducted at least 100 phone or in-person interviews last year and all of the onsite interviews followed the same standard format:

1. Three or four lead developers, the interviewee and I sit in a large conference room.
2. Per our request, the candidate spends 3-5 minutes telling us about themselves.
3. The leads and I then take turns asking the candidate both technical and team-oriented questions.
4. When I get the sense that the team has had adequate time to make a hire/no hire decision, I ask the “cube question.”
5. Finally, we give the candidate some time to ask us questions.

So what is the cube question? It’s something I was asked in an interview years and years ago and I’ve never forgotten it. “How many sides does a cube have?” That’s it. Simple, yet surprisingly 40% of our candidates answer incorrectly. Honest. My guess is that most interviewees figure it must be a trick question and they over-think the answer. Others are probably so focused on answering the technical and team-oriented questions that they aren’t able to get their brain to chew on anything else. A small portion probably just have no idea what it is I’m asking.

When it comes down to it, the question, well, more importantly, the answer means nothing to me. Whether the candidate answers right or wrong, it is a nice way to wrap up our Q & A session and let the candidate ask us some questions. Not surprisingly, the bulk of the time, the candidate’s first question is “Did I answer the cube question correctly?”

When the candidate does give us the wrong answer, we sometimes ask for an explanation. We’ve gotten reasonable explanations why one would answer 8 or 12, but one candidate answered 35. When we questioned him, he said, “In his world, a cube has 35 sides.” We hired the guy and he ended up being one the most fun, crazy and talented coders around and we still laugh about it today.

[ I've had this post in my queue for a while now. I had to get it out there today after reading Jim Martin's post, You Don't Bury Survivors. Read it. It's fantastic. ]

//TODO Don’t Waste Time

Ben Griswold — Thu, 18 Jan 2007 17:35:04 +0000

When I’m up against a tight deadline, I tend to avoid tasks which could unnecessarily eat up precious time. These tasks aren’t always the most challenging or difficult, but I recognize them as having more than one possible solution which will result in my over-thinking, over-researching and/or over-architecting (aka wasting time.) Time-gobbling task get flagged with a //TODO comment and a quick hack which gets the code immediately operational. Once the stopgap is in place, I move onto other tasks and wait until the best solution comes to me in my sleep, in the shower, while playing racquetball or anywhere other than at the computer.

Most recently, I’ve needed to generate item numbers. Each number needs to be exactly 12 digits in length and unique. I’ve been sitting on this task and a hack (which simply uses the last 12 digits of DateTime.Now.Ticks) for roughly a week now and I’m starting to get anxious because an elegant solution which avoids a database lookup is not coming to me. Maybe I should to shower more often? Maybe I should generate random fake surnames instead? In any case, there are still other tasks to complete and I’m determined to not let item numbers to slow me down.

Don’t Lose Sight Of The Problem

Ben Griswold — Fri, 10 Nov 2006 20:24:34 +0000

You may remember singing There’s a Hole in Bucket when you were younger. This is the song where boys sing the part of Henry, the poor guy who desperately needs to fix his bucket, and girls sing the part of Liza, his wife, who dreams up the fix.

There’s a hole in the bucket, dear Liza, dear Liza,
There’s a hole in the bucket, dear Liza, a hole.

So fix it dear Henry, dear Henry, dear Henry,
So fix it dear Henry, dear Henry, fix it.

With what should I fix it, dear Liza, dear Liza,
With what should I fix it, dear Liza, with what?

…

The song begins with a simple problem. Unfortunately, in the process of patching the hole, Henry encounters issue after issue and, in the end, the hole is virtually impossible to fix. Of course, we see the err of Henry’s ways. He lost sight of the problem because he was sidetracked by other problems which he introduced. We may laugh at Henry, but we fall victim to this same mistake in software development all the time.

A few years back, I spent a lot of time trying to speed up a query which was hitting a single table over a linked server connection. I called in a number of people for help and, though we all learned a lot about SQL optimization in the process, we were working on the wrong problem. I needed to pull data from a table. That’s it! The fact that my query was performing slowly was a completely different problem and a big distraction. I didn’t realize this, however, until someone was smart enough to step back and ask “What is the problem we are trying to solve again?” Once our focus was back on the problem, we reassessed the solution and 30 minutes later we were hitting the table directly and the expected results were coming back quickly.

Of course, we don’t only get off track when coding. The same thing happens in meetings. Though we may start off with the intension of addressing concerns that a primary server is running dangerously low on disk space, the conversation may take any number of twists and turns. In this case, maybe focus shifts to how to get approval to work through a different hardware vendor, how can we speed up the company’s reimbursement program, or what can we do to make sure that the group responsible for maintaining the servers actually maintains the servers. Whatever the case, let’s hope there is somebody in the room willing to ask “What is the problem we are trying to solve again?” If you are lucky, you may actually walk out of the meeting with a fix to the disk space issue.

If you do find yourself down the wrong path, put your focus back on the problem and ask yourself Henry’s question (“With what should I fix it?”) again. A better solution is more likely to come to you without the unnecessary distraction of other problems.

I bet this advice would have helped out that poor old woman who swallowed a fly…

Coding Standards – The Devil Is In The Details

Ben Griswold — Fri, 03 Nov 2006 19:55:30 +0000

A couple of years back, I was tasked with compiling C# coding standards for our development department. To be honest, I wasn’t all that excited about the assignment. Previous attempts had been met with quite a bit of resistance and worthless debate and I wasn’t sure I really wanted to open that can of worms again. After all, I felt that we had built a talented team of developers who saw eye-to-eye on most “technical things” so why bother getting everyone riled up? As you know, there are many legitimate reasons for “getting everyone riled up.” In our case, there were two very good reasons which made my assignment somewhat mandatory:

We had plans to greatly expand the size of our group in the very near future and documented standards would help get the newbies up-to-speed quickly.
Our group’s technical roadmap was becoming more defined (heck, it was taking a turn with SOA) and there were embracing a number of technical advances such as .NET 2.0, Remoting and AJAX and we needed to ensure the existing staff on the same page.

Ultimately, I accepted the challenge and standards were put in place with very little blood shed. Of course, I took a few measure to ensure that mud-slinging and stone-throwing was kept to a minimum.First, I anticipated the pain and I didn’t let it happen. To accomplish this, I guess I was a bit evasive. I didn’t solicit any help or opinions at first. I did endless online searches and I consulted a few books, but I avoided internal roundtable discussions. I also decided to wait until the documentation was rather polished before requesting any feedback. Once I did seek feedback, I kept participant counts low. In fact, only a handful of our technical leaders were invited to the review before distributing before the document was distributed to the entire development group.

Second, it was established early on that there would be difference of opinion and this was okay. Actually, it was almost encouraged, but we all (non-verbally) agreed to keep our egos out of the debate. This ultimately lead to us coming to a common ground or simply opting to “choose our battles” and accept that we wouldn’t always get what we wanted. This, in conjunction with everyone knowing their feedback was valued and respected, kept our conversations on track. Also if a topic got at all heated, we quickly moved onto something else in an effort to stay focused, to keep moving forward and keep everyone happy.

Most importantly, however, we didn’t sweat the small stuff. If you have been responsible for documenting agreed upon standards, you know what I’m talking about. Developers tend to spend just as much time hashing out the small stuff as they do the big stuff. When it comes to establishing your team’s coding guidelines, the devil is in the details. The classic example is code formatting. “Which case are we going to use? Camel or Pascal or both?” “Is Hungarian notation really dead because there is still a lot of merit in using it for form elements?” “Should we prefix private property names with underscores?” “We will use curly braces within our if-else statements even if the conditions are only a single line, right?” “How many spaces are we going to agree to indent? Please assure me that no one indents using spaces! Everyone better be using the Tab key!” There are about a million distracting, time-consuming, worthless arguments which one can have about code formatting (and other similar topics) but they provide little value. These debates can suck the life out of an initiative so beware.

I think I got lucky on my third point. To some extend, our development focus had been rapidly changing over the past few years and the individuals helping to define our standards were now interested in the big picture. Perhaps we felt we had “better things” to discuss or maybe we had all learned from our past and we knew the danger of “the details.” In any case, we concentrate on the big ticket items like namespacing, data access and logging. We traded in the time we would have given to meaningless debates and we put frameworks and templates in place.

Whatever your reason, it is important to have standards. Do yourself a favor. When it comes time to defining your own, avoid the details. Otherwise, prepare for a battle which nobody wins and nothing gets done.

If You Aren’t Making Mistakes…

Ben Griswold — Thu, 02 Nov 2006 03:27:33 +0000

I have heard many endings to this quote over the years. “If you aren’t making mistakes, you aren’t going to learn anything.” “If you aren’t making mistakes, you aren’t living.” “If you aren’t making mistakes, you aren’t taking enough risk.” There may be others. Take your pick. Choose the most appropriate quote for the situation and the individual you are consoling. Or go ahead and make up your your own. How’s about, “If you aren’t making mistakes, the problems aren’t hard enough.” It’s kind of catchy.

I have actually taken a liking to “If you aren’t making mistakes, you aren’t doing anything.” It works for nearly any occasion and it is 100% true. In software development, everyone makes mistakes. So, armed with this knowledge, what do we do about it?

First, we need to learn from your mistakes. No surprise here! Well, the problem is we don’t. We tend to get so focused on fixing our mistakes (and then we get so sidetracked by the praise which follows the amazing fix) that we neglect to put any time or thought into preventing the problem from occurring again. Here’s what I mean:

Web Service X is failing on all servers and it is negatively impacting all users. This is a code red. Fix this or update your resume. After 30 minutes, you identify the issue. Web Service X shares a database with Web Application Y which recently modified and deployed a few stored procedures. The stored procedure changes are causing the web service to continuously fail so you roll back the code and the problem is solved. The fire is out. Everyone is happy, but really, your job isn’t done. It’s time to document the dependency and share the mistake with fellow developers. Perhaps you could discuss in a post mortem meeting. If nothing else, post a note on your monitor which reads, “Web Service X must be updated and deployed with Web Application Y or else…” Or else three months down Web Application Y is going to be deployed and break Web Service X again. Round and round we go.

[ On a cynical tangent: You know you were the one who caused the problem in the first place, right? Want to be hero for a day? Try this experiment. Take down a server, wait for company-wide panic and then bring the server back up. Finally, listen for the whispers which will soon circulate through the halls. "Was the problem solved? Great. Who solved it? Great. They are so great! I don't know what we would do without them!" It's funny, but this type of thing happens all the time. I mean, who can solve a problem faster than the person who causes it? And doesn't everyone forget about the problem's cause once it is solved? Though it may sound silly, the quickest way to save the day is to be the one to ruin it in the first place. ]

Okay. Now we’re learning from our mistakes. (At the very least, we’re writing never-do-this-again warnings to ourselves.) The second thing to do is accept your mistakes. You must truly understand that mistakes come with the a coder’s territory and know that you are going to botch things up every once and a while. The underlying message is don’t be afraid of failure and try to spread this viewpoint to all team members. I know it is especially difficult if you have witnessed (or have been the brunt of) the fingerpointing when it is late in the project lifecycle and things are looking grim, but this is extremely important. You are going to do your best work if you aren’t worried about your next blunder. I’m not saying to throw caution to the wind and start coding with reckless abandon. To the contrary, you must continue to code with a lot of heart and consideration knowing that you are going to live to tell about your next mistake. The best way to become comfortable with your mistakes is to share them with others. Everyone likes a person who can admit their mistakes and poke a little fun at themselves. Here’s a fine example on how to put this to practice:

We hosted a small post-release party for the members of our development team recently. About halfway through the party, we went around the room and openly shared the mistakes which were made along the way. It was comfortable and safe and everyone had a story to share. My favorite story went something like this:

The QA department submitted a defect that our entire user base appeared to be male. Not a single female could be found in the database and the testers correctly deemed this an issue. We looked at the XML posted to us from our vendor. We found that each user’s gender was included in plain text as either “male” or “female.” From this, we knew there should be instances of female users. We then turned to the XML parsing algorithm. The mistake was easy to find since the code read “If the gender value contains M-A-L-E, the user is a male. Otherwise the user is a female.”

It was undisputedly a stupid, yet amusing, mistake.

Coincidentally, the defect was introduced by one of our better coders. This guy single-handedly coded a service which was the project’s foundation. He worked many nights and weekends and did everything in his power to ensure the project would be successful. Without him, we never would have met our deadline and no one could accuse him of “not doing anything.” The best thing is he was still contributing, even at the victory party, by demonstrating what to do about mistakes. You learn from them and you accept them. Eventually you may be fortunate enough to even laugh about them.

Solve Problems With Rubber Ducking

Ben Griswold — Mon, 30 Oct 2006 04:59:40 +0000

What is “Rubber Ducking?” The phrase was made famous by Andrew Hunt and David Thomas in the book The Pragmatic Programmer: From Journeyman to Master. A book, by the way, which is required reading for all coders. In fact, it is time I reread it. You may already be familiar with this term, but in a nutshell, the idea is that simply explaining a problem aloud often helps one come up with a solution on their own. In the words of the Pragmatic Programmer,

Place a rubber duck on your monitor and describe your problems to it. There’s something magical about stating your problems aloud that makes the solution more clear.

This is an effective approach to problem solving. I’ve actually had a duck work by my side for years now. He’s a good, patient, loyal duck. Of course, you don’t need a rubber duck. Some people use email. In the process of meticulously documenting their problem, which will ultimately be shipped to all the smartest people they know looking for help, the solution comes to them. Some people call a colleague into their office, point at the screen and say, “I’d like to get a second pair of eyes on this.” The request for review comes along with a detailed overview of the problem which, in turn, begets an answer to one’s own question. As they say in the book, it’s magical.I stumbled upon an Interview with Hunt and Thomas which tells a bit more about rubber ducking. It’s a quick read and it’s worth a look.

Reading your source code aloud, or explaining it to someone else, has concrete and documented value, whether in a formal setting of code inspections, peer reviews or just chatting with your cube neighbor, said Thomas. “Have you ever done this? You stare at a piece of code for an hour, debug and debug, and finally, in desperation, you pull your friend in from his cubicle. You start to explain the code and how it works, but then â€¦” (smacking his forehead) “Oh, that’s it!”The audience laughed again, and most of them were nodding ruefully. In fact, Thomas said, you can even resort to “rubber-ducking.” “I don’t know why it works, but it works. You put the rubber duck on top of your monitor. Then, when you’re stuck on something, you start explaining what the code does aloud to the duck.” And before you’ve finished the explanation, the solution comes to you. You smack your forehead, and politely thank the duck, he said to general laughter.

Why do I bring this up? I am currently on a 6-week leave of absence from work spending time with my wife and new born son. Prior to leaving the office a few weeks back, I dropped my duck off on a colleague’s desk without any advanced warning that a duck-sitter was needed. I know the sentiment was appreciated, but I’m not positive the significance was understood. As I mentioned earlier, you don’t need a rubber duck. All you need is to willingly share your problems aloud. I was this person’s rubber duck. They always came up with the answers on their own, but not before giving me the opportunity to listen.

I hope my duck is getting an earful right now…

* Update: Previously, I incorrectly credited Hunt and Thomas with coming up with the phrase “Rubber Ducking.” In fact, it was Greg Pugh who coined the term. Thanks to Ed Davies and his considerate comment for addressing my oversight.

Rethink Job Postings

Ben Griswold — Fri, 20 Oct 2006 17:44:39 +0000

Before you submit your next job posting, keep the end result in mind. If you are in the market for talented, interesting people who are accountable for producing quality work, you may wish to give your job listing a second look.

Haacked.com discussed the Art of the Job Post today. The article shares where the great majority of job posters miss the boat and offers tips to get back on track.

The author suggests that one should avoid the standard, monotonous outline of the potential employee’s role and responsibilities. One should not focus solely on what a candidate must provide your company, but, to the contrary, the emphasis should be on what the company has to offer.

A good job ad should not explain what hoops the candidate must jump through to join your company, it should explain why the candidate should even want to jump through those hoops in the first place.

For example, you should not be afraid to cough up information about your company’s personality and culture. After all, a good candidate is going to ask about this anyway.

Sure, many corporations seem like soulless cubicle farms in which workers are seen as mindless drones. But surely not your company, right? So why does your job posting have a tombstone all over it?

You should also “appeal to the vanity” of those seeking employment. Challenge the candidate to show how great they are. As the article states, asking the individual if they are a good problem solver conjures up the desire to prove it.

Again, your job posting should be a request for interesting, talented people — not just those who have methodically pack their resumes with the alphabet soup they think will help them land the offered position. Find these people and it is a win-win for everyone.

In my experience Haacked.com‘s comments are accurate. Most job postings are bland and focus only on experience, skills and responsibilities. Heck, I’ve been involved in the hiring process for a few years now and I’m guilty of using the same cookiecutter job description template as everyone else. Shame on me, right? Well, I will give myself some credit. I do request team players with strong verbal and written communication skills and a willingness to learn. But these are only secondary criterion. First and foremost, I evaluate a candidate’s experience and it is their technical know-how which lands them a phone screening. In the end, however, it’s the “soft skills” which get the individual hired.

There’s a lot to be said about the hiring process. It can be extremely frustrating, but also unbelievably satisfying. As one can imagine, it’s crucial to get off on the right foot so mind the “Art of the Job Post.”

I’m sure there’s more to come on the topic in the future…

Why Don’t We Handle Exceptions

Ben Griswold — Tue, 17 Oct 2006 16:59:00 +0000

Exception handling is extremely important, isn’t it? When it comes to testing, troubleshooting and maintenance it is paramount. Exception handling is definitely highlighted on every developers list of application technical requirements. So, why don’t all applications have proper exception handling? I have a few ideas.

The first and most likely reason is most developers (no matter how experienced) don’t have a good understanding of how to do it. This operation may seem trivial to some, but it actually takes a good amount of attention and care to do correctly. Granted, in many cases it’s perfectly fine to simply wrap the contents of a function with a “generic” try/catch block and merely bubble the exception up to its caller. Great. But what does the caller do with the exception? Nine out of ten times the caller, in turn, will also bubble the exception up (because that’s what the “pattern” does) or it swallows it. Even if a coder uses this bare bones approach, there are usually issues with the implementation. For example, there is a big difference between throw; and throw ex;. The difference is that throw; preserves the original stack trace and throw ex; truncates the stack trace below the method in which the throw ex; call is located. Most of the time, throw ex; is inappropriately. There are many other examples of poor exception handling, but here’s my favorite — the coder does everything “by the book” until it is time to display a error page and a coder reveals the exception details including secure information such as connection strings to the user. Yikes! Not understand proper exception handling can be dangerous.

The second reason is priority and timeline. Exception handling isn’t sexy and, let’s be honest, it doesn’t need to be in place before an application can be deployed. Hence, exception handling is usually pushed to the backburner — along with technical documentation. Only once the application requires future troubleshooting do we feel the pain of the missing “requirement.” Interesting enough, a colleague of mine now waits until his code base is quite stable to implement his error handling. He does this without regard for priority and timeline. He’d prefer to have his application assume unnecessary fatal errors early on it the project lifecycle rather than mask the issues through improper exception handling. All the same, timeline is still a standard developer excuse for lack of error handling.

The third reason is ego. Aren’t we all a little guilty of thinking our code can’t fail? After all, we can’t have a bunch of coders with defeatist-attitudes working on our projects. Without the safety net of exception handling, we are bound to write better code, right? (Of course, this argument doesn’t hold a lot of water since it would promote getting rid of the QA team if we wanted really good code.) I do think ego is a factor though, but I’m not sure to what extent.

That’s my take on exception handling. What do you think?

Manual Code Generation

Ben Griswold — Tue, 17 Oct 2006 00:19:00 +0000

Code generation is not a new concept. It has been around since the first lazy, err, smart coder realized that Hello World was the foundation of Hello World Too. I’m sure they figured they had written the code twice already and the third iteration is undoubtedly around the corner so they felt somewhat obligated to automate the process.

I’ve had the opportunity to see code generation in action. I’ve seen CodeSmith leveraged to the extreme — with a single click, a completely functional three-tiered application could be built before my very eyes. It is like magic. It is super-impressive and I commend anyone willing to put time into a building the code generators because they are awesome. And there are many advantages to auto-generating code:

Code consistency
Stable, tested and bug-free code which “works first time”
Produced very quickly
Easily updatable
Programmers are free to concentrate on the areas of development that deserve their brainpower
Increased productivity
Learning aid — If the generated code is well written and consistent, programmers are more likely to copy the style of this code and learn from it

Does code generation make good sense to me? After all, I use it all the time. (Kind of.) You see, I tend to refactor my code and compile reusable libraries with common functions. I have templates for building custom classes and collection. I hardly ever write a routine without consulting my previous work (or the work of others) and I can’t remember the last time I started a project from scratch. I alway begin with an existing, similar project and then modify it for my needs.

As you can tell, I am a proponent of code reuse. I believe in patterns and I have no dream of reinventing the wheel. With this said, I am not a fan of code generation. Is there something wrong with me? Well, here are the disadvantages to code generation. You decide.

A code generator must be written and tested thoroughly before code can be generated. This task time and effort and it adds some risk since you can’t get the “real” project out the door unless the generator is production-ready.
Code generators really only work for specific applications with specific use cases. Code generators are best suited for admin-type applications which entail no business logic. If your application is nothing but CRUD then code-gen might be right for you.
There will always be some code that needs to be hand-crafted. If the code generator doesn’t allow you to “support” hand-crafted code, you’re in a tough spot.
Most code generators work off of an existing database schema. In most cases, a well formed databases (i.e. specific primary and foreign key names, normalization, etc) is required and generators generally do not cope well with databases that have special, “unique” design features. In addition, I don’t believe business objects should exactly mirror the associated database objects. For these reasons, code generators tend to lead to bad system designs.
Code generation leads to poor performance. This one is obvious, right?
Generated code is difficult to maintain. I should be really clear on this point. Without a firm, working knowledge of the code generation tool itself, the code is difficult to maintain. Unfortunately, there is little guarantee that the original author of the code is going to be the developer slated for maintenance.

It isn’t that I wish to be a modern-day John Henry. Simply, I believe code generators have their place and it’s not in my toolbox (except for really simple cases.)

Understanding the Digital Natives

Ben Griswold — Fri, 22 Sep 2006 05:45:52 +0000

A handful of the 40 coders in my development group are recent college graduates. They have less than two years of professional coding experience under their belts and for this reason alone I consider them juniors. They are all very talented and some day they are going to be absolutely amazing at what they do, but for now they are still just learning the ropes.

I came to this conclusion after working closely with a handful of these developers on a recent project. At first, anything they did which didn’t meet my standards was immediately chalked up to their professional and/or personal immaturity. Let’s face it. I am a seasoned developer. I’ve been around the block and they haven’t. I know best. Well, as it turns out, maybe I just know differently…

Our production deployments typically last well into the night. While “supporting” a release, we drink way too many energy drinks, strike up random conversations and wait for the QA group to sign-off on the deployment. During our last product release, I took the opportunity to give one of the newbie coders a hard time about his work habits. It goes without fail that every time I walk by his office, he has a million browser windows open along with IM, Outlook and, if I’m really lucky, a single instance of Visual Studios. At any time during the day, he can tell me the latest baseball scores or the breaking news on CNN. This (along with all of his silly screen savers, desktop widgets and keyboard shortcuts) I could almost tolerate, but when I found him remotely connected to his home PC and sending personal emails, I just had to wonder about his productivity and I called him on it.

At first he began to lecture me about productivity in the workplace and all the studies which have been done stating that you can only get six solid hours of work out of a developer in an eight hour work day. At this I laughed since most of the time it feels like we’re required to fit 12 hours of coding into a 10 hour day. Once he realized I wasn’t going to bite (and he was most likely digging his own grave) he changed his tune and took another approach. “You see, I’m a Digital Native and you are a Digital Immigrant and our generations do things differently.” Granted, he wasn’t gaining any points by essentially calling me old, but he caught my interest.

You see, my young colleague represents the first generation to grow up with new technology. They have spent their entire lives surrounded by and using computers, email, the Internet, instant messaging, video games, digital music players, cell phones and all the other toys and tools of the digital age. Digital Natives are used to receiving information really fast. They prefer random access and they function best when networked. They thrive on instant gratification and frequent rewards. And they prefer games to “serious” work. They are the Net (N) or Digital (D) Generation. ^{[ 1 ]}

Those of us who were not born into the digital world, but have attempted to adopt most aspects of the new technology are Digital Immigrants. Like all immigrants, Digital Immigrants retain their “accent.” The “digital immigrant accent” can be seen in such things as turning to the Internet for information second rather than first or in reading the manual for a program rather than assuming that the program itself will teach us to use it. There are hundreds of examples of the digital immigrant accent. They include needing to print out a document written on the computer in order to edit it (rather than just editing on the screen) and bringing people physically into your office to see an interesting web site (rather than just sending them the URL.) The example we can all related to is the “Did you get my email?” phone call.

My point is there’s a new breed of developers on the rise as one of them explained to me the other evening. They are “native speakers” of the digital language of computers, video games and the Internet and they think and process information fundamentally differently from then their predecessors. And they function differently too. The next time you think the junior developer’s desktop is cluttered and you think they aren’t focused, please think again. They are simply parallel processing and multi-tasking. Find a way to work with the new generation. Better yet — learn from them.

Reference: 1.Digital Natives, Digital Immigrants by Marc Prensky
Tip: Tune into Adult Swim or the Family Guy to see first hand how Digital Natives like to consume information.

Email Etiquette 101

Ben Griswold — Thu, 21 Sep 2006 04:21:00 +0000

Unquestionably, effective communication is a key ingredient to delivering a successful project. I could rant on and on about avoidable day-to-day issues which exist only because of miscommunication, under-communication or (gasp!) over-communication, but I will save this for another day. Instead, today’s lesson hones in on the primary vehicle for poor communication — email. I am not an expert on the subject, but I do send and receive my fair share of email. I would like to think if everyone adhered to the following guidelines, projects could be delivered with less “drama.”

Do Spell and Grammar Check

This may be my # 1 pet peeve because it is so easily remedied. Nearly all programs provide a spell/grammar checking option so simply enable it. You wouldn’t do a crossword puzzle in pen, would you? We all make mistakes so make sure that proper spelling, grammar and punctuation is used before sending your next message.

Do Read Your Message Before Sending

Spell and grammar checker will bail you out the majority of the time, but it’s still a good idea to proof read a message before it is sent out. It is amazing how easily the context of an email can change due to simple mistakes. (Have you ever accidentally written don’t instead of do? I haven’t. Oops. I mean, I have.) Apart from this, reading your email through the eyes of the recipient will help you send a more effective message and avoid misunderstandings and inappropriate comments. And don’t be afraid to have someone review your message before sending — especially if you are upset with the intended recipient. It’s okay to let an email “sit” for a while until you count to ten.

Do Not Use Abbreviations and Emoticons

In business emails, try not to use abbreviations such as BTW (by the way) and LOL (laugh out loud). This is generally not appropriate. The same goes for emoticons, such as the smiley : ). If you are not sure whether your recipient knows what it means, it is better not to use it.

Do Not Leave Out the Message Thread

There is nothing more frustrating then receiving an email to which you can’t immediately determine the context and you are forced to dig through your inbox (or archives) to get up to speed. This is another “mistake” which is easily corrected. When you reply to an email, always include the complete thread.

Do Not Send Confidential Information

If you aren’t comfortable having an email forwarded to your entire company, don’t send it. Emails have a funny way of landing into the most unlikely person’s inbox at the most inopportune time. A word to the wise: be particularly careful with discriminating comments and jokes. It could cost you your job.

Do Not Attach Unnecessary Files

Compress attachments and only send attachments when they are productive. There’s nothing more infuriating than receiving a message from the System Administrator stating “Your mailbox is over its size limit” just because you’ve been forwarded dozens of 6MB FSDs which could have been replaced with the link to their location in source control.

Do Not Overuse the High Priority Option

If you overuse the high priority option, it will lose its function when you really need it. Moreover, even if a mail has high priority, your message will come across as slightly aggressive if you flag it as ‘high priority’. And we all know the story of the boy who cried wolf…

Do Not Overuse Reply to All

Only use Reply to All if you really need your message to be seen by each person who received the original message. Odds are you will never need to use this option again.

Do Not Request Delivery and Read Receipts

This will almost always annoy your recipient before he or she has even read your message. In fact, it probably annoys them enough that when prompted to send the receipt they will simply cancel the function! If you want to know whether an email was received it is better to politely follow up with the recipient. (Will an article on follow up etiquette be coming soon?)

Do Not Recall a Message

Assume that your message has already been delivered and read. In that case, a recall request would look very silly, wouldn’t it? It is better just to send an email to say that you have made a mistake. This will look much more honest (and call less attention) than trying to recall a message.

Life After Blackberry?

Ben Griswold — Fri, 15 Sep 2006 11:58:00 +0000

“I appreciate the offer, but I simply don’t want one,” I said. “I know it will completely take over my life. I will wind up working around the clock and that’s not healthy. I need to turn work off some time. Truly, thanks, but no thanks…”

As if I had never said a word, a Blackberry was delivered to my office a couple of days later.

At first, I didn’t want to look at it and I definitely didn’t want to touch it. I just let it sit on my desk as if I knew that just one taste would have me coming back for more and more and more. Yes, I knew it was a drug. It was my “crackberry.”

Six months later and I am now an addict. I simply can not live without my Blackberry. I use my Blackberry 24/7 — in my car, in bed at 2:30am, waiting for the elevator, on the can and literally 15 minutes before and 15 minutes after my son was born. In fact, I recently discovered that emails are delivered to the Blackberry Server before the Exchange Server. Now I catch myself, at my computer, working on an email and sadly pulling my vibrating Blackberry from its holster in order to sneak a peek at a new message delivered to the device a mere two seconds before it ultimately pops up before my eyes in Outlook.

I know I have a problem. The majority of the time, however, I am in denial. I have convinced myself that I am now more efficient and effective and I am more accessible than ever! Heck, I was able to address a handful of work-related issues while watching the Padres game with family at Petco Park a few Sundays ago. Talk about non-stop productivity!

Is there life after Blackberry? Yes. It is very exciting and it is often dramatic and it provides no downtime. It is a life where work and play are intermingled. And now that I have had a taste, I’m not sure if I can ever go back to my life before Blackberry.