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

Woodworking as an escape from the absurdity of software

alinpanaitiu.com

Post reply on HN
Print view View original

21–30 of 545 posts

Re: Woodworking as an escape from the absurdity of software

#21

Post by withinboredom »

zoul wrote: post #11
withinboredom wrote: post #4

Earlier quoted context omitted.

It's quite ridiculous for a number of reasons, well documented by research and experience: software engineers can't estimate how long something will take with any kind of accuracy.

But sorting issues according to their rough size is precisely what makes at least basic sense. A scale of trivial (can make many of those in a day), simple (several of those a day), medium (roughly a day of work) or large (days) makes it possible to have at least basic conversation around work planning. I’m not extra sold about calling those by shirt sizes, but I’m sure we’re on the better end of the absurdity scale…

At that point, you are estimating EFFORT, not time. Software engineers are REALLY GOOD at estimating effort. The fact that they translate to time (simple == several days) is ephemeral.

Re: Woodworking as an escape from the absurdity of software

#22

Post by asddubs »

jeromenerf wrote: post #20

You can find all the problems of Software in Woodworking, except that sometimes, using an axe is a legal and well-suited move.

You would basically never use an axe in woodworking. It's widely considered bad practice, produces unstable results, and there are better tools available

Re: Woodworking as an escape from the absurdity of software

#23

Post by throwaway4disc »

anonzzzies wrote: post #10

I am working on coding stuff I like as escape for the absurdity of modern software. I make little games, stuff for 8 bit systems etc. Stuff that is as far away from anything modern , especially the hell of node, next, devops and ‘web frameworks’ as I possibly can. It works. It’s very relaxing, like a bonsai tree.

[dead]

Re: Woodworking as an escape from the absurdity of software

#24

Post by Scarblac »

vedranm wrote: post #7
rettichschnidi wrote: post #5

Earlier quoted context omitted.

Any recommended readings on the "unable to estimate" claim?

I read Steve McConnell's Software Estimation: Demystifying the Black Art and I can recommend it without hesitation. It is quite old by now so there might be something newer and better out there as well.

That book says the opposite though, we can definitely make good estimates.

It's just that estimating well needs people with training on how to do that, and then it takes substantial time to make good estimates. And there will still be significant error bars (if the estimate isn't a range, it doesn't count as an estimate). But it's certainly doable.

Re: Woodworking as an escape from the absurdity of software

#25

Post by withinboredom »

cqqxo4zV46cp wrote: post #13
withinboredom wrote: post #4

Earlier quoted context omitted.

It's quite ridiculous for a number of reasons, well documented by research and experience: software engineers can't estimate how long something will take with any kind of accuracy.

Thanks, but this isn’t my first rodeo. In the future, please more carefully exercise more discretion when whipping out the snark. > software engineers can't estimate how long something will take with any kind of accuracy. This is both irrelevant and wrong. It’s irrelevant because t-shirt sizes, story points, and other abstract measures, are - intentionally - not measures of time. It’s a measure of effort, benchmarked…

I'm not sure you're agreeing with me and using disagreeing words, or you didn't read what I wrote...

Software engineers can't estimate how long things will take: https://www.sciencedirect.com/science/article/abs/pii/S02637...

They're wrong, 60% of the time by overestimation and when underestimated, so vastly wrong it's terrifying. I remember this one time I merely had to update a component in prod. Everything went fine in staging, then when I pressed the "button" in prod ... all hell broke loose. We spent the next 4 days fixing it.

I never wrote that software engineers can't estimate effort, I said they can't estimate time, but you're accusing me of the former.

Re: Woodworking as an escape from the absurdity of software

#26

Post by sanitycheck »

withinboredom wrote: post #4
cqqxo4zV46cp wrote: post #2

> when the Agile meetings at my last job got so absurd that we were being asked to estimate JIRA task time in T-shirt sizes Feels like a very outsized reaction to have to something well-intentioned, useful, and not-ridiculous.

It's quite ridiculous for a number of reasons, well documented by research and experience: software engineers can't estimate how long something will take with any kind of accuracy.

Software engineers, when quoting for fixed priced jobs, learn quite quickly to estimate accurately.

Software engineers, when pressured by managers to provide low estimates and/or to provide estimates quickly, will estimate inaccurately. (It can also be deliberately high as well as low, based on previous experience of having their estimates chopped in half.)

Whether you use SP or T-shirt sizes or whatever, somebody is translating that into days because days (and thus dollars) are what matter to the business. If someone asks me for an estimate, I'll give them a range in days/weeks, and they can turn it into whatever nonsense unit they like.

Re: Woodworking as an escape from the absurdity of software

#27

Post by XorNot »

cqqxo4zV46cp wrote: post #13
withinboredom wrote: post #4

Earlier quoted context omitted.

It's quite ridiculous for a number of reasons, well documented by research and experience: software engineers can't estimate how long something will take with any kind of accuracy.

Thanks, but this isn’t my first rodeo. In the future, please more carefully exercise more discretion when whipping out the snark. > software engineers can't estimate how long something will take with any kind of accuracy. This is both irrelevant and wrong. It’s irrelevant because t-shirt sizes, story points, and other abstract measures, are - intentionally - not measures of time. It’s a measure of effort, benchmarked…

Tell me, what is a unit of "effort"?

How would we measure that?

Re: Woodworking as an escape from the absurdity of software

#28

Post by withinboredom »

cqqxo4zV46cp wrote: post #19
rettichschnidi wrote: post #5

Earlier quoted context omitted.

Any recommended readings on the "unable to estimate" claim?

There are no good recommendations because it’s wrong. GP has taken “software estimation is hard and very imprecise” and vastly misrepresented it to try to dunk on someone on the internet. It’s this sort of disinformation that perpetuates the contingent of software developers that cry bloody murder whenever they’re asked to say if something will take a day or a year.

I never wrote what you quoted. Please don't misquote me to "try to dunk on someone on the internet."

Re: Woodworking as an escape from the absurdity of software

#30

Post by qiqitori »

mavamaarten wrote: post #14
withinboredom wrote: post #3

Supporting software is the hardest job, IMHO. People ask some really dumb stuff -- not out of stupidity, but of ignorance; they just don't know what they are asking. To them, the "why is this broken" is "100% your fault and 100% fixable but you are too lazy to fix it." It's maddening, annoying, and 99% of the time, not worth dealing with if you can help it.

Absolutely. People nag our customer service until they get redirected to us (software engineers). When you finally spend expensive time looking into their issue, finding the root cause on their end, take the time to explain it in detail, more often than not the answer is among the lines of "couldn't be bothered to read your response, it still doesn't work, fix it!". I love software development. I love building both s…

It's the same with many things. Hotel users suck sometimes, restaurant users suck sometimes, even museum users suck sometimes. Some people are grateful, some people think you're the hostile one.
Post reply on HN