Hacker News Reader

> 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.

Then you never worked in an agile team. The feedback loop is the most important part of it.

"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.

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 :)

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. :)

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.

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.

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.

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.

> 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.

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.

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.

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

> 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.

> if we the programmers had actual decision power in the managerial hierarchy. Which we don't.

Only at dysfunctional organizations. Organizations without developers in the managerial hierarchy are almost universally incapable of developing software effectively.

> 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.

> 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.

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.

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.

> 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.

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.

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.