Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sanding UI

blog.jim-nielsen.com

Post reply on HN
Print view View original

321–330 of 414 posts

Re: Sanding UI

#321

Post by necovek »

madeofpalk wrote: post #291
bartread wrote: post #173

Earlier quoted context omitted.

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, c…

Fixing “agile” is not the point. Find a process (and iterate on it) that helps you ship good software. I think there’s a bunch of stuff in the agile toolbox that’s helpful. Pick and mix that works for you. Maybe the business just doesn’t value shipping good software all that much - plenty don’t.

This is something those wishing to build higher quality software often forget: business mostly care about return on investment.

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!

Re: Sanding UI

#322

Post by davedx »

sutra_on wrote: post #312
2024user wrote: post #202

Earlier quoted context omitted.

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/comp…

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.

Here is the correct answer to this, buried in the comments.

Re: Sanding UI

#323

Post by itronitron »

2024user wrote: post #202
aetherspawn wrote: post #83

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

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/comp…

Why do you not have any power to fix it?

Re: Sanding UI

#324

Post by necovek »

8n4vidtmkvmk wrote: post #138
necovek wrote: post #131

Earlier quoted context omitted.

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

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…

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.

Re: Sanding UI

#325

Post by necovek »

Viliam1234 wrote: post #282
necovek wrote: post #131

Earlier quoted context omitted.

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

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

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.

Re: Sanding UI

#326

Post by pixelready »

exe34 wrote: post #251
JimDabell wrote: post #224

Earlier quoted context omitted.

> 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 pro…

may I refer you to Karl Marx? Communism is perfect, it's just been implemented wrong.

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.

Re: Sanding UI

#327

Post by radium3d »

richardlblair wrote: post #214
crazygringo wrote: post #86

Earlier quoted context omitted.

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.

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 to…

It's the balance between staying in business, going out of business, reducing employee count, increasing employee count, etc. Also how much unpaid overtime is the dev willing to put into the project. That seems to be what causes most of us to not be allowed to put in the required time for properly sanding the UI.

Re: Sanding UI

#328

Post by beryilma »

xorcist wrote: post #171
crazygringo wrote: post #86

Earlier quoted context omitted.

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.

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

By all "software engineering" books' definition, Waterfall is a software/development process. Good or bad...

Re: Sanding UI

#329

Post by robocat »

mlnj wrote: post #207
8n4vidtmkvmk wrote: post #141

Earlier quoted context omitted.

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.

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.

An interesting critique of how Agile is practiced:

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

Re: Sanding UI

#330

Post by itronitron »

sutra_on wrote: post #314
mlnj wrote: post #208

Earlier quoted context omitted.

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

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 handli…

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.

Post reply on HN