51–60 of 66 posts
Really. Compare film scheduling and construction scheduling, which are well developed disciplines. That's because, in those industries, there's paid overtime, and at rates higher than straight time. Thus, "crunches" caused by overoptimistic scheduling add labor costs, which come right out of the company's profit.
This forces scheduling discipline on management. There's a tendency to overestimate, rather than underestimate.
I've been developing for 30 years. When asked for an estimate I spend time thinking about it and then when I come up with a number I multiply it by 3. Usually this works but sometimes I can be off. My typical process is to score stuff from "totally get it" to "don't have it all in my head". I then guess on hours and in the end multiply by this 3 factor. When my clients complain about the estimate I often say we "writ…
But you risk your manager (if you have one) telling you you are "sandbagging." And you might see others on your team tell your manager "it's no big deal - an hour or so of work". And they slap some crap in there that whacks the mole down long enough for the manager to make a mental note to give your team mate a bigger raise than you.
One of the best things you can do in your organization is create a culture that treats obstacle discovery as forward progress. There is nothing more disheartening for an engineer than banging her head against the wall trying to debug some race condition only to get flak from management about why it isn't fixed and why it's holding up some milestone. The root of this problem is management that doesn't understand the p…
Just to play devil's advocate, there is also the type of person who tends to get stuck down rabbit holes more than they should. There's a skill not just to solving problems but avoiding them in the first place. Usually this requires not just engineering talent but the ability to see the bigger picture, in terms of product and business goals. If someone is banging their head against the wall, it may be because they ar…
One of the best things you can do in your organization is create a culture that treats obstacle discovery as forward progress. There is nothing more disheartening for an engineer than banging her head against the wall trying to debug some race condition only to get flak from management about why it isn't fixed and why it's holding up some milestone. The root of this problem is management that doesn't understand the p…
Just to play devil's advocate, there is also the type of person who tends to get stuck down rabbit holes more than they should. There's a skill not just to solving problems but avoiding them in the first place. Usually this requires not just engineering talent but the ability to see the bigger picture, in terms of product and business goals. If someone is banging their head against the wall, it may be because they ar…
Note to self: Remember this, whenever you feel stuck and look at the problem in perspective.
My experience, tells me this is one of the biggest guidance a technical/engineering manager must be able to provide to his team. I am not sure how hard or easy or for that matter even makes sense from the manager/lead's perspective, it is to provide this, but have found that whenever my manager is asking me to speed-up i run into these problems and lose the ability to judge whether i'm running against a wall or not.
One of the best things you can do in your organization is create a culture that treats obstacle discovery as forward progress. There is nothing more disheartening for an engineer than banging her head against the wall trying to debug some race condition only to get flak from management about why it isn't fixed and why it's holding up some milestone. The root of this problem is management that doesn't understand the p…
Just to play devil's advocate, there is also the type of person who tends to get stuck down rabbit holes more than they should. There's a skill not just to solving problems but avoiding them in the first place. Usually this requires not just engineering talent but the ability to see the bigger picture, in terms of product and business goals. If someone is banging their head against the wall, it may be because they ar…
I've seen many folks in management just always assume incompetence or rabbit holing on the part of engineers. It's good to ask clarifying questions. But as a manager you should be aware that adopting a style of second guessing and interrogating everything your reports do comes off as insulting - after all, you likely hired them, so why don't you trust them?
That being said there are no hard and fast rules here, and being aware of the different histories of different folks is important, but defaulting to a critical attitude is likely to lead to all types of efforts to hide things from you just to avoid questioning, feeling insulted, having their time wasted, etc.
One of the best things you can do in your organization is create a culture that treats obstacle discovery as forward progress. There is nothing more disheartening for an engineer than banging her head against the wall trying to debug some race condition only to get flak from management about why it isn't fixed and why it's holding up some milestone. The root of this problem is management that doesn't understand the p…
Just to play devil's advocate, there is also the type of person who tends to get stuck down rabbit holes more than they should. There's a skill not just to solving problems but avoiding them in the first place. Usually this requires not just engineering talent but the ability to see the bigger picture, in terms of product and business goals. If someone is banging their head against the wall, it may be because they ar…
I've been developing for 30 years. When asked for an estimate I spend time thinking about it and then when I come up with a number I multiply it by 3. Usually this works but sometimes I can be off. My typical process is to score stuff from "totally get it" to "don't have it all in my head". I then guess on hours and in the end multiply by this 3 factor. When my clients complain about the estimate I often say we "writ…
Scarily enough, I've worked with people whose multipliers are this large.
One of the best things you can do in your organization is create a culture that treats obstacle discovery as forward progress. There is nothing more disheartening for an engineer than banging her head against the wall trying to debug some race condition only to get flak from management about why it isn't fixed and why it's holding up some milestone. The root of this problem is management that doesn't understand the p…
Just to play devil's advocate, there is also the type of person who tends to get stuck down rabbit holes more than they should. There's a skill not just to solving problems but avoiding them in the first place. Usually this requires not just engineering talent but the ability to see the bigger picture, in terms of product and business goals. If someone is banging their head against the wall, it may be because they ar…
> “We should just be more careful at the specification stage”. But this turns out to fail, badly. Why? The core reason is that, as you can see from the examples above, if you were to write a specification in such detail that it would capture those issues, you’d be writing the software. Not true; a specification can precisely describe the properties of the solution of a (sub-)problem, rather than the process of solvin…
But seriously, though, YMMV, and the mileage on this one is all too often very low. If the requirements are detailed enough to be accurate, the users don't understand them, or simply agree to blatant inaccuracies.
Iterative development really is The Way, but The Management simply doesn't want to hear it. "What part of 'Loser' didn't you understand?" said the Sociopath (as long as hiding requirements = free extra labor).