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

91–100 of 511 posts

Re: Imaginary problems are the root of bad software

#91

Post by chillbill »

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…

I don’t think it’s as easy as you’re making it to seem. The issue is that there are unintended consequences to each one of those points you mentioned. I’m pretty sure a substantial amount of thinking goes into software design from all aspects and it’s a bit reductive to say that it’s just lack of incentive. Humans doing software are not some machine learning algorithm to train with reinforcement learning techniques.

Re: Imaginary problems are the root of bad software

#92

Post by drc500free »

t43562 wrote: post #59

On one project I did it was essential to be able to record how much a tool was used so that we could charge for it. The tool ran locally on the customers' machine and reported to our service. The overall mechanism that sent and received this information had to be reliable or we'd lose money but even worse would be to in some way overcharge customers. Lots of aspects of the design were complicated by this concern. The…

I think the most important function of a good Product Management team is to understand what parts of the go-to-market impact tech decisions and spend 80% of their energy into pinning those down as firmly as possible. There is a happy medium between JIT delivery of specs for random features and a hard two-year roadmap that can't react to business changes.

YNGNA is generally true, but Product's should have a very clear vision of what kinds of entities the system is going to handle over then next 36 months before they start asking for specific functionality. I've seen extra shit get built, but I've also seen e.g. a travel booking system that was built without a "flight" being a first class entity. Flights were deduced on the front end from attributes attached to seats... which worked well until a PM asked for the UI to show fully-booked flights, which HAVE no available seats that make it to the front end. Same product couldn't handle the booker and traveler being different people, when they knew from day 1 that it would be a necessary feature. It would have been little extra work to incorporate into the data model from the beginning, even if the two values were always the same for a while.

I think the majority of the technical debt I've seen that isn't ci/cd related is disconnect between the domain model the product team is working in and the data model the engineering team is working with. Formalizing that domain model is now one of the first things I do when joining a team, so everyone agrees on precisely what the major nouns and verbs are and how they interact. Not just for the current system, for where we think we will be in 2-3 years. With everyone doing agile, it's amazing how many incompatible, un-written assumptions you discover that hadn't been ironed out.

Re: Imaginary problems are the root of bad software

#93

Post by x86x87 »

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…

I call this "the tragedy of software development"

Re: Imaginary problems are the root of bad software

#94

Post by mildavw »

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…

Yes. While it’s less common, I’ve seen orgs struggle because they didn’t have enough imagination.

Every feature is done quick’n’dirty and eventually you have people whose full time job is to respond to customer complaints and fix data straight in the production database.

Re: Imaginary problems are the root of bad software

#95

Post by allenu »

pydry wrote: post #72
allenu wrote: post #55

I absolutely agree with the premise. People just love building things even when they're not needed. After a while, your ego gets attached to whatever it is you've built and you can't let it go. I remember working at one place where somebody built a new framework to solve a common problem we all had. He pitched it to all the other devs in a meeting and I remember being confused about it because there was a standard fr…

Your guy clearly had an emotional attachment to his work not an inexplicable intellectual attachment. It's hard to admit that your baby is ugly.

You're right. It's a good lesson to take away when it isn't you because when you're that guy, it's so hard to separate yourself from your work.

Re: Imaginary problems are the root of bad software

#96

Post by wildekek »

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…

All of those are absolutely real. There is a lack of economics and a surplus of optics in the game for all players.

Re: Imaginary problems are the root of bad software

#97

Post by voz_ »

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…

Uber was a massive example of this. The best engineers kept their head down and just tried to keep things afloat, fixing bugs, etc.

However, a large and insidious cadre of B tier engineers was constantly writing docs proposing meaningless arbitrary system changes and new designs for the sake the changes themselves. These new projects were the only way to get promoted. The entire e4->5->6->7 track was written in such a way that it only ever encouraged “TL”/“architect”types to grow.

This led to constant churn, horrible codebases, and utter bullshit self made problems which could only be solved by digging a deeper hole.

There are companies who handle this well. Ultimately it comes down to engineering culture.

Re: Imaginary problems are the root of bad software

#98

Post by aldanor »

pavlov wrote: post #90
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 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

Re: Imaginary problems are the root of bad software

#99

Post by morning-coffee »

vbezhenar wrote: post #77

How do you manage boring part though? Going mad because of boredom is a real thing. I definitely agree that some of my job is caused exclusively by my need to keep myself entertained. But what's the solution? Another factor is resume driven development. Yes, you can frown upon it all the day, but in the end I'll switch company and I'll need to find a new job. And, like it or not, but everyone these days wants a lot o…

Try to find other real problems to work on that are different from your current boring parts? The new problems might eventually become boring as well, but often the change and fresh perspective is enough to pique your interest in a motivational and productive way.

Re: Imaginary problems are the root of bad software

#100

Post by sirsinsalot »

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 rare in my experience. Software is a vastly wide scope of software types and requirements. I'm paid to be ruthless, and to know what ruthless looks like in terms of delivering consistently without downtime/data loss/critical issues.

Post reply on HN