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

201–210 of 414 posts

Re: Sanding UI

#201

Post by noisy_boy »

crazygringo wrote: post #86
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. […

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

Re: Sanding UI

#202

Post by 2024user »

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/company in 5 years so don't care.

Re: Sanding UI

#203

Post by 2024user »

xyst wrote: post #80

I wonder what’s the most polished or “sanded” UI out there? You would think FAANG would have a half decent UI and UX with the amount of money they have. But anybody that has used Amazon.com or AWS, GCP, or even Azure would beg to differ. Personally, off the top of my head. The most polished UI/UX has to be “mcmaster.com”. I can find anything I need in what seems like a couple minutes. Compare this to big box stores l…

HEY! mail was great when I used it

Re: Sanding UI

#205

Post by mdavid626 »

Put the input >into< the label. Then gap doesn’t matter, it’ll work. Of course, don’t allow such mistakes. It’s quality work when such small details are noticed and cared about.

Re: Sanding UI

#206

Post by egeozcan »

kristiandupont wrote: post #132
djhn wrote: post #122

Earlier quoted context omitted.

The thing that gets me is how slow all of it is. And I’ve programmed against facebook APIs, which are ludicrously performant! Hundreds of megabytes of data in single digit milliseconds total roundtrip.

They do this in an attempt to combat ad blockers. It's an arms race that is sadly bound to create cruft like this.

exactly, one example is there are a lot of programatically absolute positioned divs to break ad-blockers or make them very inefficient, while the performance of the app suffers from many tricks like these as well.

Re: Sanding UI

#207

Post by mlnj »

8n4vidtmkvmk wrote: post #141
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.

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.

Re: Sanding UI

#208

Post by mlnj »

bartread wrote: post #173
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).

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…

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

Re: Sanding UI

#209

Post by dustingetz »

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…

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.

Re: Sanding UI

#210

Post by jagged-chisel »

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

I feel like this goes along with the recent Artisan Software discussion on HN.

Companies don’t want Software Artisans.

Post reply on HN