7 ms·

On the flip side, I've seen far too many teams move at the speed of molasses, for reasons unrelated to the intrinsic complexity of the problem. Bureaucracy, ana

by noego 7y ago

On the flip side, I've seen far too many teams move at the speed of molasses, for reasons unrelated to the intrinsic complexity of the problem. Bureaucracy, analysis paralysis, no automated testing, accidental complexity, tech debt, poor retention of experienced developers, poor compensation resulting in sub-par hires, insufficient training and mentoring for new hires etc etc. I wouldn't be so quick to assume that every single development team is operating at their most ideal.

HeyLaughingBoy 7y ago
All the more reason to expect it to take longer.
sneak 7y ago
The real trick is being able to tell the difference between a normally slow process and a pathologically slow process, on non-trivial scales. I’m 20+ years in and I’m just getting a handle on it in the last 5 years or so. Meanwhile, I see non-software people putting their complete trust in people with less than half my experience, and getting burned.
- hinkley 7y ago
  Limited Work in Progress tries to address this. The longer a task takes the more scrutiny it gets from hopefully sympathetic individuals. If you are chasing your tail, after a week or two someone who understands what's going on will unwind you and set you up to complete the task.
irq11 7y ago
I’m dealing with this right now. A team that is downright arrogant about reducing their well-padded schedule, taking months to do a job that should take weeks, at most. Getting them to do anything is like pulling teeth, and accompanied with lots of arrogant lectures about how hard it is to estimate, how you can’t rush quality, and so on. It’s mostly bullshit. This team has historical reasons for their bloated schedules, but at root, they’ve simply been coddled, and never forced to justify their behavior. I’ve been on both sides of the table now. Developers like to gripe and moan about “unrealistic” schedules, but without aggressive pushback from management, a huge number of programmers will simply never ship.
- throwaway55554 7y ago
  Sounds like a hiring problem. Start hiring some new devs and keep them separate so as to not contaminate them. As they come up to speed, let one of the other devs go. Wash, rinse and repeat. Note: I'm a dev and I can tell you I very much dislike working with prima donnas.
  - commandlinefan 7y ago
    > Sounds like a hiring problem. Yes, but not the way I think he’s thinking (and maybe not the way you’re thinking either). If you were actually in a room with him and said, “ok, let’s just walk in there right now, fire these clowns and replace them with somebody better” he’d immediately hold up his hand and say, “but I can’t find anybody better…”. So yes, it’s probably a hiring problem but the problem is that he’s putting unreasonable expectations on the people he’s hiring.
  - megablast 7y ago
    Oh yes, keep them separate from the people who know the application, how it works, what it integrated with, all the codes, all the issues. Brilliant!
    - throwaway55554 7y ago
      Right!?
- Retra 7y ago
  Perhaps shipping simply produces more value for you than it does for them?
- hinkley 7y ago
  That knife cuts both ways. I am fundamentally a clever lazy person. I'm always looking for ways to reduce the amount of accidental complexity I have to do, and reduce the number of trivial interruptions I get by documenting the situation a little better every time someone asks me about it, until the rate drops below my pain threshold. If it weren't for schedules I'd have no defense at all for 'wasting time' on something that saves each of my teammates an hour of pain per week. (I've had a lot of shitty managers. Stuff like this shouldn't need a defense).
thanatropism 7y ago
> . Bureaucracy, analysis paralysis, no automated testing, accidental complexity, tech debt, poor retention of experienced developers, poor compensation resulting in sub-par hires, insufficient training and mentoring for new hires etc etc. Most of these look like MBA problems. That said, maybe more experienced coders should be doing MBAs (which isn't just about attending classes but about networking, acquiring a wider shallower knowledge base etc) so the dynamics of tech debt are clear to people who are in charge of making debt decisions.
- 4ntonius8lock 7y ago
  As someone who has spent time as a project and product manager, I will say a lot of it comes down to a point of view that 'tech will make it happen'. Many times I've seen long time estimates for something, because C level was requesting "X feature". But when you sit down down with C level, and understand what they want to achieve with X feature, many times it is possible to sit down with tech and figure a way to get what was wanted without the feature, generally by adapting some other request or feature. The problem is that most managers are looking to suck up to C level guys and 'deliver'. And many C level guys won't stand the insubordination of someone telling them 'maybe that thing you guys thought of isn't the best way to achieve what you want', no matter how much you work on the techniques from How to Win friends and influence people. Some guys are just dictators, and some are suck ups, and when the two meet, as they often do, it means tech will work 10x what is needed to get where the company needs to be, because the focus will be on what someone requested, not what we are looking to get at. Also, many developers get stuck in the mindset of places like that, where they assume they have no voice and everything they say will be used against them. So you ask them as a manager how they would achieve X and they just say "tell me what you want in the spec sheet"... people get weirdly conditioned when in negative re-enforcement environments.
  - jrochkind1 7y ago
    > because C level was requesting "X feature". But when you sit down down with C level, and understand what they want to achieve with X feature, many times it is possible to sit down with tech and figure a way to get what was wanted without the feature, generally by adapting some other request or feature. In the best functioning development organizations I have experienced or seen, nobody should be asking for "X feature", they should be explaining what their actual needs are, what they need to get out of the software and why. And how important it is to them, or even what their "budget" for it is. And a technical designer (who could be a developer who has some design skills perhaps by experience, or a designer who understands the tech) _designs a solution_. This requires someone(s) on the "development" side who can do needs/requirements analysis leading design (ie, "UX"). And it requires the stakeholders to trust that the capacity is there, and that it will turn all right if they don't try to micromanage the feature -- not just "all right", it'll be SO MUCH BETTER. This works so well when the organization staffs itself to make it possible and the people in charge allow it to happen, that it seems kind of insane that so few organizations do so.
novaleaf 7y ago
my own anicdata: Integrate a default proxy into our existing "choose proxy" workflow takes about 2 weeks, and I'm currently on my 3rd month of those 2 weeks :) Reasons for the delay: 1) Proxy is a stand-alone application. Needs it's own deployment and build configuration 2) Main app was running on Node 6.x. High time to upgrade to 10.x as 6.x LTS is running out. 3) Upgrade to 10.x breaks some modules we depend on (Google Cloud datastore) and that module has been deprecated in Node 8.x+.. time to refactor that.... 4) Main app is in a mono-repo with backend systems still running node 6.x Don't want to spend the time upgrading everything to node 10, so need to split Main app into it's own repo, decoupling from existing mono-repo codebase 5) Since we are upgrading main app to Node 10, Best to remove dependencies on old definitely-typed typescript typings (upgrade to npm @types definitions). And as such refactor to use latest version of all modules.... 6) Security: New Default Proxy should only allow the Main app. code a solution for this using Keypairs.... 7) Docs, sample code for users, announcement mail. thankfully i'm currently on step 7. Usually I expect to be off on my estimates by a factor of 4x. This is excessive :)
- elemeno 7y ago
  But in a case like yours if sounds like steps 2 through 5 aren't strictly relevant to the change you're making, so it's no wonder that your estimate is blown out the water. (Sorry if I'm wrong, you've obviously got more context on your own platform than I do!) It does make me wonder though if there is a trend of 'hiding' necessary maintenance work in larger tasks - if so that seems to me to be indicative of a larger problem around not being given/making the time to do those jobs as their own tasks.
  - hinkley 7y ago
    Yes, there is. Probably the best four projects I worked on, there was collusion to spread out the cost of necessary maintenance across all work items. Because nobody will agree to doing maintenance stories (this is how Scrum hijacks developer ethics). Never ask permission to do something that must be done. Or to look at it another way, if no stories are maintenance stories, then all stories are maintenance stories.
Retric 7y ago
That’s irreverent as each estimation is based on that team and it’s situation. If I am going to spend 20 hours a week stuck in meetings that’s going to impact my estimates.
- hnlmorg 7y ago
  It shouldn't do. Estimations should be based on FTE (full time equivalents) of the broken down tasks. An estimation shouldn't be guesswork of a delivery date based on your current teams situation but rather a calculated value of the number of days of effort (eg it would take 1 person 82 days if they worked on it for 7.5 hours a day) with a little margin added for any unforeseen technical hurdles that will inevitably crop up. If estimations are based on FTE then you can factor in meetings, holidays, and even other projects that might suck up resources ("resources" in this case being your engineers work time) into your delivery date. You can detect very early on if your deadlines are slipping (assuming your team are logging their hours against tickers or a timesheet) and you can also make informed judgements ahead of time about whether you need more resources (were that's an option / the work can be scaled across more engineers). Obviously this is harder if you're tackling a significantly larger "green field" project - you might have to start making some educated guesses in those instances. But most of the time you should have some idea about the work involved.
  - Retric 7y ago
    Accurate time estimates need to be associated with specific individuals. Someone who is familiar with the relevant code is simply faster than someone who is not. Further, interruptions don’t just cost time, they also reduce productivity around them. Now, you can try and do effort estimates using hypothetical people. But, at that point you have already given up the possibility of an accurate answer.
    - hnlmorg 7y ago
      > Accurate time estimates need to be associated with specific individuals. Someone who is familiar with the relevant code is simply faster than someone who is not. This is one of the many reasons why I disagree with giving projects to specific individuals. Not only do you end up silos of knowledge (which is a risk if that engineer should leave / get fired / die in a bus accident) but you also make it harder for yourself to make estimates for the reasons you've described. Sure there will always be a variance from person to person but you stand a greater chance of that averaging out if you discourage engineers "owning" code bases. > Further, interruptions don’t just cost time, they also reduce productivity around them. You missed my point regarding meetings. I'm saying if you estimate a project based on FTEs (different methodologies and frameworks will have different terms but they usually amount to the same concept) then time spent in meetings becomes a modifier you can easily adjust for, rather than a hidden time sink that you can't account for. > Now, you can try and do effort estimates using hypothetical people. But, at that point you have already given up the possibility of an accurate answer. You don't need to make the estimate on hypothetical people. You just need a system of tracking and reporting the hours people spend in a working day. For example in JIRA you can log time against a ticket and you can create generic tickets for meetings. Therefore after a week / sprint / arbitrary point in time you can view where your engineers have spent their time and if it's below the allocated time for that project you can then either: - enforce a new policy (eg are all the engineers going to every meeting when just one or two representatives would suffice? Are some meetings just duplicates or redundant? etc), - inform project managers that there will be a deadline slippage due to resource constraints - hire more resource to compensate - or all of the above I agree estimates are never going to be 100% accurate but that doesn't mean there aren't better ways to estimate than just applying guesswork based on your current teams circumstance.

by noego 7y ago

HeyLaughingBoy 7y ago

All the more reason to expect it to take longer.

sneak 7y ago

The real trick is being able to tell the difference between a normally slow process and a pathologically slow process, on non-trivial scales. I’m 20+ years in and I’m just getting a handle on it in the last 5 years or so. Meanwhile, I see non-software people putting their complete trust in people with less than half my experience, and getting burned.

hinkley 7y ago
Limited Work in Progress tries to address this. The longer a task takes the more scrutiny it gets from hopefully sympathetic individuals. If you are chasing your tail, after a week or two someone who understands what's going on will unwind you and set you up to complete the task.

irq11 7y ago

I’m dealing with this right now. A team that is downright arrogant about reducing their well-padded schedule, taking months to do a job that should take weeks, at most. Getting them to do anything is like pulling teeth, and accompanied with lots of arrogant lectures about how hard it is to estimate, how you can’t rush quality, and so on. It’s mostly bullshit. This team has historical reasons for their bloated schedules, but at root, they’ve simply been coddled, and never forced to justify their behavior. I’ve been on both sides of the table now. Developers like to gripe and moan about “unrealistic” schedules, but without aggressive pushback from management, a huge number of programmers will simply never ship.

throwaway55554 7y ago
Sounds like a hiring problem. Start hiring some new devs and keep them separate so as to not contaminate them. As they come up to speed, let one of the other devs go. Wash, rinse and repeat. Note: I'm a dev and I can tell you I very much dislike working with prima donnas.
- commandlinefan 7y ago
  > Sounds like a hiring problem. Yes, but not the way I think he’s thinking (and maybe not the way you’re thinking either). If you were actually in a room with him and said, “ok, let’s just walk in there right now, fire these clowns and replace them with somebody better” he’d immediately hold up his hand and say, “but I can’t find anybody better…”. So yes, it’s probably a hiring problem but the problem is that he’s putting unreasonable expectations on the people he’s hiring.
- megablast 7y ago
  Oh yes, keep them separate from the people who know the application, how it works, what it integrated with, all the codes, all the issues. Brilliant!
  - throwaway55554 7y ago
    Right!?
Retra 7y ago
Perhaps shipping simply produces more value for you than it does for them?
hinkley 7y ago
That knife cuts both ways. I am fundamentally a clever lazy person. I'm always looking for ways to reduce the amount of accidental complexity I have to do, and reduce the number of trivial interruptions I get by documenting the situation a little better every time someone asks me about it, until the rate drops below my pain threshold. If it weren't for schedules I'd have no defense at all for 'wasting time' on something that saves each of my teammates an hour of pain per week. (I've had a lot of shitty managers. Stuff like this shouldn't need a defense).

thanatropism 7y ago

> . Bureaucracy, analysis paralysis, no automated testing, accidental complexity, tech debt, poor retention of experienced developers, poor compensation resulting in sub-par hires, insufficient training and mentoring for new hires etc etc. Most of these look like MBA problems. That said, maybe more experienced coders should be doing MBAs (which isn't just about attending classes but about networking, acquiring a wider shallower knowledge base etc) so the dynamics of tech debt are clear to people who are in charge of making debt decisions.

4ntonius8lock 7y ago
As someone who has spent time as a project and product manager, I will say a lot of it comes down to a point of view that 'tech will make it happen'. Many times I've seen long time estimates for something, because C level was requesting "X feature". But when you sit down down with C level, and understand what they want to achieve with X feature, many times it is possible to sit down with tech and figure a way to get what was wanted without the feature, generally by adapting some other request or feature. The problem is that most managers are looking to suck up to C level guys and 'deliver'. And many C level guys won't stand the insubordination of someone telling them 'maybe that thing you guys thought of isn't the best way to achieve what you want', no matter how much you work on the techniques from How to Win friends and influence people. Some guys are just dictators, and some are suck ups, and when the two meet, as they often do, it means tech will work 10x what is needed to get where the company needs to be, because the focus will be on what someone requested, not what we are looking to get at. Also, many developers get stuck in the mindset of places like that, where they assume they have no voice and everything they say will be used against them. So you ask them as a manager how they would achieve X and they just say "tell me what you want in the spec sheet"... people get weirdly conditioned when in negative re-enforcement environments.
- jrochkind1 7y ago
  > because C level was requesting "X feature". But when you sit down down with C level, and understand what they want to achieve with X feature, many times it is possible to sit down with tech and figure a way to get what was wanted without the feature, generally by adapting some other request or feature. In the best functioning development organizations I have experienced or seen, nobody should be asking for "X feature", they should be explaining what their actual needs are, what they need to get out of the software and why. And how important it is to them, or even what their "budget" for it is. And a technical designer (who could be a developer who has some design skills perhaps by experience, or a designer who understands the tech) _designs a solution_. This requires someone(s) on the "development" side who can do needs/requirements analysis leading design (ie, "UX"). And it requires the stakeholders to trust that the capacity is there, and that it will turn all right if they don't try to micromanage the feature -- not just "all right", it'll be SO MUCH BETTER. This works so well when the organization staffs itself to make it possible and the people in charge allow it to happen, that it seems kind of insane that so few organizations do so.

novaleaf 7y ago

my own anicdata: Integrate a default proxy into our existing "choose proxy" workflow takes about 2 weeks, and I'm currently on my 3rd month of those 2 weeks :) Reasons for the delay: 1) Proxy is a stand-alone application. Needs it's own deployment and build configuration 2) Main app was running on Node 6.x. High time to upgrade to 10.x as 6.x LTS is running out. 3) Upgrade to 10.x breaks some modules we depend on (Google Cloud datastore) and that module has been deprecated in Node 8.x+.. time to refactor that.... 4) Main app is in a mono-repo with backend systems still running node 6.x Don't want to spend the time upgrading everything to node 10, so need to split Main app into it's own repo, decoupling from existing mono-repo codebase 5) Since we are upgrading main app to Node 10, Best to remove dependencies on old definitely-typed typescript typings (upgrade to npm @types definitions). And as such refactor to use latest version of all modules.... 6) Security: New Default Proxy should only allow the Main app. code a solution for this using Keypairs.... 7) Docs, sample code for users, announcement mail. thankfully i'm currently on step 7. Usually I expect to be off on my estimates by a factor of 4x. This is excessive :)

elemeno 7y ago
But in a case like yours if sounds like steps 2 through 5 aren't strictly relevant to the change you're making, so it's no wonder that your estimate is blown out the water. (Sorry if I'm wrong, you've obviously got more context on your own platform than I do!) It does make me wonder though if there is a trend of 'hiding' necessary maintenance work in larger tasks - if so that seems to me to be indicative of a larger problem around not being given/making the time to do those jobs as their own tasks.
- hinkley 7y ago
  Yes, there is. Probably the best four projects I worked on, there was collusion to spread out the cost of necessary maintenance across all work items. Because nobody will agree to doing maintenance stories (this is how Scrum hijacks developer ethics). Never ask permission to do something that must be done. Or to look at it another way, if no stories are maintenance stories, then all stories are maintenance stories.

Retric 7y ago

That’s irreverent as each estimation is based on that team and it’s situation. If I am going to spend 20 hours a week stuck in meetings that’s going to impact my estimates.

hnlmorg 7y ago
It shouldn't do. Estimations should be based on FTE (full time equivalents) of the broken down tasks. An estimation shouldn't be guesswork of a delivery date based on your current teams situation but rather a calculated value of the number of days of effort (eg it would take 1 person 82 days if they worked on it for 7.5 hours a day) with a little margin added for any unforeseen technical hurdles that will inevitably crop up. If estimations are based on FTE then you can factor in meetings, holidays, and even other projects that might suck up resources ("resources" in this case being your engineers work time) into your delivery date. You can detect very early on if your deadlines are slipping (assuming your team are logging their hours against tickers or a timesheet) and you can also make informed judgements ahead of time about whether you need more resources (were that's an option / the work can be scaled across more engineers). Obviously this is harder if you're tackling a significantly larger "green field" project - you might have to start making some educated guesses in those instances. But most of the time you should have some idea about the work involved.
- Retric 7y ago
  Accurate time estimates need to be associated with specific individuals. Someone who is familiar with the relevant code is simply faster than someone who is not. Further, interruptions don’t just cost time, they also reduce productivity around them. Now, you can try and do effort estimates using hypothetical people. But, at that point you have already given up the possibility of an accurate answer.
  - hnlmorg 7y ago
    > Accurate time estimates need to be associated with specific individuals. Someone who is familiar with the relevant code is simply faster than someone who is not. This is one of the many reasons why I disagree with giving projects to specific individuals. Not only do you end up silos of knowledge (which is a risk if that engineer should leave / get fired / die in a bus accident) but you also make it harder for yourself to make estimates for the reasons you've described. Sure there will always be a variance from person to person but you stand a greater chance of that averaging out if you discourage engineers "owning" code bases. > Further, interruptions don’t just cost time, they also reduce productivity around them. You missed my point regarding meetings. I'm saying if you estimate a project based on FTEs (different methodologies and frameworks will have different terms but they usually amount to the same concept) then time spent in meetings becomes a modifier you can easily adjust for, rather than a hidden time sink that you can't account for. > Now, you can try and do effort estimates using hypothetical people. But, at that point you have already given up the possibility of an accurate answer. You don't need to make the estimate on hypothetical people. You just need a system of tracking and reporting the hours people spend in a working day. For example in JIRA you can log time against a ticket and you can create generic tickets for meetings. Therefore after a week / sprint / arbitrary point in time you can view where your engineers have spent their time and if it's below the allocated time for that project you can then either: - enforce a new policy (eg are all the engineers going to every meeting when just one or two representatives would suffice? Are some meetings just duplicates or redundant? etc), - inform project managers that there will be a deadline slippage due to resource constraints - hire more resource to compensate - or all of the above I agree estimates are never going to be 100% accurate but that doesn't mean there aren't better ways to estimate than just applying guesswork based on your current teams circumstance.