Imaginary problems are the root of bad software • Hacker News Board

Re: Imaginary problems are the root of bad software

#261

Post by wruza » Mon, Jun 19, 2023, 1:22 AM UTC

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…

For that to happen, two things must match: a product guy who knows your job and you who know how to make products. It doesn’t even have to be stable/featureless, in my experience. New developers tend to worship some new paradigm that focuses on “how” instead of “what”, which is all paradigms can do. And once they’re in, it goes downhill because the how dominates the what. Add a clueless product guy into the mix and it loses all limits, including budget. In the end they proclaim “software is hard” and move on.

Re: Imaginary problems are the root of bad software

#262

Post by Aeolun » Mon, Jun 19, 2023, 1:25 AM UTC

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…

> I'm not saying this is a common situation, but it certainly isn't rare in my experience.

I think your experiences may be skewed by the position you find yourself in?

Re: Imaginary problems are the root of bad software

#263

Post by wruza » Mon, Jun 19, 2023, 1:27 AM UTC

sirsinsalot wrote: post #239

whstl wrote: post #211

Earlier quoted context omitted.

I'm in the same boat as GP. I work in finance. CTO said he wanted to keep things simple and stable, so I do it. It is only possible because I'm a technical manager myself and I have a very competent (and technical) product manager working with me. But for every person like me, there are 10 other devs trying to cram every pattern from the GoF book in their corner of the codebase, so I have to spend my scarce time revi…

Am GP, it is finance based, but not commercial finance. Most of the systems handle complex calculations. The system is a monolith that has been around for 15 years or so. It isn't cool. It isn't pretty. Lots of it would be better for a refactor, but absolute stability is the goal. Refactoring things may result in long-term cost savings, but with risk. The business has no risk appetite, so it doesn't make sense. If it…

Interesting, I believe there is something to finance that allows or forces things this way. There’s much less fidget spinning and much more business in it for some reason.

Re: Imaginary problems are the root of bad software

#264

Post by Aeolun » Mon, Jun 19, 2023, 1:30 AM UTC

sanderjd wrote: post #259

ronnier wrote: post #86

Earlier quoted context omitted.

I really think we have too many people working at most companies. It pushes people to the extremes and edges just to have something to work on. Managers need more people under them to get promotions. And managers want to manage managers to keep moving up. They fill teams of people on products that could really be ran by a fraction of the engineers. But that’s not where we are, we are on large teams working on small a…

Yeah I dunno, I hear this a lot, but there has universally been way more work to do than people to do it at every company I've worked for. But that doesn't mean the right things are being prioritized.

There is a lot of work, but a lot of that work is generated by people doing the wrong thing too often.

If we had a smaller and more competent team, the initial build might have been marginally slower, but we wouldn’t have to spend a permanent 50% to just keeping down the technical debt.

Re: Imaginary problems are the root of bad software

#265

Post by catmanjan » Mon, Jun 19, 2023, 1:30 AM UTC

mildavw wrote: post #94

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.

Bad engineering but potentially good business if it’s all billed to the customer…

Re: Imaginary problems are the root of bad software

#266

Post by balder1991 » Mon, Jun 19, 2023, 1:33 AM UTC

fauigerzigerk wrote: post #132

tyingq wrote: post #119

Earlier quoted context omitted.

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.

I agree, and I'm not criticising the choices that Mark Zuckerberg made at the time. But we are no longer facing the same situation he did. We do now have high productivity, high performance language runtimes. And scaling up has become much cheaper (relative to the number of users you can serve). That's why I think it can't hurt to remind people of the great lengths to which Facebook had to go in order to deal with th…

Yeah, I kinda don’t agree with the dichotomy of “you either optimize or you build features”. They’re not exclusive. If you understand the tools and their trade offs you should be able to use the right tools for the job which won’t hinder you in the future.

Of course if all you know is JavaScript, then that requires going a bit outside your comfort zone.

Re: Imaginary problems are the root of bad software

#267

Post by Aeolun » Mon, Jun 19, 2023, 1:34 AM UTC

tacitusarc wrote: post #199

joshlemer wrote: post #150

Earlier quoted context omitted.

I don't know, the more I advance in my career, the more I see it as the opposite. Wide eyed developers with big designs, who are obsessed with the technical aspects of a solution, who disregard the practicalities, long term implications at the social level (who is going to maintain this, do we have people that have that skillset, is this worth the effort, does it really matter to be this elegant, or is it more import…

As a team lead, I’ve found it really difficult to keep curious, smart, young engineers on track. Everyone wants to go off and build shiny things instead of solving real problems. I have to find enough shiny problems that actually need solving to balance out the daily grind. Interestingly, I also find it difficult to instill a sense of meticulousness, and how important it is to write code in a way that reduces bugs. C…

> I’ve found it really difficult to keep curious, smart, young engineers on track

I’ve found the opposite. The young engineers are generally willing to listen to reason. The older Enterprise Architects are the ones that want to keep making things more complicated, or want to keep using suboptimal solutions because we’ve been using them for years.

Now that I write it down it’s kind of curious how on one hand it’s complicating things with stuff they already know, and on the other hand it’s absolute rejection of stuff they don’t.

Maybe I’m the same?

Re: Imaginary problems are the root of bad software

#268

Post by paulryanrogers » Mon, Jun 19, 2023, 1:38 AM UTC

sirsinsalot wrote: post #241

kylelahnakoski wrote: post #229

Earlier quoted context omitted.

Minimal change, or minimal code? Refactoring code can make code smaller but depends on good testing. Applying minimal changes results in redundant and complicated code, but less likely to break existing functionality.

In the first instance, both. However, i'd take more code that was better reasoned and easily understood over less verbose code that was smaller for smaller sake. In terms of minimal change, we refactor when there's a clear business case to permit taking on the risk. Otherwise, we make the most minimal, most stable, least risk change to the existing code even if that code isn't optimal/pretty/well-structured/has-error…

IME this can be hard if built on a platform or dependencies one doesn't control, which is common at early stage companies.

Because often the dependencies require surfing latest, or close enough, versions to maintain a secure system or avoid stalls for jumping major versions. Sometimes even core languages and standard libraries may require staying at least near latest versions.

Re: Imaginary problems are the root of bad software

#269

Post by obviouslynotme » Mon, Jun 19, 2023, 1:46 AM UTC

BeFlatXIII wrote: post #176

noirbot wrote: post #151

Earlier quoted context omitted.

This is absolutely a thing, but I'd say there's a related option which is "Job Listing Driven Development". The more niche, dated, or specific your platform is, the harder it is to hire people onto the team who don't need months of on-the-job practice and training to be useful. You see the most extreme versions of dangers of this in stories about governments and older companies having to pay insane salaries to bring…

What's kind of funny is that MUMPS is equally as archaic and idiosyncratic as Fortran or Cobol, yet there are companies willing to put new hires through a bootcamp to make them productive. Are all the Fortran and Cobol companies too small to afford a month or three of training time on new devs?

As someone who maintains a large Fortran codebase actively maintained from the 50s, I can say with 100% confidence that syntax, compiler, and other tools aren't even 10% of getting up to speed. It's some of the worst code you will ever see. A lot of it predates "GOTO considered harmful." It also comes from an era where different common blocks and subroutines were moved into and out of memory using a custom virtual memory system.

The demand for Fortran/Cobol experience has nothing to do with training. We need to make sure you are masochistic enough to trudge through the sludge.

Re: Imaginary problems are the root of bad software

#270

Post by chrisco255 » Mon, Jun 19, 2023, 1:49 AM UTC

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…

Yeah I agree the author got a bit dismissive about the inherent complexity of solving business problems on an ongoing basis. He even links to a Wikipedia article about Google and offhandedly claims that the problem of indexing the whole web was solved by a couple of guys. We all know Sergey and Larry created the original Pagerank algorithm, but it's farcical to believe that their original algorithm would have stood the test of time without input from hundreds of engineers who had to deal with the rapidly evolving web and all the ensuing SEO spam, ad scams, revenge porn, illegal content, international firewalls, international regulations, scaling their infrastructure to handle billions of requests, creating an ad network to support the endeavor, etc etc. That all cannot be done by two guys in a dorm room.

I'm sure Google as an org has accrued plenty of staff that are working on mild to non important tasks over the years, and I get where he's coming from, but reality is far more nuanced.