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

Imaginary problems are the root of bad software

cerebralab.com

Post reply on HN
Print view View original

111–120 of 511 posts

Re: Imaginary problems are the root of bad software

#111

Post by lewisjoe »

lfowles wrote: post #106
lewisjoe wrote: post #104

Earlier quoted context omitted.

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

Great! Now try it in any other list view in any other app.

Maybe the list of docs in https://docs.google.com?

Re: Imaginary problems are the root of bad software

#112

Post by davidmnoll »

pydry wrote: post #68
davidmnoll wrote: post #27

I agree with this to some extent. but there’s a flip side too. This mentality is often taken way too far. I had an old boss who wouldn’t allow me to write unit tests citing this thought process. Even at places with decent engineering practices, I’ve seen so many examples of software where you’re limited to a one to many relationship for something that could and easily should have been implemented as many to many, ren…

Ive seen a lot of engineers complain about YAGNI being taken too far but none who have seen their concerns validated by reality.

I have seen it validated by reality several times… more times than the opposite. I had a boss refuse to let me do a refactor that changed these sketchy dynamic field tables into json columns because “it’s not customer facing.” They were unable to show off features in an important demo because the endpoints were timing out despite putting 2 other people on it for 2 weeks to find code-based optimizations.

3 days later I deployed my “nice to have” fix and the performance issues disappeared.

I’ve also seen a company stall out scaling for years and lose multiple million-dollar customers despite having a novel in-demand, market leading product because they refused to do anything to clean up their infrastructure.

Re: Imaginary problems are the root of bad software

#113

Post by mlhpdx »

dan-robertson wrote: post #80

I don’t know what is going on with this article. The first half is a maybe reasonable description of a common way for certain kinds of contracts to go wrong. But obviously lots of software doesn’t get developed in this sort of arms-length way. I would say that imaginary problems (as the author defines them) cause failed projects by consultants/contractors. I find the rest of the article to be bizarre. The discussion…

The second part might be summarized as “when technology starts to diverge from the business model, or vice versa, both become messy.”

Re: Imaginary problems are the root of bad software

#114

Post by codegeek »

icedchai wrote: post #11
dtagames wrote: post #3

The author hits the nail on the head with his claim that imaginary problems are more fun than real ones. As developers and smart folks in general, we like complicated problems that are big and far away. How many times have I heard in a meeting, "Yeah, but when we have 1M users..." It's great fun to think your product will get to 1M users. It's also very unlikely. It's not nearly as fun to finish and ship and market a…

Reminds me of a PM I used to work with. "Will this work for 1000 simultaneous users?" After almost 2 months, we have less than 100 users total, maybe 5 of them log in a day, and maybe 1 will actually do anything of interest. There is no technical problem. The problem is nobody worked on actually marketing the product. Build it and nobody shows up is the norm.

""Will this work for 1000 simultaneous users?""

Whenever someone asks me this question, I reply with a question "How many simultaneous users do you/we have today and what is our projection say for 12-18 months from now ?". If the answer is not clear, I tell them not to worry yet. If the answer is very clear but numbers are much smaller today (say 5-10), then I challenge them on where they think they/we could be in 12-18 months. A lot of times, it helps the other side see that they are mostly asking "How long is a piece of string".

Re: Imaginary problems are the root of bad software

#116

Post by fauigerzigerk »

ericbarrett wrote: post #66
fauigerzigerk wrote: post #44

Earlier quoted context omitted.

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

The trick was there was enough growth that the savings from the compiler were massive . (I worked there at the time.) The inefficiency of the PHP interpreter was a great problem to have, because it came from the success it enabled.

So I think the interesting question is whether the rest of us can learn anything from what happened there.

I believe Mark Zuckerberg simply used the technology he knew and took it from there. That's fine. I probably would have done the same thing.

But many people are making an ideology out of this, arguing that not giving a shit about performance is always the right choice initially because that's how you grow fast enough to be able to retool later.

I think this is based assumptions that are no longer true.

In the early 2000s, mainstream programming languages and runtimes were either fast and low productivity or slow and high productivity (Exceptions such as Pascal/Delphi did exist but they were not mainstream). And the cost of scaling up was prohibitive compared to scaling out.

Today, you can choose any fast high productivity language/runtime and go very far mostly scaling up.

Re: Imaginary problems are the root of bad software

#118

Post by chubot »

sirsinsalot wrote: post #100
lewisjoe wrote: post #73

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 engineer is paid extra for keeping the codebase without growing too much. I am. I'm paid more than most developers to run a team doing just this. We make minimal change, have an absolutely non-negotiable focus on stability and minimalism and reject any change that isn't absolutely driven by validated majority user need. Even then, the bar is high. I'm not saying this is a common situation, but it certainly isn't…

What kind of software do you work on? At what company?

I have seen low level parts that are managed well, because employees have skin in the game

But I’ve also seen a lot of what this post is talking about

Re: Imaginary problems are the root of bad software

#119

Post by tyingq »

fauigerzigerk wrote: post #110
cagenut wrote: post #70

Earlier quoted context omitted.

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.

I'm not sure there was really a best tool for the job in 2003-2004 that would have been high-level enough to be productive, and scalable enough to stay mostly as-is. Java, maybe.

Re: Imaginary problems are the root of bad software

#120

Post by totallywrong »

dagmx wrote: 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.

15k is rather high for those specs. A single competent dev can build that in a month.
Post reply on HN