[Rules p.1] Things that annoy you guys. 100 percent. Not gonna lie

Cuttooth wrote:The theme of self service checkouts never working or being gooseberry fool is probably the single biggest disconnect I have with apparent public consensus.

They've almost always worked just fine for me, the handful of times they don't are always sorted by the shop worker within a few seconds.

Cuttooth wrote:The theme of self service checkouts never working or being gooseberry fool is probably the single biggest disconnect I have with apparent public consensus.

They've almost always worked just fine for me, the handful of times they don't are always sorted by the shop worker within a few seconds.

Moggy wrote:

Cuttooth wrote:The theme of self service checkouts never working or being gooseberry fool is probably the single biggest disconnect I have with apparent public consensus.

They've almost always worked just fine for me, the handful of times they don't are always sorted by the shop worker within a few seconds.

Yeah I agree. The only time I've ever needed the staff was if I'm buying alcohol.

Cuttooth wrote:The theme of self service checkouts never working or being gooseberry fool is probably the single biggest disconnect I have with apparent public consensus.

They've almost always worked just fine for me, the handful of times they don't are always sorted by the shop worker within a few seconds.

BonalityMatrix wrote:I don't know, they can take a long time to respond to button presses (and then when you press again because you think it hasn't registered causes them to buffer up) but that's most things today: phones and TV boxes spring to mind. I don't know when this became acceptable but there seems to be this consensus among electronics firms that this will "do" and it's shoddy as hell.

Errkal wrote:

BonalityMatrix wrote:I don't know, they can take a long time to respond to button presses (and then when you press again because you think it hasn't registered causes them to buffer up) but that's most things today: phones and TV boxes spring to mind. I don't know when this became acceptable but there seems to be this consensus among electronics firms that this will "do" and it's shoddy as hell.

Allot of development is done using the Agile methodology and one of its waya is that you deploy when you get some value.

It doesn't need to be finished or perfect as long as some value is added, and it leads to what we have now where lots of gooseberry fool issues happen because "well it isn't perfect, but it adds X".

The focus is to release stuff always so that you are always adding things and give the illusion that you are always adding value by updating often rather than doing fewer updates but them being proper good.

Jenuall wrote:

Errkal wrote:

BonalityMatrix wrote:I don't know, they can take a long time to respond to button presses (and then when you press again because you think it hasn't registered causes them to buffer up) but that's most things today: phones and TV boxes spring to mind. I don't know when this became acceptable but there seems to be this consensus among electronics firms that this will "do" and it's shoddy as hell.

Allot of development is done using the Agile methodology and one of its waya is that you deploy when you get some value.

It doesn't need to be finished or perfect as long as some value is added, and it leads to what we have now where lots of gooseberry fool issues happen because "well it isn't perfect, but it adds X".

The focus is to release stuff always so that you are always adding things and give the illusion that you are always adding value by updating often rather than doing fewer updates but them being proper good.

This isn't strictly true. The point is that within agile methodologies you should always be at a position where you can "potentially" release something. Each iteration should be adding value from a users perspective: new features, refinements to existing features etc. but there are still plenty of caveats and QA activities which should stand between a feature being added to the product and the people involved deciding that the latest iteration is suitable for being released/deployed!

Errkal wrote:

Jenuall wrote:

Errkal wrote:

BonalityMatrix wrote:I don't know, they can take a long time to respond to button presses (and then when you press again because you think it hasn't registered causes them to buffer up) but that's most things today: phones and TV boxes spring to mind. I don't know when this became acceptable but there seems to be this consensus among electronics firms that this will "do" and it's shoddy as hell.

Allot of development is done using the Agile methodology and one of its waya is that you deploy when you get some value.

It doesn't need to be finished or perfect as long as some value is added, and it leads to what we have now where lots of gooseberry fool issues happen because "well it isn't perfect, but it adds X".

The focus is to release stuff always so that you are always adding things and give the illusion that you are always adding value by updating often rather than doing fewer updates but them being proper good.

This isn't strictly true. The point is that within agile methodologies you should always be at a position where you can "potentially" release something. Each iteration should be adding value from a users perspective: new features, refinements to existing features etc. but there are still plenty of caveats and QA activities which should stand between a feature being added to the product and the people involved deciding that the latest iteration is suitable for being released/deployed!

From a theoretical perspective at least where I am sure,but the issue we have is the business and product owners always prioritise the new thing and never fully completing the last thing leave lots of "day 2" features, fixes and enhancements in the ever growing tech debt backlog.

Jenuall wrote:

Errkal wrote:

Jenuall wrote:

Errkal wrote:

BonalityMatrix wrote:I don't know, they can take a long time to respond to button presses (and then when you press again because you think it hasn't registered causes them to buffer up) but that's most things today: phones and TV boxes spring to mind. I don't know when this became acceptable but there seems to be this consensus among electronics firms that this will "do" and it's shoddy as hell.

Allot of development is done using the Agile methodology and one of its waya is that you deploy when you get some value.

It doesn't need to be finished or perfect as long as some value is added, and it leads to what we have now where lots of gooseberry fool issues happen because "well it isn't perfect, but it adds X".

The focus is to release stuff always so that you are always adding things and give the illusion that you are always adding value by updating often rather than doing fewer updates but them being proper good.

This isn't strictly true. The point is that within agile methodologies you should always be at a position where you can "potentially" release something. Each iteration should be adding value from a users perspective: new features, refinements to existing features etc. but there are still plenty of caveats and QA activities which should stand between a feature being added to the product and the people involved deciding that the latest iteration is suitable for being released/deployed!

From a theoretical perspective at least where I am sure,but the issue we have is the business and product owners always prioritise the new thing and never fully completing the last thing leave lots of "day 2" features, fixes and enhancements in the ever growing tech debt backlog.

And that sort of thing can happen, but it's a symptom of it being done badly rather than a problem with Agile in itself!

Green Gecko wrote:

Squinty wrote:Tech related, got a cheap audio interface, cannot get the thing recognized by my DAW. Spent about 2 hours this morning strawberry floating around with it.

I spent what I would consider an eye watering amount of money yesterday on essentially a midi controller but the implementation was flawless (and bloody rightly so). Still, I feel your pain as I have used a lot of devices and only 15 years later am I actually throwing money at the problem. (As an aside, this is a positive blip, I am rather poor for the UK and make about £5000 a year). I've done my fair share of messing around with drivers. The trouble often is cheap audio interfaces come with strawberry floating dreadful software. Low latency audio (especially on Windows) is hard. It should be better these days but still.

If you want to take it back, I've not had trouble with focusrite hardware and now I'm on SSL for the control side of things which is strawberry floating insane (still using the focusrite interface for io as 10 years later its still working fine over numerous operating systems). They've taken manufacture over to China from Oxford for some things so they have cheap 1 or 2 chanel I interfaces. I say cheap around £150 but I suspect they work given yesterday's experience.

If you bought online you have essentially more rights, return it in as new condition for any reason within 28 days for cash refund. If its faulty you shouldn't have to pay return postage.