Live data from Hacker News

Imaginary problems are the root of bad software

cerebralab.com

101–110 of 511 posts

Re: Imaginary problems are the root of bad software

#101

It seems like the fundamental problem for the scenario presented in the article was an inability of the customer to communicate their strategy and a completely hands off approach during implementation when they should have had at the very least biweekly checkins with developers with pre-negotiated milestones.

The fundamental problem is that a non-technical person has specced out a technical product without input from technical people.

A restauranteur wouldn't develop a menu without input from a chef or prior experience as one. A layperson wouldn't design a real building without input from an architect or engineer.

Yet for some reason a myriad of non-technical people (read: laypeople) feel empowered to design, spec, and strategize about software. It still boggles my mind that "product management" is a real profession.

Re: Imaginary problems are the root of bad software

#103

If anything it's the incentive system in software industry, which is at fault. 1. No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. 2. No engineer is paid extra for keeping the codebase without growing too much. It's re-writes and the effort he puts in to churn out more solutions (than there are problems) that offer…

And at least at the “enterprise” level for B2B software, there is intense customer demand for more features and, simultaneously, more stability.

From my view, that and pressure from the analyst racket are the main drivers behind feature bloat with self promotion a distant third.

Re: Imaginary problems are the root of bad software

#104
post #90

If anything it's the incentive system in software industry, which is at fault. 1. No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. 2. No engineer is paid extra for keeping the codebase without growing too much. It's re-writes and the effort he puts in to churn out more solutions (than there are problems) that offer…

> “No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives.” This is a massive change from my first software industry job in 1997. I was essentially a “design intern who knows HTML” on a team that built a shrinkwrap Windows application for enterprises. The core of the design team was a graphic designer, a cognitive scienti…

From a person who started using computers from the early 2000s era:

THANK YOU!

None of the current SaaS apps I use can come close to the experience of using softwares from that era.

Take a simple list view of a typical Windows/Mac software?

1. Command clicking selected multiple objects

2. Shift clicking selected a range.

3. Right clicking brought up selection actions.

4. Double clicking opened an object.

This pattern was followed in almost list views and there was no re-learning and surprises.

Now can you say the same about the list views of modern web apps?

Can you apply the same list selection experience across Google Drive and Microsoft OneDrive and Apple iCloud? Nope.

That's were we failed as an industry. We let a lot of designers run too wild with their ideas, to put it bluntly.

Re: Imaginary problems are the root of bad software

#105

Earlier quoted context omitted.

Good reputation?

Pure luxury if you live from hand to mouth.

Reputation is what gets you more business in the future. You can expand your business or raise rates, or both.

Yes, this won't help if you're literally in danger of not meeting payroll next week, but I would hope most businesses don't operate so close to the edge.

Re: Imaginary problems are the root of bad software

#106
post #90

Earlier quoted context omitted.

> “No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives.” This is a massive change from my first software industry job in 1997. I was essentially a “design intern who knows HTML” on a team that built a shrinkwrap Windows application for enterprises. The core of the design team was a graphic designer, a cognitive scienti…

From a person who started using computers from the early 2000s era: THANK YOU! None of the current SaaS apps I use can come close to the experience of using softwares from that era. Take a simple list view of a typical Windows/Mac software? 1. Command clicking selected multiple objects 2. Shift clicking selected a range. 3. Right clicking brought up selection actions. 4. Double clicking opened an object. This pattern…

Those four actions worked for me on the Google Drive web interface

Re: Imaginary problems are the root of bad software

#107
post #98
post #90

Earlier quoted context omitted.

> “No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives.” This is a massive change from my first software industry job in 1997. I was essentially a “design intern who knows HTML” on a team that built a shrinkwrap Windows application for enterprises. The core of the design team was a graphic designer, a cognitive scienti…

Today they might have a psychologist on the team to research which buttons may serve as dopamine triggers so you're a lot more likely to upgrade to Premium before thinking it over

Right. Making people click on things they didn’t mean to and buy things they didn’t want — those goals were not even a part of the 1990s UI paradigm.

Re: Imaginary problems are the root of bad software

#108
post #17

I know it’s just an arbitrary number picked but this bit jumped out at me: “You’ve just wasted $15,000 on two months work with a team of contractors” The project may also have been doomed because $15k is not very much for something like they described. But again, fully aware that they probably picked a random number. I’d have just added another zero to make it more realistic.

150.000$ for a podcast app with zazzle shop and google ads integration? That sounds really high to me. I personally found 15k way too high already; guess it depends on the details/market/circumstances

It could be both too high or too low depending on the communicated expectations of the client. Which is I think the real issue here anyway.

But let’s say 15k for two months of a team of contractors. That’s 7.5k/mo. A team says at least two, but I think given they mention sales etc, that’s 3-5 people. Netting 2.5k/person before you take out built in profit margins, healthcare (because it’s dollars, I assume America) and more. That’s roughly 1.5k/person per month. (Of course they could have multiple projects but even then that’s a low amount imho for a contractor with sales)

If they’re expecting an off the shelf solution, then they’re getting fleeced on the costs and 15k is too high, but if they’re going to a company that does big solutions than they spent too little.

There’s too little info in general

Re: Imaginary problems are the root of bad software

#109

If anything it's the incentive system in software industry, which is at fault. 1. No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives. 2. No engineer is paid extra for keeping the codebase without growing too much. It's re-writes and the effort he puts in to churn out more solutions (than there are problems) that offer…

and the re-writes have to be in a trendy language that other companies are using, just for the engineer to stay relevant.

everything about engineering group decisions are about creating a reason to use a newer framework in a way other people can vouch for.

Re: Imaginary problems are the root of bad software

#110
post #70

Earlier quoted context omitted.

All they had to do was write a PHP compiler and a new storage engine for MySQL.

your comment implies your understanding of the timeline is backwards. they had to do those things after they had gotten hundreds of millions of users.

Depends on what you consider "far down the road" and what they had to do before writing a compiler and a storage engine.

How long did it take until Facebook engineers realised that their technology stack was not the best tool for the job? It definitely wasn't the day when they decided to build a compiler and a storage engine.

Post reply on HN