4 ms·

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 P

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.

pdimitar 9y ago
Well, we don't actually disagree. :) What I am saying is that estimates, even wildly incorrect ones, are over-valued and over-used. You seem to agree with that. I was pretty self-conscious (still am) in why do I mis-estimate but truth be told, nothing much can be done most of the time. If you go the cautious route, management tells you "that's too long, reduce it". If you reduce it, it's very likely you'll miss that now imaginary estimate, and the whole thing restarts itself for yet another vicious cycle. If you overwork yourself and manage to meet the near-impossible deadline, this becomes the baseline expectation for your productivity. One you cannot maintain for long. Yet again, management is unhappy afterwards. All of what you said I can easily agree with... if we the programmers had actual decision power in the managerial hierarchy. Which we don't.
- keithnz 9y ago
  yes, in the early days of agile processes the term "brain engaged" came up a lot when it comes to practices. You have to understand the purpose of things. overworking is not agile, one of the 12 principles "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. " but what you are saying is the common case of "let's do agile so we can get the software we want when we want". and then, commonly, that is "a scrum like planning process" and buzz words like CI and tests.... but it's just not agile. It's why you feel like you have no power, it's agile practices used in non agile ways. From my experience, ~90% of time is spent on technical excellence, 10% is the broader process, and the broader process get's tweaked regularly to adapt to changing circumstance
  - pdimitar 9y ago
    > It's why you feel like you have no power, it's agile practices used in non agile ways. Yes and no. Yes, because almost nobody really follows an agile process -- the original manifesto seems to be lost on almost everybody in the area. No, because I feel I have no power because nobody wants me to make decisions that even the slightest business implications. This is wrong on many levels. I'll be the first to agree many programmers are naive as cocker-spaniels and only think of the technicalities and never of the real world -- sadly that's true enough. Those of us with a wider culture however can make huge impact, and we're denied the possibility because of prejudiced cretins in suits who actually have much less culture in different areas of life compared to us. > From my experience, ~90% of time is spent on technical excellence, 10% is the broader process, and the broader process get's tweaked regularly to adapt to changing circumstance. Nasty stereotyping, unless I am reading your text wrong. What I and many others have as daily reality (happily I parted ways with such employers but many others haven't yet) is: - 40% of the time is spent in meaningless meetings: sprint starts, pointless bickering in status meetings, discussing a task for a longer time than it would take me to code a prototype half-asleep, personal vendettas concealed as coding style wars -- you name it, it's all there. - 20% of the time is spent in documenting things you simply don't know right now. You're paid to spend 20% of your time as a fiction writer. - 20% of the time is spent in actually coding. If you don't get interrupted 5 times an hour, count yourself lucky. - 20% of the time is spent in "retrospects", mini-meetings, mid-sprint priority re-adjustments and the "Scrum master" trying to act like a big daddy to everyone while full-well knowing he can't influence his boss' opinion on when the final shipping date should be.
zimpenfish 9y ago
> You look at what the cause of all the variation is, then sort it. It would be nice to actually spend time improving the codebase but unfortunately customers, marketing, and management have different priorities.

pdimitar 9y ago

Well, we don't actually disagree. :) What I am saying is that estimates, even wildly incorrect ones, are over-valued and over-used. You seem to agree with that. I was pretty self-conscious (still am) in why do I mis-estimate but truth be told, nothing much can be done most of the time. If you go the cautious route, management tells you "that's too long, reduce it". If you reduce it, it's very likely you'll miss that now imaginary estimate, and the whole thing restarts itself for yet another vicious cycle. If you overwork yourself and manage to meet the near-impossible deadline, this becomes the baseline expectation for your productivity. One you cannot maintain for long. Yet again, management is unhappy afterwards. All of what you said I can easily agree with... if we the programmers had actual decision power in the managerial hierarchy. Which we don't.

keithnz 9y ago
yes, in the early days of agile processes the term "brain engaged" came up a lot when it comes to practices. You have to understand the purpose of things. overworking is not agile, one of the 12 principles "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. " but what you are saying is the common case of "let's do agile so we can get the software we want when we want". and then, commonly, that is "a scrum like planning process" and buzz words like CI and tests.... but it's just not agile. It's why you feel like you have no power, it's agile practices used in non agile ways. From my experience, ~90% of time is spent on technical excellence, 10% is the broader process, and the broader process get's tweaked regularly to adapt to changing circumstance
- pdimitar 9y ago
  > It's why you feel like you have no power, it's agile practices used in non agile ways. Yes and no. Yes, because almost nobody really follows an agile process -- the original manifesto seems to be lost on almost everybody in the area. No, because I feel I have no power because nobody wants me to make decisions that even the slightest business implications. This is wrong on many levels. I'll be the first to agree many programmers are naive as cocker-spaniels and only think of the technicalities and never of the real world -- sadly that's true enough. Those of us with a wider culture however can make huge impact, and we're denied the possibility because of prejudiced cretins in suits who actually have much less culture in different areas of life compared to us. > From my experience, ~90% of time is spent on technical excellence, 10% is the broader process, and the broader process get's tweaked regularly to adapt to changing circumstance. Nasty stereotyping, unless I am reading your text wrong. What I and many others have as daily reality (happily I parted ways with such employers but many others haven't yet) is: - 40% of the time is spent in meaningless meetings: sprint starts, pointless bickering in status meetings, discussing a task for a longer time than it would take me to code a prototype half-asleep, personal vendettas concealed as coding style wars -- you name it, it's all there. - 20% of the time is spent in documenting things you simply don't know right now. You're paid to spend 20% of your time as a fiction writer. - 20% of the time is spent in actually coding. If you don't get interrupted 5 times an hour, count yourself lucky. - 20% of the time is spent in "retrospects", mini-meetings, mid-sprint priority re-adjustments and the "Scrum master" trying to act like a big daddy to everyone while full-well knowing he can't influence his boss' opinion on when the final shipping date should be.

zimpenfish 9y ago

> You look at what the cause of all the variation is, then sort it. It would be nice to actually spend time improving the codebase but unfortunately customers, marketing, and management have different priorities.