3 ms·

The idea behind "agile" is to recognize when something isn't working and improve it. You obviously have a process that does not serve your customers' needs: wo

The idea behind "agile" is to recognize when something isn't working and improve it. You obviously have a process that does not serve your customers' needs: work with your team to fix it. If you have SCRUM ceremonies, a retrospective is where you can raise it, but really, any time works (retrospectives are to purposely look at the past few weeks, but things you notice along the way, look to solve along the way).

mrguyorama 2y ago
Process gets dictated from above. Laborers like coders do not get the authority to do that stuff. Agile is a failure because it imagines this pixie dreamland where every replaceable cog in the machine somehow has the ability to dramatically change how the machine operates. We don't. We don't get to design the machine we are a part of because that's not how capitalism works.
8n4vidtmkvmk 2y ago
I don't buy this. Not serving the customer's needs? Is this the paying customer's #1 feature request/bug fix? It's probably some poor random sap that has to use the software and notices it. There's different kinds of software. The software I work on now, the advertisers are the real customers, not the users of the app. So the users have basically zero buying power unless they stop using the app and we need to attract them back, but a small bug like this isn't going to do that. The other kind of app you sell to a company. They want a good app that meets their business needs, but the ones making purchasing decisions still aren't the Frontline staff that have to use it. And there's no way a bug like this is making it up their internal chain and then over to the vendor. And even if all of that happens, I have trouble believing this would be prioritized in a sprint. The only way anything gets fixed is if by some miracle an eng with the power to fix it either notices himself or if the app is popular enough, someone tweets about it and he happens to read it. It'll never make it through the formal chain. I know this because as an eng who would rather do some sanding then add more useless features... Well, then the PMs wouldn't have anything to do.
- necovek 2y ago
  But that's because you care about the output vs what might bring value to the company. If things never bubble up, does that not mean that this is really a non-issue? You may be surprised, but most useful software is crappy by too many metrics, except for the main one: it gets the job done. And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" that most people would expect? Perhaps an addendum to W3C CSS flexbox spec is a more useful avenue? Fix it once and for everyone.
  - 8n4vidtmkvmk 2y ago
    > If things never bubble up, does that not mean that this is really a non-issue? It's a small issue, not a non-issue. Or some might even be big issues but for a minority of users. They're worth addressing from time to time because they add up. And yes, the app is probably getting the job done, which is all the more reason to start polishing the app and stop bloating it into something it was never meant to be. Focus on what does make the app good and useful. And heck, you can stop hiring thousands of engineers to build useless stuff and start enjoying all the money rolling it. (Of course that doesn't happen because every company needs 'growth' to appease the shareholders, but I digress) > And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" that most people would expect? Perhaps an addendum to W3C CSS flexbox spec is a more useful avenue? Fix it once and for everyone. I certainly wouldn't. There's 2 elements, a radio and a label, and there's a gap between them, exactly as specified in the CSS. Why would you make the gap clickable? How would you even define that? What if it was radio-image-label. The radio is clickable by virtue of being an input, the label is specified as being for that radio. Should we make the image clickable because it's in a line? Or just the gaps adjacent to the radio and label? What if the are other clickable elements next to them, which ones get priority over the gap? There's a lot of issues here, and this isn't a scenario we want to just randomly do what we think is best. That's how we ended up with HTML4 and IE.
    - necovek 2y ago
      You obviously have something against contemporary growth-obsession, but I don't see a relation to agile. Do I need to point out that there are cases where you would have enough profit only to cover running the business (if that) and can't afford to stress over smaller issues? > Why would you make the gap clickable? I already said why: if everyone expects that behaviour (OP obviously did). Just like "sanding your UI" removes rough edges for customers, fixing things in computer languages removes papercuts for developers (customers of the language). Regarding technical challenges, didn't OP switch to padding? How is that different?
devjab 2y ago
The idea behind agile is to sell you training and later consulting once your organisation fails to adopt it in any meaningful way because it’s principles are so vague your culture, will, get it wrong. It’s saying that the people behind the agile alliance and so on aren’t actually working in software engineering. Many haven’t since 20 years before the birth of Python. They’re also famous for handling any form of criticism with “you didn’t understand our principles”. Which to be fair is often completely correct, but maybe it’s because those principles are horrendous? What it has lead to is an industry full of pseudo-jobbers. As others point out… your software engineers, can, do the work if you let them. Even if you don’t, you have no guarantee that your added personal actually catches errors like the ones in this article. Because human testers usually aren’t part of the team in any meaningful way.
bartread 2y ago
Stop drinking the koolaid, will you? I didn't get into software development to spend my entire time focussed on fixing broken processes. I'd bet almost none of us did. I got into it because I like building software and, more than that, I like building high quality software. At the end of the day it comes down to this: I've worked a bunch of different places over 25 years. I've seen a lot of different processes but, certainly for the past 17 or 18 years, mostly some flavour of agile that most closely aligned with Scrum. It's not been that great anywhere, and there are a handful of places it's been outright terrible. Reality check: if agile never gets any better than "not that great" then maybe agile is the problem.
- mlnj 2y ago
  Every single time this gets brought up we see the Agile defenders come up with "It's not agile, it's literally anything else.". All I can say is if this is the common denominator...
  - deleted 2y ago
    [deleted]
  - rrr_oh_man 2y ago
    "It's not real communism..."
  - sutra_on 2y ago
    I worked in companies that are committed to Agile and companies that have a completely custom planning and development process. I don't understand your argument. What process in Agile dictates shipping subpar UI? Build, test, file bugs, resolve bug. You can do this within any framework. Or, better, develop a high quality UI component library instead of asking a junior engineer to write CSS for correct checkbox handling.
    - itronitron 2y ago
      Particularly with Scrum, people get hung up on the 'rules' of the 'process'. For example, following the rules of Scrum, if a developer finds a bug, decides to fix it, and wants to commit the fix such that it can be tested and closed out then that bug needs to first be assigned to the current sprint before the developer can touch it. It's extremely constraining and antagonistic towards shipping good software.
Viliam1234 2y ago
Fun fact: most companies doing "scrum" actually don't have retrospectives. (I understand that this goes completely against the textbook idea of scrum, but there is always the textbook and "the way we do scrum at our company", and those two often have very little in common.)
- necovek 2y ago
  As long as you fix things that don't work or make you less effective, it does not matter if it's a retrospective, or stop-the-line approach, or whatever your nameless approach is. Basically, retrospectives are a common tool, but the goal is to talk about optimizing how you do something, and to keep doing that.

mrguyorama 2y ago

Process gets dictated from above. Laborers like coders do not get the authority to do that stuff. Agile is a failure because it imagines this pixie dreamland where every replaceable cog in the machine somehow has the ability to dramatically change how the machine operates. We don't. We don't get to design the machine we are a part of because that's not how capitalism works.

8n4vidtmkvmk 2y ago

I don't buy this. Not serving the customer's needs? Is this the paying customer's #1 feature request/bug fix? It's probably some poor random sap that has to use the software and notices it. There's different kinds of software. The software I work on now, the advertisers are the real customers, not the users of the app. So the users have basically zero buying power unless they stop using the app and we need to attract them back, but a small bug like this isn't going to do that. The other kind of app you sell to a company. They want a good app that meets their business needs, but the ones making purchasing decisions still aren't the Frontline staff that have to use it. And there's no way a bug like this is making it up their internal chain and then over to the vendor. And even if all of that happens, I have trouble believing this would be prioritized in a sprint. The only way anything gets fixed is if by some miracle an eng with the power to fix it either notices himself or if the app is popular enough, someone tweets about it and he happens to read it. It'll never make it through the formal chain. I know this because as an eng who would rather do some sanding then add more useless features... Well, then the PMs wouldn't have anything to do.

necovek 2y ago
But that's because you care about the output vs what might bring value to the company. If things never bubble up, does that not mean that this is really a non-issue? You may be surprised, but most useful software is crappy by too many metrics, except for the main one: it gets the job done. And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" that most people would expect? Perhaps an addendum to W3C CSS flexbox spec is a more useful avenue? Fix it once and for everyone.
- 8n4vidtmkvmk 2y ago
  > If things never bubble up, does that not mean that this is really a non-issue? It's a small issue, not a non-issue. Or some might even be big issues but for a minority of users. They're worth addressing from time to time because they add up. And yes, the app is probably getting the job done, which is all the more reason to start polishing the app and stop bloating it into something it was never meant to be. Focus on what does make the app good and useful. And heck, you can stop hiring thousands of engineers to build useless stuff and start enjoying all the money rolling it. (Of course that doesn't happen because every company needs 'growth' to appease the shareholders, but I digress) > And to be honest, on the original story, as a software engineer, I would rather consider if this is a better behavior for "gap" that most people would expect? Perhaps an addendum to W3C CSS flexbox spec is a more useful avenue? Fix it once and for everyone. I certainly wouldn't. There's 2 elements, a radio and a label, and there's a gap between them, exactly as specified in the CSS. Why would you make the gap clickable? How would you even define that? What if it was radio-image-label. The radio is clickable by virtue of being an input, the label is specified as being for that radio. Should we make the image clickable because it's in a line? Or just the gaps adjacent to the radio and label? What if the are other clickable elements next to them, which ones get priority over the gap? There's a lot of issues here, and this isn't a scenario we want to just randomly do what we think is best. That's how we ended up with HTML4 and IE.
  - necovek 2y ago
    You obviously have something against contemporary growth-obsession, but I don't see a relation to agile. Do I need to point out that there are cases where you would have enough profit only to cover running the business (if that) and can't afford to stress over smaller issues? > Why would you make the gap clickable? I already said why: if everyone expects that behaviour (OP obviously did). Just like "sanding your UI" removes rough edges for customers, fixing things in computer languages removes papercuts for developers (customers of the language). Regarding technical challenges, didn't OP switch to padding? How is that different?

devjab 2y ago

The idea behind agile is to sell you training and later consulting once your organisation fails to adopt it in any meaningful way because it’s principles are so vague your culture, will, get it wrong. It’s saying that the people behind the agile alliance and so on aren’t actually working in software engineering. Many haven’t since 20 years before the birth of Python. They’re also famous for handling any form of criticism with “you didn’t understand our principles”. Which to be fair is often completely correct, but maybe it’s because those principles are horrendous? What it has lead to is an industry full of pseudo-jobbers. As others point out… your software engineers, can, do the work if you let them. Even if you don’t, you have no guarantee that your added personal actually catches errors like the ones in this article. Because human testers usually aren’t part of the team in any meaningful way.

bartread 2y ago

Stop drinking the koolaid, will you? I didn't get into software development to spend my entire time focussed on fixing broken processes. I'd bet almost none of us did. I got into it because I like building software and, more than that, I like building high quality software. At the end of the day it comes down to this: I've worked a bunch of different places over 25 years. I've seen a lot of different processes but, certainly for the past 17 or 18 years, mostly some flavour of agile that most closely aligned with Scrum. It's not been that great anywhere, and there are a handful of places it's been outright terrible. Reality check: if agile never gets any better than "not that great" then maybe agile is the problem.

mlnj 2y ago
Every single time this gets brought up we see the Agile defenders come up with "It's not agile, it's literally anything else.". All I can say is if this is the common denominator...
- deleted 2y ago
  [deleted]
- rrr_oh_man 2y ago
  "It's not real communism..."
- sutra_on 2y ago
  I worked in companies that are committed to Agile and companies that have a completely custom planning and development process. I don't understand your argument. What process in Agile dictates shipping subpar UI? Build, test, file bugs, resolve bug. You can do this within any framework. Or, better, develop a high quality UI component library instead of asking a junior engineer to write CSS for correct checkbox handling.
  - itronitron 2y ago
    Particularly with Scrum, people get hung up on the 'rules' of the 'process'. For example, following the rules of Scrum, if a developer finds a bug, decides to fix it, and wants to commit the fix such that it can be tested and closed out then that bug needs to first be assigned to the current sprint before the developer can touch it. It's extremely constraining and antagonistic towards shipping good software.

Viliam1234 2y ago

Fun fact: most companies doing "scrum" actually don't have retrospectives. (I understand that this goes completely against the textbook idea of scrum, but there is always the textbook and "the way we do scrum at our company", and those two often have very little in common.)

necovek 2y ago
As long as you fix things that don't work or make you less effective, it does not matter if it's a retrospective, or stop-the-line approach, or whatever your nameless approach is. Basically, retrospectives are a common tool, but the goal is to talk about optimizing how you do something, and to keep doing that.