It’s really worth reading the Michael O'Church essay that the article links to in its conclusion as well.
(note that there are hard deadlines/estimates in the world, as with satellite launches or working with other companies. that being said…)
I think a useful question is: “Why are deadlines and estimates useful, at all?”
If you’re a manager, there might be some value in being able to say “I think this project will take this long, how does that square with the rest of the business/marketing drives/etc.?”
At the same time, especially for startups with low traction, you’re basically on whatever weird schedule occurs–“when it’s done” as they say in the game dev biz (I had a CEO grimace when I mentioned this for a project…year and a half later, still hasn’t sold the finished project in question, so I don’t think I was incorrect).
People like estimates because it makes them feel like they’re in control and that they’re safe and that the inherently unpredictable howling vortex of crazy that is business isn’t about to sunder their fragile organization. And that’s fine. The problem comes when any developer with half a brain and a little perspective realizes that that is the case, and that meeting that objective has little or no relation to any honest time estimate required to finish a task.
If you give an engineer an impossible task on a tight deadline, they’ll probably deliver something. Something really weird and maladjusted to match the constraints they’ve been given (cut corners, etc.), but something nonetheless. If you give them four times the amount of time needed for a task, they’ll take up all the available time.
It’s best, in my experience, to give a “hey, we need a prototype of this project soon, and then we’ll re-evaluate and schedule later”. Thus, you remove the time pressure on the engineer (after the prototype, you’ve got plenty of time), you signal that they can cut corners (“because prototype”), and you promise them they won’t get stuck on long, slow grind of a project (which absolutely will happen if too much time is allotted).
It’s also super super disheartening to bust ass to deliver something to a timetable, only to discover that a) there’s more yet to do and b) nobody is using it. :(
It’s really worth reading the Michael O'Church essay that the article links to in its conclusion as well.
It’s Michael O. Church. O is my middle initial. Anyway, I’m glad that you liked the article.
People like estimates because it makes them feel like they’re in control and that they’re safe and that the inherently unpredictable howling vortex of crazy that is business isn’t about to sunder their fragile organization.
Yes, this.
On the other side, I don’t like giving estimates for the same reason that I don’t like using Agile products where I’m supposed to give daily indications of work progress in exchange for absolutely nothing. Doing that puts me at risk of being dragged into someone else’s chaos. I like to create local order, for a start, and build out from there, which means not taking in a bunch of incoherent garbage inbound traffic.
Exchange of information is always a negotiation. Here’s my policy: if you’re a manager and want to know where I am or how long something is taking, I’ll tell you, but you have to give me something in return. First, I have a right to know why you’re asking me. What decisions is this information leading into? If you’re not willing to tell me that, then I’m not giving anything up, because how am I supposed to trust that the information will be used in my favor and not against me? Second, I expect that whatever I say will be trusted and taken seriously (that doesn’t mean that I’ll always “win”, but if I’m treated as not a credible source, then why am I giving anything up?) and that I have the right to end the conversation at any time, which means that I have the right to say. Don’t play by these rules, and you’ll get nothing out of me, because unlike the clueless software engineers who like open-plan offices and Scrum, I’m not an idiot who gives important information up if there isn’t mutual benefit in doing so.
If someone views me as a “resource” to be jerked around, then I’m not going to give a high quality of information. I’m going to protect what I know, in order to maximize the chance that I’m not jerked around (or, at least, jerked around on to things that I see a benefit in doing). On the other hand, if this is someone who genuinely wants me and my projects to succeed and is just looking to have a discussion in light of what he knows that I don’t (and he’s willing to share this information) then we can talk. If it sounds like I espouse a policy of always being cagey with management (or treating every exchange as a negotiation to “get something” out of) then that’s not what I’m saying at all. I just hate “Agile” because I don’t like being forced to give anything up for free. I will share information when I perceive a mutual benefit.
Asking for an “estimate” is, despite the soft nature of the word, always some kind of power play. It can be a way of saying, “I have the power to fuck with you if I don’t like how long things are taking” or, more to the point, “I don’t trust you to manage your own time”. Or it can just be, “I want to see if you give up information for free, without me even telling you why I’m making this request”. It’s like when Dr. House asked Wilson for increasing amounts of money (that he never intended to pay back) just to see where his “line” was. This is something that business guys understand innately (they’re wise enough to people to know when they’re in a negotiation) and programmers generally don’t. Hence, that Agile garbage.
In all seriousness, I don’t think that I am. I’m willing to voice opinions that are so dark and negative that they’re not socially acceptable, but I’m not this brooding, unhappy person. I’m realistic and skeptical and not unwilling to go into dark places, but it’s not like I’m chronically (or even often) miserable..
What happened?
Years of hard-won experience. I’ve seen bad decisions implemented, companies fail, and the overwhelming conclusion I reach is that the people in power don’t learn a thing. That’s bad enough anywhere, but it’s even worse in software where the people on the bottom think that they’re going to be big-company CEOs.
I was talking to a recruiter, at one point, and she said that even though she found the “Where do you see yourself in 5 years?” question to be trite, she asked it anyway because a majority of candidates said “CEO” (and that was a wrong answer). See, I have an objectively better chance of it than these bozos, and I recognize that there’s a 0.000% chance of me being a big-company CEO in 5 years. So I’d much rather focus on making things better for a large number of people than step back and let corporate loyalty loot the world because of a misguided belief that I’ll be one of them in 5 years.
Ah, that makes a lot of sense. Thanks for the explanation.
How do you go about “making things better for a large number of people”?
I kinda wanted to go down that route, but spending enough time on the internet and news has robbed me of my faith in any basic sort of respect for the common man.
It’s really worth reading the Michael O'Church essay that the article links to in its conclusion as well.
(note that there are hard deadlines/estimates in the world, as with satellite launches or working with other companies. that being said…)
I think a useful question is: “Why are deadlines and estimates useful, at all?”
If you’re a manager, there might be some value in being able to say “I think this project will take this long, how does that square with the rest of the business/marketing drives/etc.?”
At the same time, especially for startups with low traction, you’re basically on whatever weird schedule occurs–“when it’s done” as they say in the game dev biz (I had a CEO grimace when I mentioned this for a project…year and a half later, still hasn’t sold the finished project in question, so I don’t think I was incorrect).
People like estimates because it makes them feel like they’re in control and that they’re safe and that the inherently unpredictable howling vortex of crazy that is business isn’t about to sunder their fragile organization. And that’s fine. The problem comes when any developer with half a brain and a little perspective realizes that that is the case, and that meeting that objective has little or no relation to any honest time estimate required to finish a task.
If you give an engineer an impossible task on a tight deadline, they’ll probably deliver something. Something really weird and maladjusted to match the constraints they’ve been given (cut corners, etc.), but something nonetheless. If you give them four times the amount of time needed for a task, they’ll take up all the available time.
It’s best, in my experience, to give a “hey, we need a prototype of this project soon, and then we’ll re-evaluate and schedule later”. Thus, you remove the time pressure on the engineer (after the prototype, you’ve got plenty of time), you signal that they can cut corners (“because prototype”), and you promise them they won’t get stuck on long, slow grind of a project (which absolutely will happen if too much time is allotted).
It’s also super super disheartening to bust ass to deliver something to a timetable, only to discover that a) there’s more yet to do and b) nobody is using it. :(
It’s Michael O. Church. O is my middle initial. Anyway, I’m glad that you liked the article.
Yes, this.
On the other side, I don’t like giving estimates for the same reason that I don’t like using Agile products where I’m supposed to give daily indications of work progress in exchange for absolutely nothing. Doing that puts me at risk of being dragged into someone else’s chaos. I like to create local order, for a start, and build out from there, which means not taking in a bunch of incoherent garbage inbound traffic.
Exchange of information is always a negotiation. Here’s my policy: if you’re a manager and want to know where I am or how long something is taking, I’ll tell you, but you have to give me something in return. First, I have a right to know why you’re asking me. What decisions is this information leading into? If you’re not willing to tell me that, then I’m not giving anything up, because how am I supposed to trust that the information will be used in my favor and not against me? Second, I expect that whatever I say will be trusted and taken seriously (that doesn’t mean that I’ll always “win”, but if I’m treated as not a credible source, then why am I giving anything up?) and that I have the right to end the conversation at any time, which means that I have the right to say. Don’t play by these rules, and you’ll get nothing out of me, because unlike the clueless software engineers who like open-plan offices and Scrum, I’m not an idiot who gives important information up if there isn’t mutual benefit in doing so.
If someone views me as a “resource” to be jerked around, then I’m not going to give a high quality of information. I’m going to protect what I know, in order to maximize the chance that I’m not jerked around (or, at least, jerked around on to things that I see a benefit in doing). On the other hand, if this is someone who genuinely wants me and my projects to succeed and is just looking to have a discussion in light of what he knows that I don’t (and he’s willing to share this information) then we can talk. If it sounds like I espouse a policy of always being cagey with management (or treating every exchange as a negotiation to “get something” out of) then that’s not what I’m saying at all. I just hate “Agile” because I don’t like being forced to give anything up for free. I will share information when I perceive a mutual benefit.
Asking for an “estimate” is, despite the soft nature of the word, always some kind of power play. It can be a way of saying, “I have the power to fuck with you if I don’t like how long things are taking” or, more to the point, “I don’t trust you to manage your own time”. Or it can just be, “I want to see if you give up information for free, without me even telling you why I’m making this request”. It’s like when Dr. House asked Wilson for increasing amounts of money (that he never intended to pay back) just to see where his “line” was. This is something that business guys understand innately (they’re wise enough to people to know when they’re in a negotiation) and programmers generally don’t. Hence, that Agile garbage.
You are one bitter motherfucker. What happened?
(good reply otherwise, thank you!)
Um, thanks?
In all seriousness, I don’t think that I am. I’m willing to voice opinions that are so dark and negative that they’re not socially acceptable, but I’m not this brooding, unhappy person. I’m realistic and skeptical and not unwilling to go into dark places, but it’s not like I’m chronically (or even often) miserable..
Years of hard-won experience. I’ve seen bad decisions implemented, companies fail, and the overwhelming conclusion I reach is that the people in power don’t learn a thing. That’s bad enough anywhere, but it’s even worse in software where the people on the bottom think that they’re going to be big-company CEOs.
I was talking to a recruiter, at one point, and she said that even though she found the “Where do you see yourself in 5 years?” question to be trite, she asked it anyway because a majority of candidates said “CEO” (and that was a wrong answer). See, I have an objectively better chance of it than these bozos, and I recognize that there’s a 0.000% chance of me being a big-company CEO in 5 years. So I’d much rather focus on making things better for a large number of people than step back and let corporate loyalty loot the world because of a misguided belief that I’ll be one of them in 5 years.
Ah, that makes a lot of sense. Thanks for the explanation.
How do you go about “making things better for a large number of people”?
I kinda wanted to go down that route, but spending enough time on the internet and news has robbed me of my faith in any basic sort of respect for the common man.