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.

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.

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.

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.

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.

https://ludic.mataroa.blog/blog/tossed-salads-and-scrumbled-...

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.

I can't help thinking that the "fungible engineer" concept has done a lot of harm to tech hiring and team structure - of course if you take a guy who most is excited about database optimisation and put him on UI work he won't be passionate about it.

The will to have nice things is a cultural value that some companies just don't have, and if they don't have it for themselves, they won't have it for their customers.

I often join support when they have a call with a customer demonstrating an issue. I also sometimes get to join support when they're on-site for training or similar.

Every time I watch users use our product, I learn so much about what to do and what not to do.

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.

No we don't.

I do my best to fix all open bugs in my own software, tho.

Window dressing in the virtual space! Spending too much time/effort worrying about this nears sabotage, IMO

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.

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.

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.

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.

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

This is the unpleasant truth of the matter. As people who hone our craft and want to take pride in our work, a competent developer’s ethos is at odds with maximizing profit.

Lack of interoperability and vendor lock-in, the move toward SaaS software that you run on behalf of your customers, making network effects fundamental to your value prop, bundling, and the enterprise sales tactics you pointed out are all ways that quality of software has been removed from the conversation entirely.

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

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.

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.

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.

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

How is padding different? It's kind of in the definition of padding. Background colors and click regions are expected to fill the padding but not margins. It's the standard CSS box model.

I was responding to you raising technical questions about how could gap work in some edge cases by saying: "same as padding".

If "gap" is always used like padding, why wouldn't it behave the same?

FTR, I am not sure it's used like that commonly (I've stopped doing CSS UIs before the flexbox came to be): I am not putting that out as a conditional by accident.

Ah.. yeah, that's a big loaded "if". I would say it's not. It's usually used as a gap, like the name implies. Gap and padding play nicely together too, so, if you want both, use both.

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.

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.

All I can say is if this is the common denominator...

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.

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.

Maybe the business just doesn’t value shipping good software all that much - plenty don’t.

As software engineers, it's our job to find exactly the right balance of quality and speed, and strategies to increase quality with no detriment to speed, for what is usually asked of software engineers.

Just like bridge and building engineers do not design those structures to stand up to 1000x the forces that they expect those structures will experience, software engineers need to learn to build with just the right level of complexity to quickly provide quality solution to a business need.

And that's where software engineers really struggle, and agile helps keep that in check, but in practice does not really improve quality. Software engineers should come up with ways to achieve quality with limited resources (just like engineers do everywhere else), and the best teams I worked in or with have!

Yes, the usual tools (JIRA, yuck!) and methodologies (SCRUM, SAFe...) tend to be the problem as they are too prescriptive and too cumbersome and verbose. But they are simply a set of tools to have in one's belt once you hit some common themes, but yes, some take them to heart.

I think true agility is only achievable with a switch to proper outcome-oriented goals which give a lot of liberty to engineering teams. Otherwise, the decision makers on what gets built and how are too far removed from those doing the building.

But that means a mindset shift for engineers (and everybody else!), in that they need to stop thinking about projects, and start thinking about results they achieve.

I do agree that the fact that most get this wrong (I remember a new TL writing down a 30 page document on teams' "agile processes") means that something has been lost in translation, and "Agile" really isn't.

I think it's fair to say that agile method is something to strive for, but never fully realise.

But, what would you propose we call the type of process we strive for, and is there a methodology/strategy you do like?

What are the principles of building software and building high quality software that worked for you in a team?

Yes, we all know that, and every time somebody like me comes along and points out that agile basically sucks this line gets trotted out by somebody or other because that's not the way agile works in any company I've ever worked for.

"Let engineers build software the way they think they should," is an alien concept to all the businesses I've experienced. Now, as it happens, I don't necessarily think engineers should have the last word either, because I've seen too many people disappear down too many rabbit holes and not deliver anything valuable, but clearly agile is broken.

To back this up (since we are presenting anecdotal evidence), I've been at different software engineering teams at engineering companies which did provide this approach to work, and I was at pretend-agile shops too. As a software engineer of more than 20 years.

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

Basically, retrospectives are a common tool, but the goal is to talk about optimizing how you do something, and to keep doing that.

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.

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.

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.

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.

Companies don’t want Software Artisans.

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

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.

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.

Yes. But also HELL NO.

Back when we were a small company and I did a bit of everything, from infrastructure management to support, on top of actually doing dev work, taking to them was the bit I dreaded most at times!

I do occasionally interact with our customers' technology/security teams as part of my remit is dealing with ingesting this party data and pushing information (or making it available to be pulled) the other way. That can be irritating enough, you would not believe the amount of people working in that area that don't properly understand SFTP and, for instance, get thoroughly confused by key based auth.

L1 support was constantly escalating issues that the sysadmin team could not assist with, because they had to do with this software. Either bugs, or new corner cases, or something changed, or they didn’t know how to do something.

We would tell them again and again “we cannot help with operating this software” (it was outside our scope of responsibilities and knowledge - our job was to make sure the computers, servers, and network were all functioning properly).

Despite the team of devs sitting 10 meters away, support would never, ever, talk to them. I think this was probably a dictate from management. It made no sense to me - these support staff were constantly using and helping people use this software, discovering the problems with it and the ways people wanted to use it, and all that feedback just died with them. The devs never interacted with the users of the software at all.

You can probably guess how user-friendly that software was, and how much the users liked it.

In some rare cases there's a direct feedback button in the product itself. Then usually you don't get the response, but at least your remarks are read by someone. Or at least that's the impression I get.

As a positive example - check out the new commit view page in GitHub which they are currently rolling out. There's a Feedback button which goes to a *public* discussion page with voting and comments. One can tell they are really into listening the feedback. And that's something. At least one of the miracles for free.

It sounds like you have organisational failures that prevent you from getting the feedback or iterating on it.

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.

Writing CSS for every checkbox makes no sense in Agile.