Entries from September 2006 ↓

Becoming a Better Developer Part 9: How to Criticize a Software Developer Without Getting Punched

There comes a point in every person’s career when we have to offer criticism of someone else’s work. For software developers and managers this can be especially difficult since most programmers view the software they write as an extension of themselves, and take criticism of that software very personally.

We all know how to criticize, but the question is how to criticize well.

Be Specific
The #1 rule of good criticism is be specific.

In Freaknomics, Steven D. Levitt examined phrases in real estate listings that had a positive correlation on sale price (meaning a higher sale price), and ones that had a negative correlation (lower sale price). The results were as follows:

Higher Sale Price
state of the art
move in condition

Lower Sale Price
well maintained
great neighborhood

What you’ll notice is that higher sale prices resulted from being more specific. Tangible, real things like granite, corian, maple, new, outweigh ambiguous, possibly made-up things like fantastic, charming and wonderful.

And so it is with criticism. Telling someone their code is “total crap” is not helpful. Telling them they misspelled two variable names, have several place where they’ve repeated code, and they need error handling in all of their methods is much more helpful. It not only allows them to improve their current code, but perhaps it will help them out in the future, as well. They still may get mad, but that’s up to them.

It certainly takes more time to itemize mistakes, but it’s worth it.

Criticize the Code, Not the Person
If someone writes crappy code, talk about the code, not about the person’s ability to code. If someone doesn’t meet a deadline, talk about how that affected you and what needs to happen in the future, don’t talk about how the person is a complete slacker (at least not the first time you discuss it). Doing so will help keep the conversation less personal.

Be Constructive
Without much effort at all I can give you a list of negative things about Los Angeles: traffic, smog, too many people, and a distinct lack of trees.

I could also give you a list of bad things about the internet: spam, viruses, poorly-designed websites, and pornography. Just because I can point out a ton of negative things doesn’t mean that the internet is not worth your time, and doesn’t mean you shouldn’t live in L.A. For all the negatives there are tons of positives to outweigh them, at least for the 10 million people who live in L.A. County, or the 1 billion people on the internet.

It’s easy to be negative. It’s easy to come into a situation and complain. It’s easy to point out the flaws in everything (have you ever read the comments on Digg or Slashdot?). If you don’t have a suggested solution in mind it’s going to be difficult for people to respect your opinion. Someone who complains often will be ignored rather quickly.

Constructive critisism is helpful; venting just pisses people off. Before you criticize something stop to think if it really matters to you and needs to be improved, and make sure you’re talking to the person who can do something about it.

Open Source Draggable ASP.NET Controls

14 months ago my wife went to China for a week and I found myself with a ton of spare time. So I did what any young, virile male living in Los Angeles would do – I stayed up until 3 am creating custom ASP.NET controls.

14 months ago the only .NET AJAX controls on the market were Dart’s PowerWEB LiveControls, which were pricey, so I figured anything I built dealing with AJAX would be popular. However, I knew the compexity of trying to implement an AJAX textbox, label or panel and, realizing I only had a few evenings on my hands, decided to look for a project I could complete in the time I had available.

During my research I stumbled upon Walter Zorn’s amazing open source DHTML API/Library for manipulating images and layers inside the browser. I quickly decided to wrap his API in a few custom ASP.NET controls, and the Draggable ASP.NET controls were born.

The controls are:

  • Cross-browser. Draggable ASP.NET controls are compatible with IE 4+, Firefox 0.6+, and Netscape 4+
  • Quick. Just drag and drop them on your web form and you’re good to go
  • Simple. They eliminate the need for complex JavaScript
  • Customizable. All properties are configurable at design or run-time, and full source code is available
  • Flexible. Make any control draggable by placing it inside a Draggable ASP.NET Panel
  • Server-side. Designate a Draggable ASP.NET control as a container and drag other controls into it, firing a server-side event

The Source Code
I wrote all code in .NET 1.1 but converted it to 2.0 last weekend. VS.NET 2005 gives a few warnings when compiling the controls because of methods that are now deprecated in 2.0, but everything compiles and works properly. This is release v0.9, but I plan to do a 1.0 release once someone has time to fix and test the compiler warnings.

Binaries Only
The installation package for the v0.9 binaries is available here. It includes an MSI, installation instructions and documentation.

Source Code
The source for the v0.9 Draggable controls is available here.

The source for the Draggable demos is available here. Note: Due to the hard-coded path to the javascript libraries you must run the demos in your web root.

The License
I’m releasing these controls under the Attribution 1.0 License. This means the controls can be used as you please, but you must give attribution. The controls may be modified and distributed in both commercial and non-commercial applications, but the attribution must be made clear in this distribution.

Time Tracking without the Timesheet

I wanted to recommend SlimTimer for anyone who hates tracking their time. The concept is simple enough: create a few tasks, click on a task when you start it, and click on it when you’re finished. The site times your tasks and allows you to run reports on what you’ve done. I’ve used the tool a few times and it’s solid. They even have a sys tray add-in in case you don’t want to keep their pop-up window open.

Check it out if you have some free cycles.

Comments on Testing Attention to Detail

Developer Interview Questions: Testing Attention to Detail generated several comments that I’d like to address.

The first one is “I think that your questions test the trait on a superficial and…formal level…Give the candidate a problem which is prone to off-by-one errors; make sure that, if the proposed solution has the error, the candidate is aware of the possibility of the error and knows how to test. [Secondly, present a] problem with potential “special cases” – something along the lines of writing a function that calculates 1/x, but a little bit more complex, so it will not be that obvious.”

Those are two excellent questions for finding out if someone knows how to see errors in code, which is one kind of attention to detail.

The other kind of attention to detail is equally necessary and if you’re not interviewing for it, you’re hiring bad developers. Corporate development has tons of hoops you have to jump through to have a stable, standardized system. Things like naming conventions, a well-defined source control structure, coding standards, SQL standards, UI standards, etc…

Although unncessary in small projects, these hoops are what allow a group of 20+ developers to produce software with any manner of efficiency. Being able to recognize these hoops, understand them, and follow them all fit into the bucket of “non-code attention to detail,” which is a trait I am looking for when hiring for our team. This is why there aren’t any “find the bug in the code” questions in my list (although I do ask these types of questions in interviews).

Another comment was “These tests won’t show you if a candidate pay [sic] attention to details. They only show that, on that given moment, he was nervous. It is much better to talk to them, and bring this topic during conversation: ‘do you focus on details? are you more interested on general concepts?’ etc. Talking is much better than silly tests.”

Talking is absolutely much better than silly tests, but how can you ensure that someone is telling the truth? Here’s an example of what “talking” might look like:

Q: “Do you write good code?”
A: “Yes”

Q: “Do you show up for work on time?”
A: “Yes”

Q: “Do you focus on details?”
A: “Yes”

You haven’t learned anything from those answers. Most candidates try to give the “right” answer during an interview, which is why you have to ask questions that require knowledge to answer. Asking someone if they pay attention to detail is like asking “Can you write a method in C# that loops recursively through all the controls in a given parent control?” And taking their word for it.

On the “nervous” portion of that comment, I turn to Vince’s reply:

“I just don’t buy it. I need someone who can analyze problems and make decisions under pressure, because during the course of a multi-million dollar software project, pressure situations come up. But mostly, the line of thought bugs me because even though I’ve had plenty of interviews where I’ve been nervous, I’ve always been able to think the interview questions through and reason them out.”

Finally, Alexander said:

“[Question] #1. Ask why the company doesn’t already have a stored procedure in place for the join? Ask for an explanantion of the business process being supported to clarify if an inner join is really necessary. Finally, write the inner join using column numbers instead of names since the company hasn’t been able to normalize their spelling.

[Question] #2. Ask for a copy of all applicable HR documentation detailing the use of the information you’re about to provide. Insinuate that the company is using the hiring process as a cover for the collection of email addresses to sell to spammers.

[Question] #3. Ask for a copy of the company’s code creation procedure manual that documents this process (They do have this stuff written down don’t they?), read it back to the interviewer…”

Whew! Where to begin?

Regarding #1, I would indicate these are brand new tables and that the candidate has been asked to write the stored procedure. I would give the business justification if asked, but would definitely be wary of the candidate’s hubris. Finally, if the candidate used column numbers instead of names I would see it as a red flag. Most single answers won’t get you shown the door, but using column numbers is pretty close.

Regarding #2…Really?!

Regarding #3: Asking for the company’s code creation procedure manual is a great answer. I would take that as a sign of someone who knows about corporate development, and who is asking the right questions.

As a closing example, one of the questions I ask during interviews, since we work with Microsoft technologies, is “Tell me about the Microsoft Application Blocks.”

If someone has never heard of them are they immediately shown the door? No.

If someone has worked with every one of them do they instantly get an offer? No.

No question is an all-or-nothing game. Folks who evaluate people for a living through psychological tests, IQ tests, certification exams, college-entry exams, etc…always include multiple questions on a single topic in order to avoid false positives/negatives. The more data points you have, the more accurate your results. Keep this in mind as you interview.

If anything, this discussion has shown how difficult it is to test for a crucial trait like attention to detail.

Developer Interview Questions: Testing Attention to Detail

In Personality Traits of the Best Software Developers we looked at four key personality traits of the best corporate software developers.

One of the comments, posted by Paul Norrie, raised an important question about interviewing: How can we test for attention to detail?

Attention to Detail
Someone who pays attention to detail stands less of a chance of forgetting to check their code into source control, checking their code into the wrong place, misspelling method, variable, or column names, having poor quality or missing comments, etc…

Here are a few interview questions to get you off in the right direction, realizing you should ask multiple of this type to avoid false negatives:

  • Data Model – Provide a simple, two table data model with two column names spelled slightly differently (e.g., UserKey and UsrKey). Ask the candidate to write an inner join using the misspelled column. Most candidates will notice right away that something is wrong, but if they write the query and match the spellings to the data model you have to give them the benefit of the doubt and assume they didn’t want to offend you by pointing out a mistake. If they write the entire query and spell both columns the same (UserKey and UserKey), you have a problem.

  • Paper Form – Give the candidate a very brief paper form asking for their contact information, but instead of asking for their current address ask only for their previous address. The candidate should raise a question about this. If they don’t, ask them if the address they wrote down is their current or previous address.
  • Scenario – Give the candidate a scenario: you’re developing software at an enterprise software shop. You have all the standard tools: an IDE, database, source control, unit testing suite and bug tracker. Ask the candidate to provide every step in the process of creating a “Hello World!” application and getting it into QA. Note: There are no right or wrong answers to this question, but some commonly missed steps are: checking the code into source control, labeling the code, creating and checking in unit tests, emailing the appropriate person in QA or Change Management to move the code to QA, checking compiled assemblies into source control (some companies don’t perform this step), and creating and checking in documentation (some companies don’t perform this step – try not to work at those companies).
  • Comments – Provide the candidate with a non-trivial function and ask them to write a comment block describing what it does. If at all possible give the candidate a laptop or workstation so they don’t have to write longhand on paper. Misspellings are not the issue here – a succinct, informative description is key. If their comment describes the method line by line that should raise a red flag. A C# sample method I’ve used in the past is:

private void X(Control parent)
Label lbl;

foreach (Control ctl in parent.Controls) {
if ((ctl) is Label) {
lbl = ((Label)(ctl));
if (lbl.CssClass == “error”) {
lbl.CssClass = “formlabel“;
} else if (ctl.Controls.Count > 0) {

If you have other ideas please post them in the comments.

Developing Software by the 15% Rule

I just found this great manifesto written by eKiwi, the developers of screen-scraper.

It’s a cross between a statement of their approach and a client bill of rights. It includes something they call the 15% rule, which, in their blog, they define as:

“Before undertaking a development project we create a statement of work (which acts as a contract and a specification) that outlines what we’ll do, how many hours it will require, and how much it will cost the client. As part of the contract we commit to invest up to the amount of time outlined in the document plus 15%. That is, if the statement of work says that the project will take us 100 hours to complete, we’ll spend up to 115 hours (but no more). As to where-fores and why-tos on how this works, read on.”

Some other highlights:

  • “In any software development project there is an element of risk. Based on our experience, the primary risk we deal with is simply that we won’t create quite what you, as our client, had in mind.”
  • “…the more time we spend on analysis, the more precise the statement of work is…This is a bit of a catch-22 , however, as you may have already surmised. We could spend weeks detailing exactly what the client wants to have built.”
  • “We’re going to be nice to you…Our intent isn’t to nickel-and-dime you, or squeeze every penny out of you that we can. We want you to like us. We’re going to be nice to you. At the same time, we need to do what we can to ensure that our business prospers. That may mean that we need to be a bit hard-nosed about things on occasion.”

New Article: How To Burn $6,540 a Week: Indecision and Software Development

From my new article How To Burn $6,540 a Week: Indecision and Software Development:

“These kinds of decisions come up constantly during development. Let’s say we have five developers working on a project and between them we encounter 10 in a week . If a monkey flipped a coin he’d choose the right answer half the time. Giving the manager the benefit of the doubt, let’s say he chooses correctly 60% of the time. 6 out of 10 times we break even, the other 4 we lose $420, for a total cost of $1,680 per week.

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week.

Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That’s a difference of $6,540 per week.

Give that a few minutes to sink in.”

You can read the full article here.

How To Burn $6,540 a Week: Indecision and Software Development

Indecision is a slow and painful death to both productivity and job satisfaction. A recent survey (pdf) found that three of the six main obstacles people face in performing their jobs are tied to decision making.

The sad part is that indecision is a management strategy for some (quite a few, according to this study which states “90% of Australians work in a negative workplace culture of blame, indecision and conformity.” We can only assume the numbers are similar around the world.)

In software development there are two kinds of indecision: developer and non-developer. Non-developers can be managers, internal users, marketing, or your CEO; whoever has a say in how your software will be built. For the sake of this article we’re going to look at non-developer indecision, and we’re going to refer to it, for ease of readability, as “management indecision.”

How Indecision Kills Productivity
What is the impact of management indecision on software development?

Which Way?

One study examined the disruptions caused by technology and resource failures in the workplace. They grouped the disruptions into two types: simple disruptions, and what they call “agenda benders.” Agenda benders “create a period of uncertainty and indecision, during which any existing plans are suspended; replanning may become difficult if not impossible. [Agenda benders] can, at worst, cause the entire day�s agenda to be abandoned, and at the very least, will leave it seriously bent out of shape.”

The study goes on to say:

“[When an agenda bender strikes] not only does she switch from doing high-priority tasks to filling in time with relative trivia, but she has no idea when her workstation will revive and must replan her day without adequate information. This uncertainty ultimately contributes to her inability to complete the �write specs � plan. Agenda benders appear to arise through a loss or breakdown of essential resources, for a period of significant but unpredictable length. Sometimes the missing resource is a person, e.g., a colleague who cannot be found for a vital meeting.” Or, I would add, information that cannot be obtained in a timely manner.

That being said, the impact of indecision is a potentially serious disruption to the development process due to a number of causes:

  • The tendency for most people to freeze when faced with a question where they don’t have all the necessary information (described in the book How Would You Move Mount Fuji?)
  • The effort it takes to note there’s a gap and come back to it once a decision has been made
  • The mental exhaustion of feeling like you’re building a well-designed application that’s full of holes because no one will fill those holes with decisions

Why Developers Hate Indecision
If you’re a developer you know the frustration of not having the answers you need to keep working. You’ve probably experienced this more than you care to remember:

You start working on a new page, script, design, data model, etc… and realize the spec you’ve been given doesn’t have enough information for you to do your job. You walk over to your manager’s desk in search of an answer but he’s working on another issue and you have to wait.


You trudge back to your cube, realizing your deadline is not budging, but unable to continue your work until you have an answer. Your stress begins to increase and you resort to one of two things: sending an email and sitting on your hands until you get an answer (but looking busy, of course), or making the call yourself and living with the consequences. Either way your productivity is hammered and you’re now feeling the stress of having one more loose end on your mind.

“Surveys frequently rank managerial indecision as one of the top office torments, even above issues like low pay.” (source)

So why is it that no ones seems to make decisions?

Most of the time your question is a lower priority than the other tasks on a manager’s plate. Other times it’s due to corporate politics; no one wants to be responsible for a bad decision on a UI that doesn’t work for the Accounting team simply because he made a hasty decision and didn’t ask the accounting team what they wanted.

I genuinely believe that the majority or managers, internal users and yes, even CEOs, are not intentionally trying to see how much stress you can take before your head implodes. For better or worse, this is just one of the realities of working in a corporate environment.

Why Managers Should Hate Indecision: The True Cost
Summary so far: indecision is bad. It’s so bad, in fact, I maintain that most of the time a poor decision is better than no decision at all. This doesn’t hold true when launching nuclear missiles, performing heart surgery, or making software architecture decisions, but in most common software development scenarios it does. Let’s look at an example:

Developer: “The spec doesn’t say if we should show all products on this page, or only enabled products. What should I do?”

Manager: “Let’s call a meeting. We’ll get the four key people together, discuss it and come up with an answer. The soonest everyone can meet is next week.”

Developer: “But this is the core of the page. I need a decision to finish it.”

Manager: “Well, then, put it on hold and move on to something else.”

Now let’s examine the impact this has on the developer’s productivity and, ultimately, cost.

[Note: I know this next section will elicit a slew of comments like “Developers don’t make that much/little,” or “It would never take 2 hours to shift to another task.” In the end I decided that a practical example, even one that requires some subjectivity, is such a helpful part of this discussion that it’s worth including.]

To begin, the average salary of a Mid-level software developer in Los Angeles is $88,750 (Robert Half’s 2006 Salary Guide). With burden and overhead of 65% (this includes your benefits, employer’s portion of your social security and unemployment, the lights over your head, your phone, computer, software licenses and parking space) it comes out to around $146k, or just over $70 per hour (based on 2080 hours per year). A company employing a software developer making $88,750 pays approximately $70 for each hour they work, are sick, or on paid vacation.

Price Tag

In our example above, the first thing the developer has to do is participate in the meeting. Elapsed time: 1 hour (more if she has to prepare for the meeting). Cost: $70.

Next, she has to stop what she’s doing, add this to her to do list and come back to it in a week. Elapsed time: 2 hours to shift gears into another task then try to remember what she was doing when she comes back. Cost: $140.

After returning to the task after a week the developer is more likely to introduce additional bugs because of forgotten loose ends and a lack of familiarity with the code. Since “bug rates” per line of code varies widely this is difficult to measure. Let’s say that on an average day five bugs would show up in QA, but due to the disjointed nature of her development she introduces two additional bugs. The average cost to fix a bug based on this case study (careful, it’s a PDF) is $200. 2 x $200 = Cost: $400.

Finally, she now has another item cluttering her task list, she’s frustrated she can’t complete her work, she’s lost respect for her manager because he won’t make a decision, frustrated with her company for having to gather four people to decide how a single screen works, and she’s concerned she’s not going to remember all the details when she has to come back to the page in a week. Due to stress her productivity degrades 10% for the next 2 days. 16 hours x .10 = 1.6 hours = Cost: $112.

Total loss due to indecision: $70 + $140 + $400 + $112 = Total Cost: $822.

But wait, there are two other alternatives to this story.

One is that the manager makes a decision, and it’s the right one. In this case no additional time or money is wasted. Cost: $0.

The other alternative is that the manager makes the wrong decision. He sends an email to the parties involved indicating how they’ve decided to proceed, and finds out they screwed up. The developer has to go back and re-work the page after she’s completed it. Elapsed time: difficult to know, but assuming it’s a standard page we’re safe with an estimate of 6 hours. Cost: $420.

“Making a decision is a clear winner!” you think. But it gets worse.

These kinds of decisions come up constantly during development. Let’s say we have five developers working on a project and between them we encounter 10 in a week . If a monkey flipped a coin he’d choose the right answer half the time. Giving the manager the benefit of the doubt, let’s say he chooses correctly 60% of the time. 6 out of 10 times we break even, the other 4 we lose $420, for a total cost of $1,680 per week.

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week.

Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That’s a difference of $6,540 per week.

One approach will cost you almost five times as much as the other. Give that a few minutes to sink in.

Trying to Fix Things
Now that we’ve likened indecision to kicking puppies, terrorism and weapons of mass destruction, we’ve decided it’s bad for developers and for the company, and we’ve blamed everyone but the developer, what can someone do to move things along when the brakes are locked?

Here are three alternatives:

  • Make it easy for someone to make the decision
  • “Ambush” the decision makers
  • Force a decision

Making it Easy
We can blame the managers all we want, but the bottom line is that leading a team is hard. As a former manager (who’s back in development by choice), the most common task I performed was making fast decisions with incomplete information. The not very surprising point is that the exact same situation that exhausts developers and kills productivity is the most difficult job of a manager, and the easiest to screw up.


The one thing I found most helpful when forced to make decisions without adequate information was to hear problems and solutions.

Here’s what I never wanted to hear from one of my developers: “Oh my gosh, we didn’t think that people would want to view the results on the blah blah page and now we don’t know what to do. Aaaah! We’re all gonna die!”

Here’s what I wanted to hear: “We didn’t think that people would want to view the results on the blah blah page. At this point we have two options: add the results grid, which is the right way to do it, and will take 2 days, or hack in a temporary table which will take 4 hours. Based on the schedule and where we are with out other tasks I think we should .”

What did the second developer just do? He gave me our best options. He turned this problem into a decision-making process, not a fact finding mission where I had to do recon to figure out the 10 possible approaches. Right away we could discuss pros and cons and make a decision quickly instead of wasting time back at the starting line. In this scenario I would likely suggest additional options, but starting with a base of 2 or 3 is a fabulous head start over the first developer, and makes me more likely to take the few minutes required to make the decision, rather than the 20 minutes needed for the first developer’s approach.

“Ambushing” the Decision Makers
This one is simple; if you need three people to make a decision, find out if they’re going to be in the same place at the same time and drop by. Or, better yet, have one of them walk with you to find the other two. Creating an impromptu meeting will only work with people who have serious buy-in to see your work succeed, or who are close to you in the org chart.

One other way is to try the ol‘ “drop by one and call the other” trick (this works best when you only need two people’s agreement). There’s no rule that specifies you have to wait until everyone’s in a meeting to make a decision (although this is likely the culture if you work at a big company). There are significant limitations to this approach, however, such as a lack of thorough discussion, visual aids, or a white board. If the topic is complex you are likely to receive blank stares and a look that says “I’ll see you at our meeting next week.”

Forcing a Decision
The third tool I’ve found useful is to force a decision. The phrase “We have to make a decision now or we’re going to lose x hours of time.” carries some weight with decision makers. Sure, they may put you off, but make a note that you said this and mention it again (as tactfully as possible) once the damage is done. Do this enough and someone may actually start listening to you.

Wrong Turn OK

It’s possible no one will listen to you, even after repeated warnings. In this case you have one of two choices: escalate the problem to your manager, your manager’s manager, the CEO, or whoever you think can address it, or think long and hard about how much your company really wants its software projects to succeed. If nothing changes after your best efforts, then you have little choice but to keep fighting, accept it, or move on.

The other way to force a decision is to make the decision yourself and do the work. People are less likely to change something that’s already been written. This is a back-handed way of getting things done, but it both makes your point and accomplishes something during the time you’re waiting. As with the other approaches, use this one with caution or you may find yourself pissing off the wrong people.

The Wrap Up
Indecision hurts productivity, job satisfaction, and the bottom line, and eliminating it should be on everyone’s agenda. Managers will likely be motivated by cost and morale; developers by the desire to meet their deadlines and avoid frustration.

Either way, we’re in the same boat. Hopefully someone will decide to steer.

Thanks to Mike Taber for reading a draft of this article.