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

Responding to “Are bugs and slow delivery ok?”

uselessdevblog.wordpress.com

Post reply on HN
Print view View original

111–120 of 128 posts

Re: Responding to “Are bugs and slow delivery ok?”

#111

Post by xupybd »

distcs wrote: post #47
userbinator wrote: post #6

Both this article and the one it references only seem to provide more evidence that the descent into mediocrity of the software industry is certainly happening. That said, there's a difference between actual quality, and "quality" as popularised by metrics-driven dogma.

It really saddens me to know that the hacker culture I once so much loved to be part of is rapidly disappearing from the industry.

Is it? Or is a massive industry forming around a still small group of hackers?

Maybe the two are groups are not the same. Someone getting into software to make money is different to the kid who couldn't put the computer down. There are people that want to hack on software and others that want to solve business problems with computers for profit.

Re: Responding to “Are bugs and slow delivery ok?”

#112

Post by tru1ock »

bedobi wrote: post #18

The problem is that anyone with a semblance of professional pride will find it mentally quite difficult to knowingly ship bad software. Like, sure, even if we make best efforts to catch both obvious and less obvious bugs, all software we ship will still be full of bugs. But knowingly shipping software full of obvious bugs... it feels unprofessional. And makes you really feel the weight of all the inevitable bug repor…

You are not professional if you are not aligning with the values that are being optimized for the context. There should be an explicit decision tree setup for your work context that informs you what those values are. If not have some conversations and align.

Re: Responding to “Are bugs and slow delivery ok?”

#113

Post by idbehold »

wokwokwok wrote: post #54

So, here’s a simple game: - take a blank piece of paper (this is “the software”) - pick two random points on the paper roughly 3 inches apart (“a requirement”) - draw a line between the two points; the line cannot cross any other line (“the implementation”). Repeat the exercise multiple times. You’ll quickly learn that unless you have a “system”, drawing a three inch line goes from taking about 2 seconds, to taking 1…

What "system" would you use for random "requirements" (dots on a piece of paper)? The only reasonable thing to do is to push back on "requirements" that don't fit into the existing requirements/software/implementation.

Re: Responding to “Are bugs and slow delivery ok?”

#114

Post by [deleted] »

g4zj wrote: post #101
qingcharles wrote: post #45

Earlier quoted context omitted.

Thank you for (1). I was trying to explain to someone the other day how unpredictable coding is, but you're right, it's wildly unpredictable. Even for tiny projects they sometimes go so far off the rails. I remember working on this one major project - an online music store - and one of the execs hired his very lovely wife to project manage a team of developers. She would create these fantastic charts in Microsoft Pro…

> I've been writing code for 40 years and I still get caught out myself. I try to give realistic deadlines [...] Call it immaturity, or perhaps just not being a "team player", but I've been coding for 15 years and stopped giving time estimates about 5 years ago. I simply refuse, and instead, explain that I would just be making something up, and I'm not interested in taking responsibility for an arbitrary guess, since…

[deleted]

Re: Responding to “Are bugs and slow delivery ok?”

#115

Post by wokwokwok »

idbehold wrote: post #113
wokwokwok wrote: post #54

So, here’s a simple game: - take a blank piece of paper (this is “the software”) - pick two random points on the paper roughly 3 inches apart (“a requirement”) - draw a line between the two points; the line cannot cross any other line (“the implementation”). Repeat the exercise multiple times. You’ll quickly learn that unless you have a “system”, drawing a three inch line goes from taking about 2 seconds, to taking 1…

What "system" would you use for random "requirements" (dots on a piece of paper)? The only reasonable thing to do is to push back on "requirements" that don't fit into the existing requirements/software/implementation.

The thing about this game is that there is no requirement that is technically impossible.

That's provable; with no closed loops, any pair of points on the paper can be joined by a long enough line. That's why it's a good analogy for code.

...but if you, eg. a system for this; Use straight lines only and space the lines equidistant from other lines.

I mean, it's a game. Literally play the game a few times (grab a friend and do it together) and you'll very quickly figure out things that do work (leaving space) and dont work (draw crazy squiggly lines and lines that are too close together).

This is just a contrived example; if you want to make it more realistic allow 'you can erase a line and redraw it as long as the requirement is maintained', and then you can structure lines into groups, etc.

Re: Responding to “Are bugs and slow delivery ok?”

#116

Post by idbehold »

wokwokwok wrote: post #115
idbehold wrote: post #113

Earlier quoted context omitted.

What "system" would you use for random "requirements" (dots on a piece of paper)? The only reasonable thing to do is to push back on "requirements" that don't fit into the existing requirements/software/implementation.

The thing about this game is that there is no requirement that is technically impossible. That's provable; with no closed loops, any pair of points on the paper can be joined by a long enough line. That's why it's a good analogy for code. ...but if you, eg. a system for this; Use straight lines only and space the lines equidistant from other lines. I mean, it's a game. Literally play the game a few times (grab a frie…

Ah, so you are pushing back on the requirements. "I'm not going to implement the requirement (two random dots added) as it would break my requirement to only have straight lines in my implementation."

Re: Responding to “Are bugs and slow delivery ok?”

#117

Post by wokwokwok »

idbehold wrote: post #116
wokwokwok wrote: post #115

Earlier quoted context omitted.

The thing about this game is that there is no requirement that is technically impossible. That's provable; with no closed loops, any pair of points on the paper can be joined by a long enough line. That's why it's a good analogy for code. ...but if you, eg. a system for this; Use straight lines only and space the lines equidistant from other lines. I mean, it's a game. Literally play the game a few times (grab a frie…

Ah, so you are pushing back on the requirements. "I'm not going to implement the requirement (two random dots added) as it would break my requirement to only have straight lines in my implementation."

There's no part of anything I posted that required straight lines.

Whether you use structured code (straight lines and spacing) or squiggles (spaghetti code) is up to you as the developer implementing the requirement.

Re: Responding to “Are bugs and slow delivery ok?”

#118

Post by DanielHB »

watt wrote: post #55
qingcharles wrote: post #45

Earlier quoted context omitted.

Thank you for (1). I was trying to explain to someone the other day how unpredictable coding is, but you're right, it's wildly unpredictable. Even for tiny projects they sometimes go so far off the rails. I remember working on this one major project - an online music store - and one of the execs hired his very lovely wife to project manage a team of developers. She would create these fantastic charts in Microsoft Pro…

If the code you write is uncovering bugs in compiler, you literally are too smart for your own good. Fwiw, I have seen how compilers are made. Makes me amazed anything actually compiles and runs.

I have run into bugs that only happened in specific linux kernel versions when used with specific java runtimes

Re: Responding to “Are bugs and slow delivery ok?”

#119

Post by joshspankit »

qingcharles wrote: post #45
commandlinefan wrote: post #21

I've been coding now for about 30 years. I've never moved up into management and, now at almost 50, it's pretty clear I never will, and will spend the remainder of my career coding (which I'm perfectly fine with). In the 30 years I've been coding, languages have come and gone, platforms have come and gone, frameworks have come and gone, methodologies have come and gone, but two things have never changed: 1) Software…

Thank you for (1). I was trying to explain to someone the other day how unpredictable coding is, but you're right, it's wildly unpredictable. Even for tiny projects they sometimes go so far off the rails. I remember working on this one major project - an online music store - and one of the execs hired his very lovely wife to project manage a team of developers. She would create these fantastic charts in Microsoft Pro…

At some point I ran across this strategy for estimating when you’re the one doing it: Take whatever time you think it’ll take, then double it. Then add 20%*

Things still go off the rails of course making an an imperfect solution, but it ends up being more right than any other method I’ve tried.

*If there are any unknown unknowns I might start multiplying by the number of big ones.

Re: Responding to “Are bugs and slow delivery ok?”

#120

Post by sanitycheck »

commandlinefan wrote: post #78
sanitycheck wrote: post #74

Earlier quoted context omitted.

You can make some good guesses about levels of unpredictability based on previous experience though. For example: If the job involves dealing with anyone from Samsung or LG, it will take 2-3 times as long as you think. If the job involves adding in a commercial third-party component which has a website about it, and that website doesn't clearly explain what the benefit of the thing actually is, the job will take 10-2…

> the job will take 10-20 times as long as it should. But your CTO will think it will take 10-20 times less time than it should, because that's what the vendor promised.

CTO's can't all be idiots, some of them will only be pretending to think that.
Post reply on HN