Yes that is what Agile is like
-
From CP newsletter Agile process can spur micromanagement and poorly maintained code, says ex-Google software engineer • DEVCLASS[^] Article that is commenting on a book which reflects on Agile. "Estimates of how long work will take become deadlines and engineers feel untrusted, scrutinized, and negatively criticized when things do not go well." I have definitely seen that happen. It has gotten so when I see poor Epics/Stories or many fuzzy bugs I just claim it will take 6 months. If they insist on a better 'estimate' then I state it will take time and research to refine it. "Feature flags, a way of enabling and disabling features, may be introduced to improve reliability, but “too many flags mean there are too many combinations,” Guler writes, so that proper testing is difficult." Proper testing? If that was the only problem it would be great. I have seen a case where the 'feature' flag was so old no one even knew what it was for. Even looking at the code did not make it clear. In many other cases if documentation existed it was so minimal that it was hard to tell what it was for or even how to use it. Then of course there was the problem that when a new feature flag was turned on any and every problem after that was blamed on the flag. Even when it was obvious that it could not have an impact. "Pair programming, where two developers sit together and work on the same code, is a “brand of torture” and “highly distracting,” " I always figured it was just a certain way to significantly reduce my productivity. But that description fits well. However what the article doesn't mention is that there is nothing better.
-
From CP newsletter Agile process can spur micromanagement and poorly maintained code, says ex-Google software engineer • DEVCLASS[^] Article that is commenting on a book which reflects on Agile. "Estimates of how long work will take become deadlines and engineers feel untrusted, scrutinized, and negatively criticized when things do not go well." I have definitely seen that happen. It has gotten so when I see poor Epics/Stories or many fuzzy bugs I just claim it will take 6 months. If they insist on a better 'estimate' then I state it will take time and research to refine it. "Feature flags, a way of enabling and disabling features, may be introduced to improve reliability, but “too many flags mean there are too many combinations,” Guler writes, so that proper testing is difficult." Proper testing? If that was the only problem it would be great. I have seen a case where the 'feature' flag was so old no one even knew what it was for. Even looking at the code did not make it clear. In many other cases if documentation existed it was so minimal that it was hard to tell what it was for or even how to use it. Then of course there was the problem that when a new feature flag was turned on any and every problem after that was blamed on the flag. Even when it was obvious that it could not have an impact. "Pair programming, where two developers sit together and work on the same code, is a “brand of torture” and “highly distracting,” " I always figured it was just a certain way to significantly reduce my productivity. But that description fits well. However what the article doesn't mention is that there is nothing better.
-
Whatever estimate I give -- add six months.
Some will find your post amusing, but there's a lot of truth in it for larger projects that don't have similar precursors. For those, any estimate without a design is just taking a stab at it. Not only that, any large-scale design that I did always evolved when the code started to speak to me.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
From CP newsletter Agile process can spur micromanagement and poorly maintained code, says ex-Google software engineer • DEVCLASS[^] Article that is commenting on a book which reflects on Agile. "Estimates of how long work will take become deadlines and engineers feel untrusted, scrutinized, and negatively criticized when things do not go well." I have definitely seen that happen. It has gotten so when I see poor Epics/Stories or many fuzzy bugs I just claim it will take 6 months. If they insist on a better 'estimate' then I state it will take time and research to refine it. "Feature flags, a way of enabling and disabling features, may be introduced to improve reliability, but “too many flags mean there are too many combinations,” Guler writes, so that proper testing is difficult." Proper testing? If that was the only problem it would be great. I have seen a case where the 'feature' flag was so old no one even knew what it was for. Even looking at the code did not make it clear. In many other cases if documentation existed it was so minimal that it was hard to tell what it was for or even how to use it. Then of course there was the problem that when a new feature flag was turned on any and every problem after that was blamed on the flag. Even when it was obvious that it could not have an impact. "Pair programming, where two developers sit together and work on the same code, is a “brand of torture” and “highly distracting,” " I always figured it was just a certain way to significantly reduce my productivity. But that description fits well. However what the article doesn't mention is that there is nothing better.
Agile is just Waterfall with a shorter initial release date and a lot of Day 2 features to add, and the wishful thinking of "business involvement". Regardless of which method you choose, if the design, the need for requirements, breaking the solution into smaller bits, and prioritizing those bits aren't part of your plan you're doing it wrong. The true evil of Agile is adding Scrum. Breaking the work into arbitrary and meaningless units of time might help project managers but they are insane for application development. Sure, I'll build you a house in a couple of weeks. Unless it rains. Or a tornado hits and I have to start over. Or half my workers quit. Or ...
There are no solutions, only trade-offs.
- Thomas SowellA day can really slip by when you're deliberately avoiding what you're supposed to do.
- Calvin (Bill Watterson, Calvin & Hobbes) -
From CP newsletter Agile process can spur micromanagement and poorly maintained code, says ex-Google software engineer • DEVCLASS[^] Article that is commenting on a book which reflects on Agile. "Estimates of how long work will take become deadlines and engineers feel untrusted, scrutinized, and negatively criticized when things do not go well." I have definitely seen that happen. It has gotten so when I see poor Epics/Stories or many fuzzy bugs I just claim it will take 6 months. If they insist on a better 'estimate' then I state it will take time and research to refine it. "Feature flags, a way of enabling and disabling features, may be introduced to improve reliability, but “too many flags mean there are too many combinations,” Guler writes, so that proper testing is difficult." Proper testing? If that was the only problem it would be great. I have seen a case where the 'feature' flag was so old no one even knew what it was for. Even looking at the code did not make it clear. In many other cases if documentation existed it was so minimal that it was hard to tell what it was for or even how to use it. Then of course there was the problem that when a new feature flag was turned on any and every problem after that was blamed on the flag. Even when it was obvious that it could not have an impact. "Pair programming, where two developers sit together and work on the same code, is a “brand of torture” and “highly distracting,” " I always figured it was just a certain way to significantly reduce my productivity. But that description fits well. However what the article doesn't mention is that there is nothing better.
I'm not saying it's for everyone but I just fundamentally disagree about pair programming. Though it does require the people involved, particularly the one not driving, to really care about the code/outcome/tech. It's not something I think should just always be done. I just did it for about a year and thought it was very valuable, but the code was all at least a little bit new to everyone involved. Me maybe most of all because I hate web UI so much I'd just avoided anything even adjacent lest I catch a stray. The driver's seat? I don't pretend like I know every bit of code syntax and keyword. I lean on the IDE to get all that right, it's why it exists, so my headspace needn't be concerned with the 7 different overloads of an event handler. Sometimes it can feel embarrassing. So far as feature flags, on the one hand you have TDWTF's "configurable system", and on the other, just... what?Too many combinations making testing difficult? That's like saying wow, the system we designed has all the code-paths to through/to the functionality we wanted. Now we have to test the system we wanted built? What?
-
From CP newsletter Agile process can spur micromanagement and poorly maintained code, says ex-Google software engineer • DEVCLASS[^] Article that is commenting on a book which reflects on Agile. "Estimates of how long work will take become deadlines and engineers feel untrusted, scrutinized, and negatively criticized when things do not go well." I have definitely seen that happen. It has gotten so when I see poor Epics/Stories or many fuzzy bugs I just claim it will take 6 months. If they insist on a better 'estimate' then I state it will take time and research to refine it. "Feature flags, a way of enabling and disabling features, may be introduced to improve reliability, but “too many flags mean there are too many combinations,” Guler writes, so that proper testing is difficult." Proper testing? If that was the only problem it would be great. I have seen a case where the 'feature' flag was so old no one even knew what it was for. Even looking at the code did not make it clear. In many other cases if documentation existed it was so minimal that it was hard to tell what it was for or even how to use it. Then of course there was the problem that when a new feature flag was turned on any and every problem after that was blamed on the flag. Even when it was obvious that it could not have an impact. "Pair programming, where two developers sit together and work on the same code, is a “brand of torture” and “highly distracting,” " I always figured it was just a certain way to significantly reduce my productivity. But that description fits well. However what the article doesn't mention is that there is nothing better.
-
Agile = Adaptive - something we all should be good at
"A little time, a little trouble, your better day" Badfinger
jmaida wrote:
Agile = Adaptive
More often than not, Agile = Adhoc.
-
Agile is just Waterfall with a shorter initial release date and a lot of Day 2 features to add, and the wishful thinking of "business involvement". Regardless of which method you choose, if the design, the need for requirements, breaking the solution into smaller bits, and prioritizing those bits aren't part of your plan you're doing it wrong. The true evil of Agile is adding Scrum. Breaking the work into arbitrary and meaningless units of time might help project managers but they are insane for application development. Sure, I'll build you a house in a couple of weeks. Unless it rains. Or a tornado hits and I have to start over. Or half my workers quit. Or ...
There are no solutions, only trade-offs.
- Thomas SowellA day can really slip by when you're deliberately avoiding what you're supposed to do.
- Calvin (Bill Watterson, Calvin & Hobbes)TNCaver wrote:
Breaking the work into arbitrary and meaningless units of time
I think most people (developers/managers) have difficulty splitting tasks into smaller sub-tasks. Every time we define tasks for a new sprint, we spend some time discussing, arguing, splitting them up. We have tasks that spans a few months, but at every sprint we can actually show progress (designed, coded and tested) in the main production branch.
CI/CD = Continuous Impediment/Continuous Despair
-
jmaida wrote:
Agile = Adaptive
More often than not, Agile = Adhoc.
Amarnath S wrote:
Agile = Adaptive
Agile = "Oh, I just thought of a new feature to add. It'll only take a minute..."
-
Amarnath S wrote:
Agile = Adaptive
Agile = "Oh, I just thought of a new feature to add. It'll only take a minute..."
Or rather: Agile = "Oh, I just thought of a new feature to add that wasn't planned for, so the architecture isn't really suited for it. It'll only take a minute; I'll make a few quick hacks and leave the rest as 'technical debt'..."
Religious freedom is the freedom to say that two plus two make five.
-
TNCaver wrote:
Breaking the work into arbitrary and meaningless units of time
I think most people (developers/managers) have difficulty splitting tasks into smaller sub-tasks. Every time we define tasks for a new sprint, we spend some time discussing, arguing, splitting them up. We have tasks that spans a few months, but at every sprint we can actually show progress (designed, coded and tested) in the main production branch.
CI/CD = Continuous Impediment/Continuous Despair
I've been doing this for nearly forty years, I have no problem breaking tasks into smaller subtasks. But there is a point of diminishing returns in breaking them down into smaller and smaller chunks just to fit them into an arbitrary unit of time where you spend more time splitting them up than it would take to just do the task itself.
There are no solutions, only trade-offs.
- Thomas SowellA day can really slip by when you're deliberately avoiding what you're supposed to do.
- Calvin (Bill Watterson, Calvin & Hobbes)
