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

Software development is a loser’s game

thehosk.medium.com

Post reply on HN
Print view View original

151–159 of 159 posts

Re: Software development is a loser’s game

#151

Post by ric2b »

lmilcin wrote: post #149
Nursie wrote: post #146

Earlier quoted context omitted.

I’m afraid I would not hire someone with that sort of outlook, nor do I believe that you could reliably produce software at any great speed that way. Unit tests show you that the code does what it’s supposed to. Without them you haven’t demonstrated that, just asserted it, nor have you left a system that can be picked up by others with a reasonable expectation that if something does break, it will be caught.

You are blinded, that's what it is. Unit tests became popular relatively recently. When I started development decades ago there was no talk of unit tests at all. Do you want to suggest that people were unable to effectively write working software back then? Just think about this. Unit tests are just one way to help make it more likely the code works. It is neither the only way nor the best way.

> Do you want to suggest that people were unable to effectively write working software back then?

On the first try? Yes, absolutely they weren't, and still aren't.

> Unit tests are just one way to help make it more likely the code works. It is neither the only way nor the best way.

Agreed.

Re: Software development is a loser’s game

#152

Post by wpietri »

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.

For sure. That's definitely where many organizations are. "To cook breakfast this morning, I propose we clean up last night's dinner mess. Here is my 27-slide deck."

But I think it's also worth orgs getting to the point of defaulting to just cleaning up after dinner, and also cleaning as they cook. Having to have a specific, urgent reason to clean up a mess is a fine argument for 13-year-olds to make as they come to understand how a household works. But it's tiresome when nominal adults refuse to accept that the future eventually arrives.

Re: Software development is a loser’s game

#153

Post by tartoran »

rektide wrote: post #31

Big fan of Tom Gamon's Programming is a Losers Game (Sept 2020)[1]. Tom's short post was a very welcome introduction to the matter for me, very open ended, & Ben Hosking here elaborates much more clearly specific concerns & outlooks. [1] https://tomgamon.com/posts/a-losers-game/ Both Ben in this "Software" and Tom Gamon in "Programming" anchor their arguments to Charles Ellis, & his example of tennis as a game where…

This is very well put and am surprised it didn't get more replies.

>Only rarely does the business let us drive towards the true fantastic excellences that we dream of pursuing. Just as the business doesn't understand the loser's game challenges that are all over the place, oh, sad, the business also does not have anywhere near the vision or creativity of the individual, of the coder, who sees possibility & value oozing out of so many areas, often so untapped. And programmers are not put into decision making roles nearly enough, not given structure & the attitude that they can strike, that they can chase down big game, game the rest of the company often has a hard time seeing. The socialization processes that work places must go through to allow commitment are very high, and so programmers simply do not have the time, ability, or often even the common language to get the businesses play the winning game. We must trust that the business somehow is aligned to let us make them kings, rather than taking an active stake in pushing the business towards their would be kingdomship.

The socializing aspect is spot on but there is also a fear that the business people have of losing control. On the software domain they are clueless and they prefer to keep the reigns, even if their decisions are bad than cede some power to software people. They are afraid that software people would become to powerful.

Re: Software development is a loser’s game

#154

Post by pdimitar »

BoiledCabbage wrote: post #140
justin_oaks wrote: post #119

Earlier quoted context omitted.

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.

> 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. 100% true. People love to dig at Test Driven Development, but it solves a common…

> 3. Keep you codebase clean and well factored. Don't let cruft and hacks build up.

I feel obliged to mention that this very often goes against "do the stupidest thing that will work".

Most of the time in my career a clean codebase has naturally led to an intelligent solution which is definitely not the stupidest thing that will work.

Finally, it's also often the case that stupid code requires exorbitant amounts of comments or documentation, undermining the notion of it being simple to extend (which many conflate with the original premise). A little bit more intelligent code is usually self-describing.

Re: Software development is a loser’s game

#155

Post by pdimitar »

ryandrake wrote: post #126
justin_oaks wrote: post #119

Earlier quoted context omitted.

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 t…

In my experience the most common cause for this phenomena is that the devs are afraid they won't be employable if they don't utilize those fads or, as you very correctly summarized it: resume-driven development.

Re: Software development is a loser’s game

#156

Post by pdimitar »

david38 wrote: post #148
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 is a fault of the team culture if it allows junior devs to do that. The whole point of design reviews, code reviews, senior devs, and more is to ensure that stuff that doesn’t work or can’t be maintained doesn’t get deployed.

> ensure that stuff that doesn’t work or can’t be maintained doesn’t get deployed.

That part (especially the second: maintenance) is endlessly contested in calls until some of us just give up and let the others reinvent the wheel for themselves because they don't listen to experience.

Re: Software development is a loser’s game

#157

Post by meiraleal »

pinkybanana wrote: post #101

I was at a startup, we almost never wrote tests, just hacked like amateurs in the way this guy seems to despite. But we managed to sell the startup and got rich. Now the software we hacked together is being maintained by professional programmers. They have tests and all those fancy processes and what not. They get paid nice salary but they'll probably never get rich like the founder programmers. I'm pretty sure also…

Perfect. Although I agree with the writer, context is everything. It is like static vs dynamic typed languages. If typed was really better for every case, dynamic wouldn't be as big (or bigger).

Re: Software development is a loser’s game

#158

Post by meiraleal »

tomphoolery wrote: post #70

This article is so pompous. Calling people "amateurs" when they get paid to do something is hilarious at best and damaging to new developers at worst. It reeks of the "No True Scotsman" fallacy, by listing a set of good practices and then claiming that you're not a "true professional" unless you grok all of that. Get this Gen X snobby attitude out of software development. You're making it harder for the rest of us to…

Amateur programmers can create profitable software, that's not the point of the article. An army is not made of elite soldiers. But it is important to discuss what is the foundation of being elite/pro in a field.

Re: Software development is a loser’s game

#159

Post by fctorial »

Snoozle wrote: post #22
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…

On the flip side, as a dev with 10 years exp, I think TDD is a process crutch designed to cover up poor engineering by adding additional time spent to all work.

Kind of like animations. Mobile apps hide latency by adding transition animations that are longer than the load time.
Post reply on HN