Yes, I'm very aware of how it generally comes to pass that companies ask for heroic efforts from individual employees. However there is a feedback loop here. A company that pushes employees to heroic efforts has something broken about their estimation process. But conversely if employees really don't know whether they can do what they try to do, then I guarantee that they will regularly fail. Which will lead to a lot of uncertainty and make accurate estimation impossible. And to complete the scenario, most people burn out fairly quickly from heroics. (Programmers are particularly likely to be demotivated by pressure to be heroic.) Which means that if you're requiring heroics, then you'll quickly wind up with a burned out team and all ofthe attending problems that come with that as well.

In short heroics are both a cause and effect of organizational problems. Which makes heroics a red flag to watch out for.

Going to your made up example, obviously your "bad" problem is bad. But your "good" problem is also bad. If the whole spec was "speed it up by 10%", that's a bad project to commit someone to. Perhaps it can't be sped up by 10% at all. Or perhaps it can but that programmer won't be the one to do it. Or perhaps it can be sped up in 20 minutes after you realize that it isn't using an index. A far better project would be, "Spend up to a week studing how to speed up search." Another good project would be, "Spend a week to do change X that we think would speed up search by 10%".

Why are those versions better? Well first, with both it is fairly easy to figure out where to start. Second, both make demands on programmer effort that are estimatable up front so that programmers can give you feedback on whether your demands are reasonable. Thirdly other people can be given clear messages about when to expect improvements that they need.

About whether I understand you, I am quite certain that I don't. You are throwing around the word "accomplishment", but I don't know when you feel a sense of accomplishment in doing something, and when you don't. And I'm painfully aware that different people feel a sense of accomplishment about very different things. (BTW there is a certain irony that you'd respond to a post titled, Well, what do YOU mean by accomplishment? with a response where you say, assuming you understand what I mean by accomplishment... Um, in fact I probably don't...)

About reporting. You might find reporting (at least as it is for my job) more interesting than you think. People often ask for reports that are not going to happen in a reasonable time frame, I have to explain that to them. People often ask for reports that won't actually solve the question that they want to solve, and I often have to work with them to define a report that does. People often ask for a report without realizing that someone they don't work closely with already has the answers they want, and I get to hook them up. And given that I'm in so many discussions, I often wind up pointing out, "You know, it wouldn't be hard for me to give you numbers for _____, which would probably help you a lot." Plus a large fraction of the questions that people want to answer are of the form, "Why do the numbers look like ____?" Which puts me close to business problems in discussion with people whose responsibility is to address those problems. If I have any ideas about why that happened or what to do about them, they are all ears.

There is a lot more to the job than just producing reports that someone else has specified.

Cheers,
Ben

PS FYI, I recognized the author's name when I saw the article. That was part of why I stopped on that article, even though I'm not a big fan of CMM.

He was discussing how agile maps to CMM. I took it more as a way to use CMM, which has some executive-level acceptance, to justify or explain agile.

Yup.

Yes, I'm very aware of how it generally comes to pass that companies ask for heroic efforts from individual employees.

You're focusing on the time aspect of "heroic efforts". I completely agree that heroic time commitments are a huge red flag. In fact the article supports something I said earlier in (I believe) this thread: Most programming work does not require genius. Yes, the cutting-edge stuff Todd described probably does.

I believe you've said it before, but I don't think you said it in this thread.

About heroism, it isn't just heroic time efforts that are bad. It is also bad (albeit for different reasons) to depend on someone having a brilliant flash of insight to be able to get a project done. It is great to have someone have a brilliant flash of insight and then start a project. It is great for a project to be simplified by a brilliant flash of insight. But it is bad to depend on that.

But your "good" problem is also bad. If the whole spec was "speed it up by 10%", that's a bad project to commit someone to. Perhaps it can't be sped up by 10% at all.

You mean it can't be done with new code on the existing hardware, right? Some problems can be solved by throwing hardware at it. What if you're at a small company with a single DB server that's got 2GB of ram in it. How much does another 2GB cost? What does one week of programmer salary cost?

I didn't mean "with new code on the existing hardware". I did mean "at acceptable cost".

For instance at my job, search is a major technical problem. But the easy bullets have mostly been fired. For instance I believe that you aren't going to improve our hardware without spending 5 or 6 figures on it.

There are a few bullets left. There is a caching improvement scheduled that will let us scale another 50% or so. (The primary concern is not time users spend doing a search, it is how many concurrent users we can support without melting down.) And we're about to upgrade our database to 10G, and there is a real possibility that we'll be able to find an easy improvement or two after doing so. Plus we're scheduling hardware improvements, I think for the fall.

While you were posing a hypothetical question, I'm giving answers based on a very real example which I know a fair amount about.

That's actually a good example of what I mean when I say I'm interested in giving users what they need. Programmers want to write code. IT directors want to develop systems. Operatoins people want solutions. Sometimes the best solution doesn't involve IT.

Sometimes the best solution requires all groups to cooperate. That's certainly been the case with search for us.

BTW there is a certain irony that you'd respond to a post titled, Well, what do YOU mean by accomplishment? with a response where you say, assuming you understand what I mean by accomplishment...

That followed four paragraphs of explaining what I meant. Perhaps I should have written, "Assuming you now understand ..."

That was a bad assumption. I feel no closer than I did before to knowing when you will or will not feel a sense of accomplishment.

But let's leave that point. It isn't important.

Cheers,
Ben

And even then I weaseled with "probably a sign".

Yes, I know there are times when it makes sense to code for a long time before running anything. I've done so myself. But I don't do so as a rule, and consider it a red flag if someone does do so as a rule.

I should also note that the programs where I've felt a need to develop that way have generally worked very well, but with a density of "interesting" that makes it very good that they do so.

Cheers,
Ben