9 ms·

This is so lost in Agile. Engineers should get the time to “sand” their products, but we just don’t. If QA doesn’t make a ticket for the space between, it’ll n

This is so lost in Agile. Engineers should get the time to “sand” their products, but we just don’t. If QA doesn’t make a ticket for the space between, it’ll never get fixed. The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. [In fact most companies have such opaque issue boards that as a customer I get so frustrated when I find a small issue or bug and have to spend like 50 hours back and forth to prove it’s a bug and actually get a ticket put in the tracker.]

crazygringo 2y ago
What does agile have to do with anything? You think waterfall explicitly provided time to test out the UI and "sand" it? This is a process that generally requires a product manager to choose to prioritize, together with a capable UX engineer and/or designer. That prioritization can be inserted into any development methodology if you want it. Agile is irrelevant here.
- exe34 2y ago
  I agree that it's not agile, it's the environment that led to agile/scrum being adopted: not that it leads to better products, but that it gives management more control over every decision of how time is spent. essentially they can arbitrarily reduce the time/budget you have, and hire standard code monkeys, etc, to get something made. I think in a company like Steve Job's Apple, where it needs to look perfect (within his tastes), you'd have the time to polish the UI even with agile/scrum - one of the acceptance criteria will be "I spent 5 minutes kicking it and I didn't get any splinters". and then later on when Steve gets a splinter, he'd yell at you for a bit and then create a ticket.
  - JimDabell 2y ago
    > I agree that it's not agile, it's the environment that led to agile/scrum being adopted: not that it leads to better products, but that it gives management more control over every decision of how time is spent. essentially they can arbitrarily reduce the time/budget you have, and hire standard code monkeys, etc, to get something made. This is the exact opposite of agile. Direct from the Agile Manifesto: > Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. > Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. > The best architectures, requirements, and designs emerge from self-organizing teams.
    - exe34 2y ago
      may I refer you to Karl Marx? Communism is perfect, it's just been implemented wrong.
      - pixelready 2y ago
        I’m not sure if you meant this to be sarcastic but I think you’re on to something. In both cases: a rebellion against a soul crushing authoritarian system by writing a manifesto describing a decentralized utopia… which then gets implemented in an authoritarian context and undermined along the way until all that remains is the name and some window dressing from the manifesto. Orwell’s Animal Farm still resonates because of this.
      - JimDabell 2y ago
        If somebody says “be agile; do A, B, and C for better software engineering”, and you do not A, not B, and not C then complain about how terrible agile is, the problem is not with agile. You did something different to agile and got different results, so why are you blaming agile for your own failure? It is, in fact, possible to implement agile wrong – by doing the exact opposite of agile. This is not a rhetorical trick you are catching people out on.
        exe34 2y ago
        If somebody says “be communist; do A, B, and C for better society”, and you do not A, not B, and not C then complain about how terrible communism is, the problem is not with communism. You did something different to communism and got different results, so why are you blaming communism for your own failure? It is, in fact, possible to implement communism wrong – by doing the exact opposite of communism. This is not a rhetorical trick you are catching people out on
    - Viliam1234 2y ago
      Perhaps the problem is that there are few self-organizing teams in companies. Managers needs to justify their salaries.
- 8n4vidtmkvmk 2y ago
  I don't think you even need PMs and UX to be involved here. Let the eng get a little bored and they'll find stuff to fix. The way it actually works though is we set some arbitrary impossible deadline, rush to meet it, creating a wake of tech debt, launch, and then straight on to the next thing.
  - mlnj 2y ago
    The best way to build products I've found is to 1. hire passionate engineers. 2. give engineers enough room to breath and collaborate on the product. Every project that uses Agile defeats 2. I'm not saying that Agile is the reason for this but after 15 years of seeing this repeatedly I'm very wary of places which place Agile as a component of their culture.
    - robocat 2y ago
      An interesting critique of how Agile is practiced: https://ludic.mataroa.blog/blog/tossed-salads-and-scrumbled-eggs/ https://ludic.mataroa.blog/blog/tossed-salads-and-scrumbled-...
  - meiraleal 2y ago
    > Let the eng get a little bored and they'll find stuff to fix. That is the opposite of all engineers I worked with. Engineers easily learn that they should click in the specific part of the element and will forget it is an issue and use it like that for 5 years if nobody point that the issue is making the UX terrible for most users.
    - lol768 2y ago
      I think that says more about the engineers you've been working with than anything else.
      - meiraleal 2y ago
        sure but in some of the cases we were scaling products to millions of users. And it would work great but don't expect engineers to create good UI/UX paying attention to the "small" details. That won't happen naturally.
- xorcist 2y ago
  "Waterfall" is not a development process. But plenty of the processes that give space for planning, also give space for QA. So surely agile, in the broad sense of development processes, is relevant to the comparison.
  - ahoka 2y ago
    A development process is not either Agile or “waterfall” anyway.
  - beryilma 2y ago
    By all "software engineering" books' definition, Waterfall is a software/development process. Good or bad...
    - xorcist 2y ago
      Which book describes "waterfall" as an actual process, as opposed to something generally slow and bad?
      - beryilma 2y ago
        Being an actual process and being slow and bad are not opposites of each other. Literally, every recent software engineering book has a section on the "Waterfall Process". Nobody claims waterfall is good, but it is a software development process.
- jurgenkesker 2y ago
  Agree, we have some time in sprints to do whatever we want, and then you finally can fix those minor annoyances that are probably the users annoyance too. But in general I think more time should be there reserved for it. It's now once in x sprints. When working on my own apps it's really obvious that non focused time leads to lots of improvements. Instead of only the business wishes. In that regard it seems that the potential of a dev is a bit diminished when you don't have time to do things according to your own priorities.
- raincole 2y ago
  It's just a general romanticization of how programmers work: if we have more time we'll fix everything. No we don't.
  - ungamedplayer 2y ago
    You do not speak for me. I think but can't prove that you don't even speak for most programmers.
    - meiraleal 2y ago
      He is not speaking for me but all enterprise projects I worked was like that. When devs (me included) run out of high priority tasks we ask or are directed to more high priority tasks, not fix the minor label/input issue, or the border of the disabled button in resolutions smaller than 400px, or whatever the PM/Scrum master didn't prioritize. Tired of bad management, developers just do what master Jira tell us to do. I do my best to fix all open bugs in my own software, tho.
- bravetraveler 2y ago
  I think the key to your post is that waterfall or agile is irrelevant if you're getting work done and setting priorities Window dressing in the virtual space! Spending too much time/effort worrying about this nears sabotage, IMO
- noisy_boy 2y ago
  Agile is relevant here because it has been adopted almost universally as a shovel to push more things on the programmer's back without much care to the quality of the changes being done. Sure, it is not to be blamed as per Agile manifesto but how many companies are adhering to the manifesto? It is how it is used, not what it was used for.
  - beryilma 2y ago
    > Sure, it is not to be blamed as per Agile manifesto but how many companies are adhering to the manifesto? Increasingly, I am also blaming the Agile Manifesto for causing the mess we are all in. Given current business tendencies, the authors should have probably foreseen the future consequences of their wishy-washy manifesto declarations. I think "true Agile has never been implemented" should not absolve them from assuming some responsibility.
- richardlblair 2y ago
  Agile isn't entirely irrelevant, it's also not the main issue. It's a cultural one. If someone tells me they work on an 'Agile Development' team my immediate perception is that they are a culture of cargo culting and bike shedding, without putting a ton of thought or care into their product, process, or users. These systems are designed to maximize output, not the quality of the output. Management is likely out of touch with the demands of creating a high quality product. This leads to misalignment with the development team and probably the business needs. Most businesses need a higher quality product than they have. Some don't, though. In those circumstances it doesn't really matter - I recommend avoiding these places like the plague.
  - Viliam1234 2y ago
    Business is trying to maximize money. It seems like quality has much less of an impact on sales than many of us would wish. I am not sure why it is like that, but as long as it is... it is a financially rational decision to throw unpolished products on the market as fast as possible. It would be easy to blame the customers. But let's look in the mirror -- how do I make purchase decisions as a customer? Actually, not a good example, because I usually don't buy software. OK, I buy Windows, but... I don't feel like I have a choice between more polished and less polished versions of Windows. Other than that, I use free software. When I use software at work, someone else made the decision and I had zero input. And that kind of software usually sucks (now I am thinking of Confluence, Jira, and other user-hostile monstrosities). So I guess a part of the answer is that if you sell software to business, there is no need to make it nice, because the people who decide whether the company buys it are not the ones who will be stuck with using it.
    - __MatrixMan__ 2y ago
      I wish users more aggressive about their software. At least once a week I hear something along the lines of: > I'm not a technology person, so I can't make X do Y It would be so much better if the go to response was: > This technology sucks, so I can't make X do Y. And if it can't even manage to make Y easy, then I'm sure not going to trust it with Z, and I'm going to tell my friends that they shouldn't either. If the business types need to be reminded that the quality problem is hurting them, then we should coordinate among ourselves to ensure that it hurts even more until they notice.
- osigurdson 2y ago
  I legitimately question if waterfall was ever practiced beyond a very small niche of projects.
necovek 2y ago
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.
exe34 2y ago
> QA doesn’t make a ticket for the space between, it’ll never get fixed. it'll be a low priority ticket with a very large tshirt size because the product manager doesn't want it done and the newbie who estimated it doesn't know what's going on, so it'll take a very long time to figure out.
whazor 2y ago
You can recommend adding analytics to all your flows. Then recommend some of these sanding tasks in order to improve metrics such as drop-off rate. Managers are more inclined to say yes when there is data involved.
bl4ckm0r3 2y ago
priority matters though, if you want to go full Apple with UI/UX then you need to lock the UI/UX for years, like Apple does, and refine every little thing to bring a fully ecstatic UX to the user. Or accept that most users won't notice that or wouldn't mind it behaving like that and build new features that will bring useful behaviours to the app (and revenue to the company). If you have to spend 50 hours to explain why it's a bug, most likely only you care about it. In some cases it may matter to be THAT precise with UI/UX and it's cool, not saying i don't appreciate quality but you can't have everything. One thing I'd like to point out is that most of the time it isn't even a matter of priority, lots of dev energy gets wasted in useless refactors and picking "the right library/framework" and building the "next outdated design library", instead of being used to improve things ;)
- martinsnow 2y ago
  Apple does many things right but things like Mail.app got thrown to the side for years. There's still many odd utilities here and there that have not seen any love like grapher.
7bit 2y ago
> The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. Man, Discord does have a "posts" feature that works similar like a forum. If you draft a text there, the HOME/END keys are all messed up and you can't select text with shift, or move by word holding CTRL (I don't remember the specifics at the moment). I have reported that a couple of times over the past 3 years, because that makes the drafting text *extremely* difficult and frustrating. As a web dev myself, I wonder how this even broke in the first place. Meaning, I wonder what kind of incompetency is needed to break something, that works out of the box. Anyhow, this should be a fix that cannot possibly take longer than 30 minutes to fix and would immediately make the user experience 1000 times better for everyone. Yet, the bug is still there 3 years after reporting it. I also reported a bug in Teams, where you cannot use the HOME/END keys in the phone number input, to Microsoft, through Premiere Support. The reply was: This works as designed. I am not surprised that customers don't report these kind of bugs any longer, because neither the employees/developers, nor the company doesn't give a shit anyway.
ahoka 2y ago
It’s more of the artifact of ticket centric development, so I would blame Jira and the like before “programming self help” methodologies.
2024user 2y ago
This is so true. I'm the lead developer for a product and we have loads of small issues all over the place. It is not a great feeling to be responsible for something while also not having any power to fix it. From the business point of view, why would they spend time and money on fixing these things unless it's hurting sales or brand? Long term it likely does affect the brand but most people will have moved role/company in 5 years so don't care.
- dustingetz 2y ago
  it is hurting sales and brand, the underlying problem is that to dramatically increase performance requires recomping both the tech team and the management and likely also the executives whose decisions shape and limit the org in the first place. In any org, the #1 priority for everyone involved is to keep their salary flowing, which means not replacing themselves with someone better.
- sutra_on 2y ago
  This sounds like a lead/architect issue. If you can't roll out a custom UI component library, use one of several mature libraries that already handles these cases. Accumulating tens or hundreds of thousands of lines of UI tech debt is not an Agile issue.
  - 2024user 2y ago
    Can you explain this further? What library are you talking about?
  - davedx 2y ago
    Here is the correct answer to this, buried in the comments.
- itronitron 2y ago
  Why do you not have any power to fix it?
  - 2024user 2y ago
jagged-chisel 2y ago
I feel like this goes along with the recent Artisan Software discussion on HN. Companies don’t want Software Artisans.
- itronitron 2y ago
  Thanks, I think I just discovered my new job title :)
abbadadda 2y ago
> [In fact most companies have such opaque issue boards that as a customer I get so frustrated when I find a small issue or bug and have to spend like 50 hours back and forth to prove it’s a bug and actually get a ticket put in the tracker.] Agree wholeheartedly. Back & forth emails, screenshots, Q&A (what version are you on?), etc. The number of times I make it to checkout on the last step and something breaks on a certain version of a browser
ibash 2y ago
> The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. I report a lot of bugs. But it seems like a lot of customer support people view their jobs as “protect engineers from bug reports and deflect responsibility”. That’s if you get a response at all.
- swiftcoder 2y ago
  In most companies customer support doesn't have any authority to retask engineers. Maybe if a customer reports a security issue, or a truly application-breaking bug. Otherwise all that customer feedback just gets rolled up into a slide deck once per quarter, and ignored
  - __MatrixMan__ 2y ago
    A neat quirk of having an open source saas product is that really it's customer support that's the product (after all, you can get the software for free). I think it makes for a higher percentage of tickets that are directly related to user experience--although there's still plenty of make-sales-happy type tickets too: gotta put a really shiny bezel around the open source thing.
- Viliam1234 2y ago
  In my experience, it can make a huge difference if the developers are allowed to talk directly to the users of their product. The users tell them which parts of the product hurt them most, and the developers find a way to fix that. If instead the communication is something like "the end users give information to their manager, their manager gives information to our analyst, our analyst gives information to our manager, our manager creates Jira tasks for us", there is often a lot of information lost at every step. For example, once my team made a web application that allowed users to edit some forms. When we asked how many rows there will on a form, we got an answer "five, on average". So we made forms that supported unlimited number of lines, tested them with about 10 rows, everything worked, we considered our job well done. One day, we met a guy who actually used the software. He complained about how it sucks, that validating or saving the form takes forever, that he sometimes loses data because of a timeout, etc. It turned out that although most of the forms contained about five rows, some of them actually contained thousands of rows. And yes, with over ten thousand rows in a form, on a bad day the web application lost the data because of a timeout. The developers were quite shocked. We complained about the analysis, but the analyst insisted that the average number of rows per form was about five, so the analysis was not wrong. (Technically correct; the best kind of correct.) Had we known this in advance, we certainly would have chosen a different web framework, but now it was too late to rewrite everything from scratch. So we just did what we could at this moment, some ugly hack like validating only 1000 rows at a time, so the end user had to push the validation button multiple times for very long forms or something like that, but at least he didn't get a timeout. The hack took about a week to implement and test, and the end user was happy, because it was a huge improvement over the previous situation. The management still insisted that developers meeting with the end users were wasting time. There were Jira tasks waiting to do, no time for chat.
madeofpalk 2y ago
I don’t know what we’re calling “agile”, but it’s explicitly supposed to capture this. You use the product, get feedback (from either yourself or users), and iterate on it. It sounds like you have organisational failures that prevent you from getting the feedback or iterating on it.
corytheboyd 2y ago
When it’s something this trivially small, why don’t you just… do it? So long as you can demonstrate your ability to deliver on “real” work, why not just knock these tiny things out too if you can? Work it into an adjacent change if that comes up. “But my manager and PM and CEO all say this is ILLEGAL TO DO” always seems to be the answer… but if your company isn’t completely rotten to the core with toxic waste, I don’t think anyone is going to axe you for making small microscopic incremental product improvements…
- etherealG 2y ago
  Because it’s not small. Doing what the article describes takes a very significant amount of time. Especially compared to a much more directly estimated and measurable action like “add x feature”. Doing what is described halfway will likely return poor results since noticing the subtle things like the example given only happens when trying many times with a tendency to try random things that you didn’t before. Who purposefully clicks somewhere they never did before, QA people. Most engineers are not QA, and they don’t even begin to think in a way that leads them to try things that they didn’t before just to try to find a few pixels of unclickable UI. Your assumption that the kind of work described is small is a much bigger problem than any so called assumption that blaming the PM and CEO is at fault.
janaagaard 2y ago
> This is so lost in Agile. My personal experience is that you have to blame the people and not the method. I would define my current project as very agile in the sense that we only have details plan for what to do a week ahead at the time. Each week the team has an hour long meeting where we present what we have done, and discuss if it's good enough. If something like a hover region is found to be wrong it will get fixed for next week. If you find this issue while working on something else, you make task and PR and just fix these smalls things. I feel like this way of working is what what meant by the people who invented the idea of making software development agile.
sutra_on 2y ago
Not sure what this has to do with Agile. Companies that move fast and have complex UI almost always use React (or similar) and a UI component library that handles all these edge cases. Writing CSS for every checkbox makes no sense in Agile.
deleted 2y ago
[deleted]
ainiriand 2y ago
You guys have QA?

crazygringo 2y ago

What does agile have to do with anything? You think waterfall explicitly provided time to test out the UI and "sand" it? This is a process that generally requires a product manager to choose to prioritize, together with a capable UX engineer and/or designer. That prioritization can be inserted into any development methodology if you want it. Agile is irrelevant here.

exe34 2y ago
I agree that it's not agile, it's the environment that led to agile/scrum being adopted: not that it leads to better products, but that it gives management more control over every decision of how time is spent. essentially they can arbitrarily reduce the time/budget you have, and hire standard code monkeys, etc, to get something made. I think in a company like Steve Job's Apple, where it needs to look perfect (within his tastes), you'd have the time to polish the UI even with agile/scrum - one of the acceptance criteria will be "I spent 5 minutes kicking it and I didn't get any splinters". and then later on when Steve gets a splinter, he'd yell at you for a bit and then create a ticket.
- JimDabell 2y ago
  > I agree that it's not agile, it's the environment that led to agile/scrum being adopted: not that it leads to better products, but that it gives management more control over every decision of how time is spent. essentially they can arbitrarily reduce the time/budget you have, and hire standard code monkeys, etc, to get something made. This is the exact opposite of agile. Direct from the Agile Manifesto: > Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. > Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. > The best architectures, requirements, and designs emerge from self-organizing teams.
  - exe34 2y ago
    may I refer you to Karl Marx? Communism is perfect, it's just been implemented wrong.
    - pixelready 2y ago
      I’m not sure if you meant this to be sarcastic but I think you’re on to something. In both cases: a rebellion against a soul crushing authoritarian system by writing a manifesto describing a decentralized utopia… which then gets implemented in an authoritarian context and undermined along the way until all that remains is the name and some window dressing from the manifesto. Orwell’s Animal Farm still resonates because of this.
    - JimDabell 2y ago
      If somebody says “be agile; do A, B, and C for better software engineering”, and you do not A, not B, and not C then complain about how terrible agile is, the problem is not with agile. You did something different to agile and got different results, so why are you blaming agile for your own failure? It is, in fact, possible to implement agile wrong – by doing the exact opposite of agile. This is not a rhetorical trick you are catching people out on.
      - exe34 2y ago
        If somebody says “be communist; do A, B, and C for better society”, and you do not A, not B, and not C then complain about how terrible communism is, the problem is not with communism. You did something different to communism and got different results, so why are you blaming communism for your own failure? It is, in fact, possible to implement communism wrong – by doing the exact opposite of communism. This is not a rhetorical trick you are catching people out on
  - Viliam1234 2y ago
    Perhaps the problem is that there are few self-organizing teams in companies. Managers needs to justify their salaries.
8n4vidtmkvmk 2y ago
I don't think you even need PMs and UX to be involved here. Let the eng get a little bored and they'll find stuff to fix. The way it actually works though is we set some arbitrary impossible deadline, rush to meet it, creating a wake of tech debt, launch, and then straight on to the next thing.
- mlnj 2y ago
  The best way to build products I've found is to 1. hire passionate engineers. 2. give engineers enough room to breath and collaborate on the product. Every project that uses Agile defeats 2. I'm not saying that Agile is the reason for this but after 15 years of seeing this repeatedly I'm very wary of places which place Agile as a component of their culture.
  - robocat 2y ago
    An interesting critique of how Agile is practiced: https://ludic.mataroa.blog/blog/tossed-salads-and-scrumbled-eggs/ https://ludic.mataroa.blog/blog/tossed-salads-and-scrumbled-...
- meiraleal 2y ago
  > Let the eng get a little bored and they'll find stuff to fix. That is the opposite of all engineers I worked with. Engineers easily learn that they should click in the specific part of the element and will forget it is an issue and use it like that for 5 years if nobody point that the issue is making the UX terrible for most users.
  - lol768 2y ago
    I think that says more about the engineers you've been working with than anything else.
    - meiraleal 2y ago
      sure but in some of the cases we were scaling products to millions of users. And it would work great but don't expect engineers to create good UI/UX paying attention to the "small" details. That won't happen naturally.
xorcist 2y ago
"Waterfall" is not a development process. But plenty of the processes that give space for planning, also give space for QA. So surely agile, in the broad sense of development processes, is relevant to the comparison.
- ahoka 2y ago
  A development process is not either Agile or “waterfall” anyway.
- beryilma 2y ago
  By all "software engineering" books' definition, Waterfall is a software/development process. Good or bad...
  - xorcist 2y ago
    Which book describes "waterfall" as an actual process, as opposed to something generally slow and bad?
    - beryilma 2y ago
      Being an actual process and being slow and bad are not opposites of each other. Literally, every recent software engineering book has a section on the "Waterfall Process". Nobody claims waterfall is good, but it is a software development process.
jurgenkesker 2y ago
Agree, we have some time in sprints to do whatever we want, and then you finally can fix those minor annoyances that are probably the users annoyance too. But in general I think more time should be there reserved for it. It's now once in x sprints. When working on my own apps it's really obvious that non focused time leads to lots of improvements. Instead of only the business wishes. In that regard it seems that the potential of a dev is a bit diminished when you don't have time to do things according to your own priorities.
raincole 2y ago
It's just a general romanticization of how programmers work: if we have more time we'll fix everything. No we don't.
- ungamedplayer 2y ago
  You do not speak for me. I think but can't prove that you don't even speak for most programmers.
  - meiraleal 2y ago
    He is not speaking for me but all enterprise projects I worked was like that. When devs (me included) run out of high priority tasks we ask or are directed to more high priority tasks, not fix the minor label/input issue, or the border of the disabled button in resolutions smaller than 400px, or whatever the PM/Scrum master didn't prioritize. Tired of bad management, developers just do what master Jira tell us to do. I do my best to fix all open bugs in my own software, tho.
bravetraveler 2y ago
I think the key to your post is that waterfall or agile is irrelevant if you're getting work done and setting priorities Window dressing in the virtual space! Spending too much time/effort worrying about this nears sabotage, IMO
noisy_boy 2y ago
Agile is relevant here because it has been adopted almost universally as a shovel to push more things on the programmer's back without much care to the quality of the changes being done. Sure, it is not to be blamed as per Agile manifesto but how many companies are adhering to the manifesto? It is how it is used, not what it was used for.
- beryilma 2y ago
  > Sure, it is not to be blamed as per Agile manifesto but how many companies are adhering to the manifesto? Increasingly, I am also blaming the Agile Manifesto for causing the mess we are all in. Given current business tendencies, the authors should have probably foreseen the future consequences of their wishy-washy manifesto declarations. I think "true Agile has never been implemented" should not absolve them from assuming some responsibility.
richardlblair 2y ago
Agile isn't entirely irrelevant, it's also not the main issue. It's a cultural one. If someone tells me they work on an 'Agile Development' team my immediate perception is that they are a culture of cargo culting and bike shedding, without putting a ton of thought or care into their product, process, or users. These systems are designed to maximize output, not the quality of the output. Management is likely out of touch with the demands of creating a high quality product. This leads to misalignment with the development team and probably the business needs. Most businesses need a higher quality product than they have. Some don't, though. In those circumstances it doesn't really matter - I recommend avoiding these places like the plague.
- Viliam1234 2y ago
  Business is trying to maximize money. It seems like quality has much less of an impact on sales than many of us would wish. I am not sure why it is like that, but as long as it is... it is a financially rational decision to throw unpolished products on the market as fast as possible. It would be easy to blame the customers. But let's look in the mirror -- how do I make purchase decisions as a customer? Actually, not a good example, because I usually don't buy software. OK, I buy Windows, but... I don't feel like I have a choice between more polished and less polished versions of Windows. Other than that, I use free software. When I use software at work, someone else made the decision and I had zero input. And that kind of software usually sucks (now I am thinking of Confluence, Jira, and other user-hostile monstrosities). So I guess a part of the answer is that if you sell software to business, there is no need to make it nice, because the people who decide whether the company buys it are not the ones who will be stuck with using it.
  - __MatrixMan__ 2y ago
    I wish users more aggressive about their software. At least once a week I hear something along the lines of: > I'm not a technology person, so I can't make X do Y It would be so much better if the go to response was: > This technology sucks, so I can't make X do Y. And if it can't even manage to make Y easy, then I'm sure not going to trust it with Z, and I'm going to tell my friends that they shouldn't either. If the business types need to be reminded that the quality problem is hurting them, then we should coordinate among ourselves to ensure that it hurts even more until they notice.
osigurdson 2y ago
I legitimately question if waterfall was ever practiced beyond a very small niche of projects.

necovek 2y ago

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.

exe34 2y ago

> QA doesn’t make a ticket for the space between, it’ll never get fixed. it'll be a low priority ticket with a very large tshirt size because the product manager doesn't want it done and the newbie who estimated it doesn't know what's going on, so it'll take a very long time to figure out.

whazor 2y ago

You can recommend adding analytics to all your flows. Then recommend some of these sanding tasks in order to improve metrics such as drop-off rate. Managers are more inclined to say yes when there is data involved.

bl4ckm0r3 2y ago

priority matters though, if you want to go full Apple with UI/UX then you need to lock the UI/UX for years, like Apple does, and refine every little thing to bring a fully ecstatic UX to the user. Or accept that most users won't notice that or wouldn't mind it behaving like that and build new features that will bring useful behaviours to the app (and revenue to the company). If you have to spend 50 hours to explain why it's a bug, most likely only you care about it. In some cases it may matter to be THAT precise with UI/UX and it's cool, not saying i don't appreciate quality but you can't have everything. One thing I'd like to point out is that most of the time it isn't even a matter of priority, lots of dev energy gets wasted in useless refactors and picking "the right library/framework" and building the "next outdated design library", instead of being used to improve things ;)

martinsnow 2y ago
Apple does many things right but things like Mail.app got thrown to the side for years. There's still many odd utilities here and there that have not seen any love like grapher.

7bit 2y ago

> The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. Man, Discord does have a "posts" feature that works similar like a forum. If you draft a text there, the HOME/END keys are all messed up and you can't select text with shift, or move by word holding CTRL (I don't remember the specifics at the moment). I have reported that a couple of times over the past 3 years, because that makes the drafting text *extremely* difficult and frustrating. As a web dev myself, I wonder how this even broke in the first place. Meaning, I wonder what kind of incompetency is needed to break something, that works out of the box. Anyhow, this should be a fix that cannot possibly take longer than 30 minutes to fix and would immediately make the user experience 1000 times better for everyone. Yet, the bug is still there 3 years after reporting it. I also reported a bug in Teams, where you cannot use the HOME/END keys in the phone number input, to Microsoft, through Premiere Support. The reply was: This works as designed. I am not surprised that customers don't report these kind of bugs any longer, because neither the employees/developers, nor the company doesn't give a shit anyway.

ahoka 2y ago

It’s more of the artifact of ticket centric development, so I would blame Jira and the like before “programming self help” methodologies.

2024user 2y ago

This is so true. I'm the lead developer for a product and we have loads of small issues all over the place. It is not a great feeling to be responsible for something while also not having any power to fix it. From the business point of view, why would they spend time and money on fixing these things unless it's hurting sales or brand? Long term it likely does affect the brand but most people will have moved role/company in 5 years so don't care.

dustingetz 2y ago
it is hurting sales and brand, the underlying problem is that to dramatically increase performance requires recomping both the tech team and the management and likely also the executives whose decisions shape and limit the org in the first place. In any org, the #1 priority for everyone involved is to keep their salary flowing, which means not replacing themselves with someone better.
sutra_on 2y ago
This sounds like a lead/architect issue. If you can't roll out a custom UI component library, use one of several mature libraries that already handles these cases. Accumulating tens or hundreds of thousands of lines of UI tech debt is not an Agile issue.
- 2024user 2y ago
  Can you explain this further? What library are you talking about?
- davedx 2y ago
  Here is the correct answer to this, buried in the comments.
itronitron 2y ago
Why do you not have any power to fix it?
- 2024user 2y ago

jagged-chisel 2y ago

I feel like this goes along with the recent Artisan Software discussion on HN. Companies don’t want Software Artisans.

itronitron 2y ago
Thanks, I think I just discovered my new job title :)

abbadadda 2y ago

> [In fact most companies have such opaque issue boards that as a customer I get so frustrated when I find a small issue or bug and have to spend like 50 hours back and forth to prove it’s a bug and actually get a ticket put in the tracker.] Agree wholeheartedly. Back & forth emails, screenshots, Q&A (what version are you on?), etc. The number of times I make it to checkout on the last step and something breaks on a certain version of a browser

ibash 2y ago

> The customer probably notices this kind of a thing but it’s a miracle if the customer bothers to report it, and another miracle if it eventually turns into a ticket, and another miracle if someone prioritises it enough to spend time fixing it. I report a lot of bugs. But it seems like a lot of customer support people view their jobs as “protect engineers from bug reports and deflect responsibility”. That’s if you get a response at all.

swiftcoder 2y ago
In most companies customer support doesn't have any authority to retask engineers. Maybe if a customer reports a security issue, or a truly application-breaking bug. Otherwise all that customer feedback just gets rolled up into a slide deck once per quarter, and ignored
- __MatrixMan__ 2y ago
  A neat quirk of having an open source saas product is that really it's customer support that's the product (after all, you can get the software for free). I think it makes for a higher percentage of tickets that are directly related to user experience--although there's still plenty of make-sales-happy type tickets too: gotta put a really shiny bezel around the open source thing.
Viliam1234 2y ago
In my experience, it can make a huge difference if the developers are allowed to talk directly to the users of their product. The users tell them which parts of the product hurt them most, and the developers find a way to fix that. If instead the communication is something like "the end users give information to their manager, their manager gives information to our analyst, our analyst gives information to our manager, our manager creates Jira tasks for us", there is often a lot of information lost at every step. For example, once my team made a web application that allowed users to edit some forms. When we asked how many rows there will on a form, we got an answer "five, on average". So we made forms that supported unlimited number of lines, tested them with about 10 rows, everything worked, we considered our job well done. One day, we met a guy who actually used the software. He complained about how it sucks, that validating or saving the form takes forever, that he sometimes loses data because of a timeout, etc. It turned out that although most of the forms contained about five rows, some of them actually contained thousands of rows. And yes, with over ten thousand rows in a form, on a bad day the web application lost the data because of a timeout. The developers were quite shocked. We complained about the analysis, but the analyst insisted that the average number of rows per form was about five, so the analysis was not wrong. (Technically correct; the best kind of correct.) Had we known this in advance, we certainly would have chosen a different web framework, but now it was too late to rewrite everything from scratch. So we just did what we could at this moment, some ugly hack like validating only 1000 rows at a time, so the end user had to push the validation button multiple times for very long forms or something like that, but at least he didn't get a timeout. The hack took about a week to implement and test, and the end user was happy, because it was a huge improvement over the previous situation. The management still insisted that developers meeting with the end users were wasting time. There were Jira tasks waiting to do, no time for chat.

madeofpalk 2y ago

I don’t know what we’re calling “agile”, but it’s explicitly supposed to capture this. You use the product, get feedback (from either yourself or users), and iterate on it. It sounds like you have organisational failures that prevent you from getting the feedback or iterating on it.

corytheboyd 2y ago

When it’s something this trivially small, why don’t you just… do it? So long as you can demonstrate your ability to deliver on “real” work, why not just knock these tiny things out too if you can? Work it into an adjacent change if that comes up. “But my manager and PM and CEO all say this is ILLEGAL TO DO” always seems to be the answer… but if your company isn’t completely rotten to the core with toxic waste, I don’t think anyone is going to axe you for making small microscopic incremental product improvements…

etherealG 2y ago
Because it’s not small. Doing what the article describes takes a very significant amount of time. Especially compared to a much more directly estimated and measurable action like “add x feature”. Doing what is described halfway will likely return poor results since noticing the subtle things like the example given only happens when trying many times with a tendency to try random things that you didn’t before. Who purposefully clicks somewhere they never did before, QA people. Most engineers are not QA, and they don’t even begin to think in a way that leads them to try things that they didn’t before just to try to find a few pixels of unclickable UI. Your assumption that the kind of work described is small is a much bigger problem than any so called assumption that blaming the PM and CEO is at fault.

janaagaard 2y ago

> This is so lost in Agile. My personal experience is that you have to blame the people and not the method. I would define my current project as very agile in the sense that we only have details plan for what to do a week ahead at the time. Each week the team has an hour long meeting where we present what we have done, and discuss if it's good enough. If something like a hover region is found to be wrong it will get fixed for next week. If you find this issue while working on something else, you make task and PR and just fix these smalls things. I feel like this way of working is what what meant by the people who invented the idea of making software development agile.

sutra_on 2y ago

Not sure what this has to do with Agile. Companies that move fast and have complex UI almost always use React (or similar) and a UI component library that handles all these edge cases. Writing CSS for every checkbox makes no sense in Agile.

deleted 2y ago

[deleted]

ainiriand 2y ago

You guys have QA?