Software development is a loser’s game • Hacker News Board

Re: Software development is a loser’s game

#121

Post by justin_oaks » Thu, Apr 01, 2021, 4:29 PM UTC

watwut wrote: post #95

commandlinefan wrote: post #80

Earlier quoted context omitted.

> developers forget that the goal is to ship software and instead focus on doing everything the most correct I'm far, far more frustrated by developers who focus only on shipping software and making dates by cutting corners wherever they can and leave everybody else to deal with their gigantic mess later.

That is squarely and fully leadership issues. I means this 100%. The way to avoid this are fully in management and leadership hands.

Agreed. I think many of us realize the futility of getting our leadership to change, and instead hope that our coworkers will change.

Re: Software development is a loser’s game

#122

Post by tsimionescu » Thu, Apr 01, 2021, 4:32 PM UTC

justin_oaks wrote: post #119

scottious wrote: post #92

Earlier quoted context omitted.

I think you're right, but I also think the author isn't necessarily wrong. Using his tennis analogy, each chunk of code written is like swinging at the tennis ball. You don't have to have the perfect curve-ball, you just have to NOT screw it up. I've too often seen developers try to attack the ball with the perfect swing and the most force possible, only to have it go straight into the net. If they just focused on ge…

This reminds me of advice I give to junior devs who over-complicate things in the planning phase: "Start with the stupidest thing that will work". You need to make something work before you can make it work well. You need to start simple before you dig into the complexity. Sometimes you find that the "stupid" solution is good enough.

I think it's important to note here that you need to start your thinking or design from the simplest possible solution, but that doesn't mean it always makes sense to actually implememt that solution.

Re: Software development is a loser’s game

#123

Post by LMYahooTFY » Thu, Apr 01, 2021, 4:42 PM UTC

scottious wrote: post #92

terracatta wrote: post #28

> If we invert software development, the goal isn’t then to write code that works, it’s spending time on avoiding writing poor quality code and bugs. This line is packaged to sound really insightful, but is it? The goal of software development is to create software in support of some greater mission. That mission might be to make someone's life easier, to make money, to advance human knowledge, or many other things.…

I think you're right, but I also think the author isn't necessarily wrong. Using his tennis analogy, each chunk of code written is like swinging at the tennis ball. You don't have to have the perfect curve-ball, you just have to NOT screw it up. I've too often seen developers try to attack the ball with the perfect swing and the most force possible, only to have it go straight into the net. If they just focused on ge…

>If they just focused on getting it over the net as simply as possible, the end result usually means less code that's easier to understand.

I'm sure there's some range of nuance to your point, but it's also in line with the iterative philosophy isn't it? Do you find patching/revising things later to skew better/worse or some other downstream consequences?

It seems like you find that approach more efficient overall?

Re: Software development is a loser’s game

#124

Post by aYsY4dDQ2NrcNzA » Thu, Apr 01, 2021, 4:44 PM UTC

kristianc wrote: post #87

wpietri wrote: post #62

Earlier quoted context omitted.

I think the heart of this isn't devs changing jobs. It's execs. I know plenty of devs who will be "irrational" about quality in that they build for sustainabilty and longevity far beyond their personal economic incentives. But when those same devs go up the chain to improve practices or clean up tech debt, they rarely end up happy. I think that's because executive turnover is also fast and the rewards for underinvest…

I've rarely seen progress get made when it's framed as "I want to clean up tech debt." To execs it seems like moving deckchairs rather than moving the number (which to be fair, it sometimes is). "In order to release feature x which customer y cares about, we need to clear up tech debt / refactor z" is a much better way of getting execs on board.

Excellent point, it needs to offer a concrete benefit. Simply saying “it will make it easier to write new features going forward” won’t convince anyone.

Re: Software development is a loser’s game

#125

Post by PicassoCTs » Thu, Apr 01, 2021, 4:47 PM UTC

culopatin wrote: post #63

PragmaticPulp wrote: post #20

An ask of anyone reading this article: Please don’t let yourself become a smug or cynical programmer. Too many programmers read articles like this and assume that they are the 20% of good programmers while everyone who disagrees with them is the 80% of amateur developers: > I have worked in software development for 20 years, worked on many projects with many software developers. I estimate 80 percent of software deve…

I am one of those that can’t get started because perfection and peer review is in my head. I blame it on Stackoverflow making me feel like a moron every time I ask something.

Its a toxic, anti-enlightenment culture, if any question or request for information is perceived as a attack on the self-worth of the author of that piece of information. I think at the root of this perfectionism, are loads of damaged individuals, whos whole identity and self-worth is defined via their work, their code, their child of mind.

There are so many of these, that they can become a culture majority and bring whole projects to a stop. When i encounter these, i tend to isolate them, link up with other reasonable people (who usually also work around them. If they have grown to powerful, you build two versions, one with their "architecture" (which they will inevitable grab and sink years of time into) and one that will be actually shipped, as a emergency solution.

If discussion is not possible, double the project estimate, cause there are two now.

Re: Software development is a loser’s game

#126

Post by ryandrake » Thu, Apr 01, 2021, 4:50 PM UTC

justin_oaks wrote: post #119

scottious wrote: post #92

Earlier quoted context omitted.

I think you're right, but I also think the author isn't necessarily wrong. Using his tennis analogy, each chunk of code written is like swinging at the tennis ball. You don't have to have the perfect curve-ball, you just have to NOT screw it up. I've too often seen developers try to attack the ball with the perfect swing and the most force possible, only to have it go straight into the net. If they just focused on ge…

This reminds me of advice I give to junior devs who over-complicate things in the planning phase: "Start with the stupidest thing that will work". You need to make something work before you can make it work well. You need to start simple before you dig into the complexity. Sometimes you find that the "stupid" solution is good enough.

I wonder if there is something going wrong in the software engineering education pipeline that is encouraging developers to always keep reaching for the most complex tool in the toolbox rather than the simplest. We all see this all the time, so the problem is widespread. Maybe it’s not education but career growth: It sounds like “resume-driven development” where people are incentivized to add complex tools to their toolbox merely so they can get hired at places that select for complex tool use.

Re: Software development is a loser’s game

#127

Post by BlargMcLarg » Thu, Apr 01, 2021, 4:51 PM UTC

varispeed wrote: post #9

One of the problems I faced is that the university didn't teach TDD, I couldn't find any books about TDD and every single programming course didn't even have a section about TDD. It's like this was some kind of secret knowledge that only few had. I was only able to learn TDD when I joined one corporation and it was like a new world to me. I tried to learn as much as I could and then carry that to next jobs. It's bett…

It really depends on what you're building though.

Project I work at right now could really benefit from basic TDD principles, mainly just setting test / outcome matrices and basing production off of that (which logically follows into TDD). The requirements are largely set up front, yet we still shoehorn unit tests in after production is done, wasting both development and test time. Requirements rarely change in major ways, and they are often established months up front.

Other times I work on stuff where fundamentals change rapidly. At that point I'm spending 1.5x-2.5x the time just to include test I'm likely to remove, and TDD largely inflates time required I don't have or wish to spend. Often testing trivial things, too.

Re: Software development is a loser’s game

#128

Post by aYsY4dDQ2NrcNzA » Thu, Apr 01, 2021, 4:56 PM UTC

lmilcin wrote: post #105

Nursie wrote: post #91

Earlier quoted context omitted.

> In many years there has not been a single time the unit test saved me from anything. You've never even made a typo that a unit test has helped you spot? You've never, ever, had a unit test show you that one of the assumptions was wrong that you made about the behaviour of a piece of third party code? That seems mighty unusual to me...

As I said, I try to always thoroughly understand anything I am about to modify. For example, if I change a function body I always familiarize myself with how the function is being used, exactly, what the code of the function does, exactly and how other function it calls work, exactly.

I think I understand where you’re coming from, but let me ask something: when there are bugs found in your code, due to subtle implications of the design or whatnot, are you ever tempted to add a unit test to check that this situation doesn’t return?

Re: Software development is a loser’s game

#129

Post by 908B64B197 » Thu, Apr 01, 2021, 5:00 PM UTC

duxup wrote: post #43

PragmaticPulp wrote: post #20

An ask of anyone reading this article: Please don’t let yourself become a smug or cynical programmer. Too many programmers read articles like this and assume that they are the 20% of good programmers while everyone who disagrees with them is the 80% of amateur developers: > I have worked in software development for 20 years, worked on many projects with many software developers. I estimate 80 percent of software deve…

There's very much almost a meme of those programmers who tell us all how everyone else is doing it wrong ... but their whole idea about who is doing it wrong seems to be entirely driven by how often they're inconvenienced by other people's code, but never account for how often others are inconvenienced by their code. I get inconvenienced by other people's code all the time, but it's so easy to assume when you're look…

> Anecdotal story: I had a bug a few weeks ago that all sorts of people thought was really dumb / obvious / shouldn't have happened. I checked... the code hadn't been changed for FIVE YEARS. Nearly every customer we had ran this code for five years. Maybe I feel that they should have had a catch for the situation that occurred, but whomever wrote it wrote code that lasted bug free for five years ... maybe they weren't dumb and they knew something I didn't?

I've seen this. Huge big O complexity but on a dataset that fits in cache? Runs fine. As soon as the dataset gets bigger, you get systematic timeouts.

Re: Software development is a loser’s game

#130

Post by 908B64B197 » Thu, Apr 01, 2021, 5:01 PM UTC

terracatta wrote: post #28

> If we invert software development, the goal isn’t then to write code that works, it’s spending time on avoiding writing poor quality code and bugs. This line is packaged to sound really insightful, but is it? The goal of software development is to create software in support of some greater mission. That mission might be to make someone's life easier, to make money, to advance human knowledge, or many other things.…

> Feels like this person is very frustrated with novice engineers writing buggy code and has assumed a gatekeeper role to protect the integrity of the codebases in which he holds responsibility.

I wonder what his recruitment pipeline looks like where 80% of engineers end up not being productive.

Sounds like he's hiring wrong to begin with.