Fog Creek Software
Discussion Board




Over the top?

I was reading Joel's note about the release of FogBUGZ and how it doesn't include performance metric reports because Joel feels like the end result is to "antagonize programmers."

First off, I tend to agree with Joel about how performance metrics are a crutch and are routinely abused by management. I think that metrics like this are pointless for the very reason he gives.

However....His announcement seemed to strike me as a tad arrogant. I mean, it's one thing to say we aren't going to implement this feature because nobody would use it, its not cost effective for us, etc, but it's another thing to say "we're not going to give you this feature because we know better than you how to develop software. You shouldn't be doing this, so we aren't going to let you. We are saving you from yourself."

I dunno....If I were in Joel's shoes I would probably do the same thing, but there was just something in his announcement that hit a nerve.  This is a bad analogy, but it seems somewhat similiar if I were developing a news reader program and I disallowed the downloading of attachments from any sex newsgroups because I find pornography offensive. I'm forcing my viewpoints on my users. I know, bad analogy but I hope my point comes across.

Anyway, I'm ambivalent because I agree with Joel on software development issues about 99% of the time anyway. Just food for thought.

Mark Hoffman
Monday, November 04, 2002

I was very impressed with FogBugz.  Very impressed.  The breadth and depth of the tool seems like an excellent value.  We'll take a look at it once we get some breathing space.

As for performance metrics...  Given the nature of bugs, and the division of labor among developers, I would think that metrics would be very difficult to calibrate.  Not all bugs and development effort are created equal.  Some tasks are much more difficult than others.

Nat Ersoz
Monday, November 04, 2002

I was interested to see how people would respond to that.  You're not buying just a program, but a methodology.  So you're paying them to exercise a certain amount of judgement.  To make a tool that will actually help you.

In some cases it would be arrogant, but I don't see a use of this feature other than to beat up on individual programmers. Are there any better uses?

Anyway, it's good when you can seriously claim that an absence is a feature. 

anon
Monday, November 04, 2002

reminds of the original "The Fog Creek Promise" , which has been toned down now.

Prakash S
Monday, November 04, 2002

I thought it was both a smart, and a bold, move.

Joel is right that tracking of individual performance would lead to poor process.

Yet legions of "business analysts" and "UI experts" would have told him that customers should be able to do that if they so wished.

To resist what would seem like just another feature is the mark of an artist, just as visual artists know when to leave white space.

Must be a manager
Tuesday, November 05, 2002

Prakash, what was the original Fog Creek Promise?

Captain Nuss
Tuesday, November 05, 2002

I agree with Joel about the abuse and ineffectiveness of using performance metrics in reviews, but how then do you hold programmers accountable for the code they produce?

Brian
Tuesday, November 05, 2002

Joel is right about leaving out performance metrics.  Although it might seem a little arrogant at first, I think it's a very good business decision.

Joel doesn't want his software to have a reputation in the industry as a tool that nobody uses.

Andy Shyne
Tuesday, November 05, 2002

I think that Joel is trying to uphold the truth about software development.  Sometimes accuracy can't help sounding arrogant.  It may make Joel seem like a know-it-all, but I think he has positive motivations.  And, for me, that's what counts.

Brent P. Newhall
Tuesday, November 05, 2002

Excellent thread.  At my company, we face a similar "ethics" issue.  We produce project management software, and sell heavily based on the ability to quantitatively measure the performance of a project manager.  Is this right?

I can live with it, for the following reasons:

- Many companies do not abuse it.  They go by the principle that more information is always good and that it all needs to be taken with a grain of salt.

- Truth be known, some companies use the metrics to lay off people who they wanted gone for other reasons.  i.e., the metrics were a subsitute for high-priced "management consulting".

- The metrics provide useful information on project profitability that can help project managers trim the fat from project timelines.

- Companies that use the metrics to can good people are going to be hurting.  If they're this stupid, they wouldn't need metrics to get into trouble, they would find another way to screw stuff up.

Of course, metrics, by definition, can't answer questions about intangibles.  Most businesses are "stateful", not "stateless".  The intangibles matter.

All in all though, like Mark, I'm ambivalent.

Bill Carlson
Tuesday, November 05, 2002

anon said: "I don't see a use of this feature other than to beat up on individual programmers."

Since my job title (I think I've got one of those) is a euphemism for "software department," I'm pretty much responsible for any software bug that goes out the door.

Ah, the joys of small companies! Actually, I do like it here a lot. I get a lot more variety than anywhere else I've worked.

Steve Wheeler
Tuesday, November 05, 2002

The only person at one client of mine - who have a 150+ person in-house development team - who wanted "objective metrics" from the source control system was the HR manager, who wanted to second guess line managers about who their good staff are.  It's worth noting the HR manager has no real experience in managing developers (in fact, no line management experience at all), so you can imagine what a debacle that would be: promotion by LOC.

Rodger Donaldson
Tuesday, November 05, 2002

"At my company, we face a similar "ethics" issue.  We produce project management software, and sell heavily based on the ability to quantitatively measure the performance of a project manager.  Is this right?"

Do you eat your own dog food?

http://www.joelonsoftware.com/articles/fog0000000012.html

BC
Tuesday, November 05, 2002

Hmm. I  find myself torn on this issue. While it's easy to claim that you've designed your software to prmote best practice, at the end of the day, surely your software should do what your client wish?

For example, taking a problem from my field (ish) I would modify Dreamweaver to not be ABLE to produce non-standards compliant code.

But some people need to be able to. I expect that some of your customers would like to be able to use this tool to measure programmer performance (however inaccurately).

I think that this crosses the line between arrogance and sensible design. I might get shot down for that opinion ( though I hope not, the level of debate around here tends toward the sensible), but I think at the end of the day, you shouldn't lose track of what (a) client(/s) want...

Andrew Cherry
Tuesday, November 05, 2002

Andrew,

<quote>
But some people need to be able to. I expect that some of your customers would like to be able to use this tool to measure programmer performance (however inaccurately).
</quote>

Think of it this way. I am a programmer. I like Joel's website. I think my team could do with a bug tracking system.

I am about to tell my boss about it when I find out it has the ability to keep performance measurements. Tell my boss who is fixing the most bugs - that kind of thing. Now, I have no interest in that feature. I just want a nice, usable system that keeps track of bugs and whether or not they have been fixed.

Now, will that feature detract from my recommendation to my manager? Definitely. Maybe my manager won't use that feature. But there's good odds he will. And then I will either:

a) Stop using the bug tracking system
or
b) Use it differently to make the reports come out making me look good...

To illustrate my point, I have been in companies where teams were basically rebuked for having too many open tasks (ie too much 'unfinished work'). Noone thought about whether that was a sensible measurement to take. Instead, our team spent hours of work combining tasks (taking 4 or so tasks, and combining them to make 1) to make the stats better. Productive output for that time - nothing.

I would not want FogBUGZ to be used along the same lines - because if it was, the most likely scenario will be wasted time (in 'manipulating' the stats) or not using FogBUGZ.

Just some thoughts. ;-)

Matthew Wills
Tuesday, November 05, 2002

BC asked if we "eat our own dog food".  We don't.  There are features in our product that do not apply to our business.  Primarily, we sell to architecture firms, where metrics make some sense.  If two project managers both design a 5000 sq ft. McDonalds on a flat, one acre lot with similar zoning and traffic issues and one is 150% of budget and another is 75% of budget, it can tell you something.  You hardly ever see "apples to apples" comparisons like this in software.

Bill Carlson
Tuesday, November 05, 2002

Andrew

> surely your software should do what your client wish?

The bottom line is that customers, like users, do not always know what they want at the detail level. At the top level, they want products that help their work and their business. Joel's giving them that.

> I expect that some of your customers would like to be able to use this tool to measure programmer performance

Customers who are desperate for that can probably find some other product. That's a decision they have to make.

Must be a manager
Wednesday, November 06, 2002

*  Recent Topics

*  Fog Creek Home