5 ms·

Couldn't disagree more with this article, is this even written by a programmer? Agile takes into account the very real 'semantic cost' when translating from use

Couldn't disagree more with this article, is this even written by a programmer? Agile takes into account the very real 'semantic cost' when translating from user requirements to actual code. Code is so specific and brittle compared to the lovely fuzzy English language that we think and write in, that we can never get the requirements just right. The biggest problem is integration of ideas into an existing system. Yeah ok you want to extend the login screen to support one extra field? That's great but after a couple of days work, it turns out that 2 years ago Joe Bloggs added some complex verification algorithm no one understands to a stored procedure, oh which contains about 30 other input fields, and so is going to take an extra week to untangle. The procedure is also used in 20 other places too and there's no unit tests covering any of the functionality. Agile gives the programmer a voice in the process, and once they update the tasks and time estimates, the feature's priority can be re-evaluated. Treating development as a one shot process is just doomed to fail and more stressful for everyone involved.

zimpenfish 9y ago
> Agile gives the programmer a voice in the process In theory, perhaps, but there are many places (everywhere I've worked) where the programmer voice is subjugated to project managers, product owners, and pretty much everyone else. > once they update the tasks and time estimates, the feature's priority can be re-evaluated Never worked anywhere that developer task and time estimates were considered as "truth" rather than something for everyone else to override or ignore based on external constraints.
- sametmax 9y ago
  Then you never worked in an agile team. The feedback loop is the most important part of it.
  - pdimitar 9y ago
    "Communism never worked because it was never implemented in its purest form". Sorry for being a bit dismissive, but take the above quote and apply it to Agile. I frankly never seen it working anywhere, ever. Most of the times it actually made things worse.
    - sametmax 9y ago
      I understand your frustration as most shops claiming they do agile actually don't. But I've worked at least twice in agile envs, and it worked nicely. But the requirement is to have a good team. And when you have a good team, most things work, agile or not :)
      - pdimitar 9y ago
        Exactly. A hand-waving methodology means nothing when the people like what they do and they're professionals -- maybe even friends. I've witnessed that in both semi-agile and semi-waterfall teams. So yeah, I agree. :)
- matthewmacleod 9y ago
  Never worked anywhere that developer task and time estimates were considered as "truth" rather than something for everyone else to override or ignore based on external constraints. In that case – and I've said this often – the problem is with wider organisational culture and 'agile' or otherwise will not help with that. I work in an environment where those estimates are just bluntly accepted, because they're the considered opinion of a team of professionals, and they're never overridden. If they are too high to meet some other business or marketing constraint, then we can start looking at ways to reduce the scope, extend the deadline, or incur some temporary technical debt. I can't imagine having my estimates 'overridden' by anybody else and would not continue to work in an company where my actual, professional opinion about my own work was routinely ignored.
  - pdimitar 9y ago
    Count yourself lucky. Or, like my wife, you are one of these people that are proud in a kingly yet humble manner -- and never allow anyone to step on them ever since early childhood. They seem to have a presence/aura that strongly discourages all dictators from trying to dominate them.
- 2muchcoffeeman 9y ago
  In theory, perhaps, but there are many places (everywhere I've worked) where the programmer voice is subjugated to project managers, product owners, and pretty much everyone else. If you actively ignore the process, the process fails. People also expect too much of a quick fix. But change takes time. I briefly worked in an environment where everybody was on board, and I have to say it worked really well, until new management screwed it up all over again.
- keithnz 9y ago
  estimates are supposed to be just that. You then compare them with what actually happened, then you can work out if the estimates correlate well with work getting done. The whole point of that is you can then start making decisions about scope / timeframe. If it's not used to make decisions about scope and time frame, then don't do it.
  - pdimitar 9y ago
    > estimates are supposed to be just that. You then compare them with what actually happened, then you can work out if the estimates correlate well with work getting done. Impossible, unless you work in a very narrow scope. Examples: (1) I had to add several new parameters to an endpoint that accepted data from HTTP forms. It was a pain since there were mechanisms in the code nobody documented. Estimate: 1 day. Done: 2 days. (2) I had to make phone numbers mandatory if your physical shipping address is in a certain USA state. Estimate: 3 days (loads of JS written by previous team). Done: 2 hours. Reason: they actually added an engine for such dynamic rules; after doing due diligence, the work was walk in the park. (3) I had to allow a small part of our endpoints to be able to save to two different data stores. Estimate: 1 week. Done: 4 weeks. Reason: hardcoded Oracle SQL everywhere, had to rework 50+ modules several times. (4) I had to improve helper modules that cached data from remote API that was painfully slow to proxy through. Estimate: 3 days. Done: 3 weeks. Reason: the current code that cached stuff was extremely superficial, didn't deal with cache expiration, and it didn't even work part of the time. I can go all day. Point is, when you can do a lot, you get assigned a lot, and usually they are pretty different tasks. You can't reasonably draw any meaningful conclusion, except one: that an individual is over-estimating themselves. And even that is not always true because even at 37 I still don't expect at least half of the stupidities I find in legacy code that I have to maintain and evolve as part of a contract. I try very hard to not to be an ass, meaning I do not assume everyone is an idiot. From my perspective I give realistic estimates. In retrospect however, I probably should've assumed the worst 19 out of 20 times.
    - keithnz 9y ago
      It's not impossible. Your examples are what orginally was the reason for massive massive emphasis on code quality and automation ( I started out with Extreme Programming in 99 ). Your examples are actually the whole point, if your code base becomes such that estimates vs actual does not correlate very well, then you don't use it to plan, you have too much variation. You look at what the cause of all the variation is, then sort it. It's actually good when it's no good for planning, it means you should have a bunch of obvious things to improve. Estimates were, in the XP world at least, virtual. You could give them a unit of "JellyBeans" so tasks were either a 1, 2 3, 4 JellyBean level of effort. Then you tracked how many jellybeans you get done in a time interval. Plan based on how many Jellybeans you got done in the last time interval. You track the variation. If your variation essentially means it's not predictable, then you look at why, and improve that. You as an individual should also be concious of how you are estimating as well, if you "should've assumed the worst 19 our of 20 times" then do that. IT'S THE WHOLE POINT. It's a feedback mechanisim. It's really important you don't blindly do planning with estimates if it's not working. It's meant so you can make reasoned choices about scope to achieve a particular time line. - so either variability is good meaning you make reasoned choices about scope - OR it's bad, and you make reasoned choices about improving the code base.
danielbarla 9y ago
I think the last paragraph is perhaps as important as the first one, though I wonder if it highlights the most poignant issues. In a sense, one concept agile is aimed at is that (most of the time) neither the developer nor the user / business knows exactly what the end result should be. Rather than try to ignore this, agile aims to treat it as a base truth, and work with it. Whether it succeeds or not is open for debate, but for most domains, I tend to prefer it over big, upfront design.
mattmanser 9y ago
I read the article and can't understand your point of view. It feels as if you didn't read the article and are responding to the title. He's not saying it doesn't work at all, he's saying it often doesn't work when the developers aren't listened to. Re-read the final section, or the conclusion: Which brings me to Agile. Agile is worthless unless it serves as a catalyst for continuous improvement.
barrkel 9y ago
> Agile gives the programmer a voice in the process This is not my experience of "agile"; in practice, it's a conveyor belt of user stories in a feature factory, and developers are simply cogs in the meat grinder. You can try and feed information in via estimates, sure, but that can only marginally change how the product evolves under the prevailing winds. Unless you give silly estimates, you have a hard time changing product management's mind much. And it's not a route for coming up with new features by recombining already existing work.
- zzalpha 9y ago
  you have a hard time changing product management's mind much. I have pity for you that you have to live with such a shitty product manager. But don't think it reasonable to paint all PMs with that same brush. Conversely, I could claim all developers are flat-food-eating basement dwellers who can't communicate with real humans. But that wouldn't be very fair, either.
  - pdimitar 9y ago
    I don't hate PMs per se, mind you, but my experience for 15 years of career is exactly the same. I have stumbled upon exactly 2 out of 70+ PMs that actually valued programmers' opinion and used it to change project roadmaps and schedules. ...and these 2 PMs didn't last even 6 months. Higher management is not happy when its prejudiced idealistic picture of productivity and feature deliveries is challenged by reality. A bit too cynical, I know. But it has been true in the majority of my office / freelance / consultant / remote work.
pdimitar 9y ago
> Agile gives the programmer a voice in the process, and once they update the tasks and time estimates, the feature's priority can be re-evaluated. You couldn't be more wrong on this one. Managers love their power and they don't give it away to programmers no matter what. In 15 years of career I've never seen a manager treat a programmer as a decision maker, not even once. And I suspect that's a biiiiiit more than "anecdotal evidence". What usually happens is: - "Why did this estimate change from 2 days to 3 weeks?" - "Are you sure you're doing this right?" (coming from a non-technical manager) - "Let me stop you right there. We heard your concerns but you overplay their importance." (that I can agree with sometimes) - "This feature is important. Reduce your estimate, it doesn't look good to the people above us." ...etc. to infinity. Agile is not, and never was, a magic bullet. It's kind of like some economical systems that only existed on paper -- sounds perfect in theory, is never implemented well (or fully) in practice.

zimpenfish 9y ago

> Agile gives the programmer a voice in the process In theory, perhaps, but there are many places (everywhere I've worked) where the programmer voice is subjugated to project managers, product owners, and pretty much everyone else. > once they update the tasks and time estimates, the feature's priority can be re-evaluated Never worked anywhere that developer task and time estimates were considered as "truth" rather than something for everyone else to override or ignore based on external constraints.

sametmax 9y ago
Then you never worked in an agile team. The feedback loop is the most important part of it.
- pdimitar 9y ago
  "Communism never worked because it was never implemented in its purest form". Sorry for being a bit dismissive, but take the above quote and apply it to Agile. I frankly never seen it working anywhere, ever. Most of the times it actually made things worse.
  - sametmax 9y ago
    I understand your frustration as most shops claiming they do agile actually don't. But I've worked at least twice in agile envs, and it worked nicely. But the requirement is to have a good team. And when you have a good team, most things work, agile or not :)
    - pdimitar 9y ago
      Exactly. A hand-waving methodology means nothing when the people like what they do and they're professionals -- maybe even friends. I've witnessed that in both semi-agile and semi-waterfall teams. So yeah, I agree. :)
matthewmacleod 9y ago
Never worked anywhere that developer task and time estimates were considered as "truth" rather than something for everyone else to override or ignore based on external constraints. In that case – and I've said this often – the problem is with wider organisational culture and 'agile' or otherwise will not help with that. I work in an environment where those estimates are just bluntly accepted, because they're the considered opinion of a team of professionals, and they're never overridden. If they are too high to meet some other business or marketing constraint, then we can start looking at ways to reduce the scope, extend the deadline, or incur some temporary technical debt. I can't imagine having my estimates 'overridden' by anybody else and would not continue to work in an company where my actual, professional opinion about my own work was routinely ignored.
- pdimitar 9y ago
  Count yourself lucky. Or, like my wife, you are one of these people that are proud in a kingly yet humble manner -- and never allow anyone to step on them ever since early childhood. They seem to have a presence/aura that strongly discourages all dictators from trying to dominate them.
2muchcoffeeman 9y ago
In theory, perhaps, but there are many places (everywhere I've worked) where the programmer voice is subjugated to project managers, product owners, and pretty much everyone else. If you actively ignore the process, the process fails. People also expect too much of a quick fix. But change takes time. I briefly worked in an environment where everybody was on board, and I have to say it worked really well, until new management screwed it up all over again.
keithnz 9y ago
estimates are supposed to be just that. You then compare them with what actually happened, then you can work out if the estimates correlate well with work getting done. The whole point of that is you can then start making decisions about scope / timeframe. If it's not used to make decisions about scope and time frame, then don't do it.
- pdimitar 9y ago
  > estimates are supposed to be just that. You then compare them with what actually happened, then you can work out if the estimates correlate well with work getting done. Impossible, unless you work in a very narrow scope. Examples: (1) I had to add several new parameters to an endpoint that accepted data from HTTP forms. It was a pain since there were mechanisms in the code nobody documented. Estimate: 1 day. Done: 2 days. (2) I had to make phone numbers mandatory if your physical shipping address is in a certain USA state. Estimate: 3 days (loads of JS written by previous team). Done: 2 hours. Reason: they actually added an engine for such dynamic rules; after doing due diligence, the work was walk in the park. (3) I had to allow a small part of our endpoints to be able to save to two different data stores. Estimate: 1 week. Done: 4 weeks. Reason: hardcoded Oracle SQL everywhere, had to rework 50+ modules several times. (4) I had to improve helper modules that cached data from remote API that was painfully slow to proxy through. Estimate: 3 days. Done: 3 weeks. Reason: the current code that cached stuff was extremely superficial, didn't deal with cache expiration, and it didn't even work part of the time. I can go all day. Point is, when you can do a lot, you get assigned a lot, and usually they are pretty different tasks. You can't reasonably draw any meaningful conclusion, except one: that an individual is over-estimating themselves. And even that is not always true because even at 37 I still don't expect at least half of the stupidities I find in legacy code that I have to maintain and evolve as part of a contract. I try very hard to not to be an ass, meaning I do not assume everyone is an idiot. From my perspective I give realistic estimates. In retrospect however, I probably should've assumed the worst 19 out of 20 times.
  - keithnz 9y ago
    It's not impossible. Your examples are what orginally was the reason for massive massive emphasis on code quality and automation ( I started out with Extreme Programming in 99 ). Your examples are actually the whole point, if your code base becomes such that estimates vs actual does not correlate very well, then you don't use it to plan, you have too much variation. You look at what the cause of all the variation is, then sort it. It's actually good when it's no good for planning, it means you should have a bunch of obvious things to improve. Estimates were, in the XP world at least, virtual. You could give them a unit of "JellyBeans" so tasks were either a 1, 2 3, 4 JellyBean level of effort. Then you tracked how many jellybeans you get done in a time interval. Plan based on how many Jellybeans you got done in the last time interval. You track the variation. If your variation essentially means it's not predictable, then you look at why, and improve that. You as an individual should also be concious of how you are estimating as well, if you "should've assumed the worst 19 our of 20 times" then do that. IT'S THE WHOLE POINT. It's a feedback mechanisim. It's really important you don't blindly do planning with estimates if it's not working. It's meant so you can make reasoned choices about scope to achieve a particular time line. - so either variability is good meaning you make reasoned choices about scope - OR it's bad, and you make reasoned choices about improving the code base.

danielbarla 9y ago

I think the last paragraph is perhaps as important as the first one, though I wonder if it highlights the most poignant issues. In a sense, one concept agile is aimed at is that (most of the time) neither the developer nor the user / business knows exactly what the end result should be. Rather than try to ignore this, agile aims to treat it as a base truth, and work with it. Whether it succeeds or not is open for debate, but for most domains, I tend to prefer it over big, upfront design.

mattmanser 9y ago

I read the article and can't understand your point of view. It feels as if you didn't read the article and are responding to the title. He's not saying it doesn't work at all, he's saying it often doesn't work when the developers aren't listened to. Re-read the final section, or the conclusion: Which brings me to Agile. Agile is worthless unless it serves as a catalyst for continuous improvement.

barrkel 9y ago

> Agile gives the programmer a voice in the process This is not my experience of "agile"; in practice, it's a conveyor belt of user stories in a feature factory, and developers are simply cogs in the meat grinder. You can try and feed information in via estimates, sure, but that can only marginally change how the product evolves under the prevailing winds. Unless you give silly estimates, you have a hard time changing product management's mind much. And it's not a route for coming up with new features by recombining already existing work.

zzalpha 9y ago
you have a hard time changing product management's mind much. I have pity for you that you have to live with such a shitty product manager. But don't think it reasonable to paint all PMs with that same brush. Conversely, I could claim all developers are flat-food-eating basement dwellers who can't communicate with real humans. But that wouldn't be very fair, either.
- pdimitar 9y ago
  I don't hate PMs per se, mind you, but my experience for 15 years of career is exactly the same. I have stumbled upon exactly 2 out of 70+ PMs that actually valued programmers' opinion and used it to change project roadmaps and schedules. ...and these 2 PMs didn't last even 6 months. Higher management is not happy when its prejudiced idealistic picture of productivity and feature deliveries is challenged by reality. A bit too cynical, I know. But it has been true in the majority of my office / freelance / consultant / remote work.

pdimitar 9y ago

> Agile gives the programmer a voice in the process, and once they update the tasks and time estimates, the feature's priority can be re-evaluated. You couldn't be more wrong on this one. Managers love their power and they don't give it away to programmers no matter what. In 15 years of career I've never seen a manager treat a programmer as a decision maker, not even once. And I suspect that's a biiiiiit more than "anecdotal evidence". What usually happens is: - "Why did this estimate change from 2 days to 3 weeks?" - "Are you sure you're doing this right?" (coming from a non-technical manager) - "Let me stop you right there. We heard your concerns but you overplay their importance." (that I can agree with sometimes) - "This feature is important. Reduce your estimate, it doesn't look good to the people above us." ...etc. to infinity. Agile is not, and never was, a magic bullet. It's kind of like some economical systems that only existed on paper -- sounds perfect in theory, is never implemented well (or fully) in practice.