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

Re: Software development is a loser’s game

#141

Post by jfengel » Thu, Apr 01, 2021, 7:13 PM UTC

hnarn wrote: post #113

danans wrote: post #111

Earlier quoted context omitted.

> What happened is once I cracked the codebase open I found ... Sounds like giving the time estimate before cracking open the code base may have played a role in this. You (and your project manager) should factor in research time before giving your estimate. If you are expected to give accurate estimates without research, something might be very wrong with the expectations being put on you.

If you ask someone to give you an estimate for work needing to be done on your car, not only is it obvious that they will have to look at the car first, it's also obvious that the estimated cost and/or time may and often will overrun (although you're normally notified and asked before it does). It seems like both of these things should be equally obvious in software.

When you look in the car, there are only a very limited number of things you expect to be there. If you're a mechanic, you've seen this model before, and it'll be pretty much identical, down to the last bolt. You need to assess the condition, and that'll affect the cost, but even so you can make a pretty good estimate from a glance.

Every piece of software is different. By the time you know what's going on in there, you're almost done. You have to look, but you're still going to be making a lot of assumptions. Assumptions that can throw you off by a factor of 10 -- or even make the fix literally impossible.

That doesn't mean we can do without estimation, even in software. You have to make plans and allocate resources. Just be prepared to change the plans -- and make plans that can accommodate the changes.

Re: Software development is a loser’s game

#142

Post by watwut » Thu, Apr 01, 2021, 7:55 PM UTC

crazypython wrote: post #138

watwut wrote: post #99

Earlier quoted context omitted.

Videogames overall are primary tested by humans, but smaller components inside them do have unit tests. Unit test and integration testing are two different things.

Hmmmm, how would you test, for instance, a rendering engine?

Majority of it are pure calculations that are easy to test automatically. Was this even serious question?

Re: Software development is a loser’s game

#143

Post by lmilcin » Thu, Apr 01, 2021, 8:21 PM UTC

Nursie wrote: post #137

lmilcin wrote: post #105

Earlier quoted context omitted.

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’m afraid I find this somewhat unlikely, or if you are genuinely not only this careful but this fault-less, can only imagine you progress at a very slow pace. Do you not consider unit tests useful because they might help others understand and catch changes to the implicit contracts in your own code?

It has always been amazing to me that almost all developers are convinced that it is not possible to write programs that work on the first try.

This is as silly as stating that you need to build at least couple skyscrapers that fall before one that can stand up and can be occupied.

It is not at all difficult. Instead of spending my entire career writing couple of lines of code and then running it, to see if it works (which is training at being perpetually newb at programming), I spent it learning to write longer and longer pieces of code that I understand exactly what they are going to do and that work on the first try.

I can work weeks writing thousands of lines of complex code and have very good chance that the effect will be working code that needs no corrections.

Do I make silly mistakes? Sure I do. But I then try to figure how it happened and how to make sure I don't make those kinds of blunders in the future.

I also try to design the modules in such a way that it is not possible to misuse them (well, at least requires malicious intent or gross incompetence).

You see, unit tests reward people who break a lot, not people who put a lot of effort into not breaking things. I prefer to focus my efforts into not breaking things in the first place.

I wish this was more popular: https://en.wikipedia.org/wiki/Personal_software_process

Re: Software development is a loser’s game

#144

Post by helij » Thu, Apr 01, 2021, 8:21 PM UTC

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…

I'm Gen X and think the article is pompous as well. I don't get the feeling that my generation is pompous though.

Re: Software development is a loser’s game

#145

Post by bokohut » Thu, Apr 01, 2021, 10:06 PM UTC

My first exposure to computers and writing code was on an Apple in the mid 1980s, I was hooked at a very young age. Since that time I have obtained a higher education degree in software development as well as architected, coded and managed entire enterprise platforms for multiple businesses I have founded. As an entrepreneurial software development loser I stand proud and sm:)e.

Re: Software development is a loser’s game

#146

Post by Nursie » Thu, Apr 01, 2021, 10:23 PM UTC

lmilcin wrote: post #143

Nursie wrote: post #137

Earlier quoted context omitted.

I’m afraid I find this somewhat unlikely, or if you are genuinely not only this careful but this fault-less, can only imagine you progress at a very slow pace. Do you not consider unit tests useful because they might help others understand and catch changes to the implicit contracts in your own code?

It has always been amazing to me that almost all developers are convinced that it is not possible to write programs that work on the first try. This is as silly as stating that you need to build at least couple skyscrapers that fall before one that can stand up and can be occupied. It is not at all difficult. Instead of spending my entire career writing couple of lines of code and then running it, to see if it works…

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.

Re: Software development is a loser’s game

#147

Post by wpietri » Fri, Apr 02, 2021, 4:01 AM UTC

watwut wrote: post #93

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…

Being irrational about quality does not lead to easier to maintain software. You need to be rational about it and the distinction matters a lot. You can go all petty on minor idioms and force everyone to use all the sonar rules and all it will create is a lot of busywork with zero improvement on maintainability. And I have seen this dynamic to happen more then once.

That's not the kind of irrational I'm talking about, which is why I put the word in quotes and then explained exactly what I meant in the same sentence.

Re: Software development is a loser’s game

#148

Post by david38 » Fri, Apr 02, 2021, 4:38 AM 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…

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.

Re: Software development is a loser’s game

#149

Post by lmilcin » Fri, Apr 02, 2021, 8:54 AM UTC

Nursie wrote: post #146

lmilcin wrote: post #143

Earlier quoted context omitted.

It has always been amazing to me that almost all developers are convinced that it is not possible to write programs that work on the first try. This is as silly as stating that you need to build at least couple skyscrapers that fall before one that can stand up and can be occupied. It is not at all difficult. Instead of spending my entire career writing couple of lines of code and then running it, to see if it works…

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.

Re: Software development is a loser’s game

#150

Post by Nursie » Fri, Apr 02, 2021, 11:59 AM UTC

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.

> You are blinded, that's what it is.

Others might call it experienced.

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

People are still unable to effectively write working software. Unit tests are useful for catching problems, which are inevitable, early. They have grown in popularity over the last couple of decades precisely because of the prevalence and costs of preventable errors in the industry. I'm afraid I don't believe that simply by trying really hard you can eliminate said errors, nor do I believe the productivity trade-off would be worth it.

> 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.

Absolutely, they are part of a whole spectrum of techniques and are far from enough in isolation. I've never claimed they are the be-all and end all. They're a useful and essential part of a system of checks and validations, not the only thing you need to do. The clue's in the name, they test units.