Responding to “Are bugs and slow delivery ok?” • Hacker News Board

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

#101

Post by g4zj » Thu, Jul 06, 2023, 5:58 PM UTC

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…

> 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 I know from experience how it can come back to haunt me.

I try to suggest saving such speculation for a time, hopefully in the near future, where the initial research has been completed and _some_ progress has been made on the foundation of the requested work, so that my speculation can have some basis in reality.

If all else fails, I give a wild estimate that I don't expect anyone to agree to, such as 2 years for work that might not even take 2 or 3 months.

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

#102

Post by tomxor » Thu, Jul 06, 2023, 6:10 PM UTC

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…

> but what they delivered always had "bugs" (either actual incorrect behavior, or edge cases that nobody thought of until they actually used the software)

This is why they are not only inevitable but unending.

Most real world problems are so large and messy that they do not have closed form solutions. In this context "bug" more often means a deficiency, a reflections of changing or competing and incompatible requirements, than abstract mistakes.

In this context, I've learned to appreciate the choice becomes "which bugs", because "fixing" such bugs is not necessarily a net positive, especially when the fix is not a natural fit for the design or architecture of the overarching solution. The mindless, incessant fixing of such bugs on a case-by-case basis can result in accumulation of so much complexity and LoC it becomes self perpetuating in bug fixing alone. When you are conscious of this, and have enough respect and autonomy, it's possible to decide whether it's worth this intangible cost, or whether to put it into the pile of "wont fix", this kind of decision requires cross domain collaboration. But that pile is not worthless, you can periodically revisit it and see opportunities to a fundamentally different approach that may tick more boxes (or more preferable boxes) without being ad-hock.

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

#103

Post by CKMo » Thu, Jul 06, 2023, 6:22 PM UTC

Bugs in cybersecurity products are not okay at all. We call those zero-days.

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

#104

Post by mandevil » Thu, Jul 06, 2023, 6:25 PM UTC

commandlinefan wrote: post #57

embwbam wrote: post #46

Earlier quoted context omitted.

In my experience, one can accurately predict development time by correctly working around the planning fallacy. The planning fallacy is something like "Humans are hopelessly optimistic. Even if you think you're planning for the worst case, unexpected things will happen, and your estimate is more like the best case scenario. This is true even if you try to compensate for the planning fallacy by being more pessimistic"…

> How long did it ACTUALLY take Haha, I came to that same conclusion decades ago - I don't know if it would actually produce meaningful estimates or not, though, because every time I try to estimate that way, somebody more "important" than me comes along and throws out that estimate for one that fits the timeline he already had in mind.

And then the CTO complains that no one ever tells him the truth on how long a project will take.

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

#105

Post by commandlinefan » Thu, Jul 06, 2023, 6:37 PM UTC

vegetablepotpie wrote: post #94

cameldrv wrote: post #81

Earlier quoted context omitted.

Software does not have to be wildly unpredictable if you do good estimation work up front. Being good at this is very important if you work for clients that have a specific budget or are doing fixed bids for software. The main thing is that you have to take estimation very seriously. You have to put experienced people on the estimation task, and you have to spend a lot of time on it to get it right, but doing it righ…

Everything you describe works well for estimating tasks that can be automated. If you’re doing that kind of work, your employer will be happy to replace you with an AI system.

> replace you with an AI system

Or a couple of Excel macros.

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

#106

Post by Arrath » Thu, Jul 06, 2023, 7:34 PM UTC

AnthonyMouse wrote: post #70

embwbam wrote: post #46

Earlier quoted context omitted.

In my experience, one can accurately predict development time by correctly working around the planning fallacy. The planning fallacy is something like "Humans are hopelessly optimistic. Even if you think you're planning for the worst case, unexpected things will happen, and your estimate is more like the best case scenario. This is true even if you try to compensate for the planning fallacy by being more pessimistic"…

As far as I can tell there are two major problems with this. The first is that you can predict that there will be unforeseen problems, but not how many of them nor how long each will take to resolve. The result is high variance. Then if the average such project takes 16 months, and you predict each such project will take 16 months, then some take 7 months and some take 17 months and some take 25 months and people get…

The third major problem:

Project Manager/Scheduler/Sales/Customer doing one/any/all of: not believing the input of the SME (you) when they ask for input developing the schedule, overpromising, expecting the world, or so many other problems.

Too many times in my own field (heavy construction) the scheduler has asked me how long it will take to do a given task, and it is actually reasonably quantifiable to say "It will take my crew X days to move Y volume of material at Z/shift" only to be told "Well our proposal only allocated X-5 days and budgeted a Crew of for that task. Figure it out."

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

#107

Post by nickelbob » Thu, Jul 06, 2023, 8:13 PM UTC

tikhonj wrote: post #90

> Software doesn’t make or break an organization. This is true... but it's also true of ≈everything else in the organization. An organization that could be broken by any single thing would not survive for long! This includes the things people tediously insist to be "more important" than software quality. It certainly includes the usual suspects that push people to cut software corners: companies don't break by missin…

> This is true... but it's also true of ≈everything else in the organization.

Except for sales?

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

#108

Post by nickelbob » Thu, Jul 06, 2023, 8:18 PM UTC

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…

Perhaps one solution is to divorce your own self worth from the quality of the software you happen to write and to realize that you are an employee first and a software engineer second - make decisions that increase the amount of money the company makes and look for self worth in that itself or in hobbies/family/friends/something else.

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

#109

Post by newaccount74 » Thu, Jul 06, 2023, 9:00 PM UTC

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…

In practice, the implementations will end up crossing a few times anyway (bugs) and noone cares much because software bugs are a part of life.

Speed only goes to zero if you insist on bug free software.

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

#110

Post by ianmcgowan » Thu, Jul 06, 2023, 9:16 PM UTC

embwbam wrote: post #46

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…

In my experience, one can accurately predict development time by correctly working around the planning fallacy. The planning fallacy is something like "Humans are hopelessly optimistic. Even if you think you're planning for the worst case, unexpected things will happen, and your estimate is more like the best case scenario. This is true even if you try to compensate for the planning fallacy by being more pessimistic"…

This is the only thing that ever works for me, but a) you have to be doing repeated projects or high overlap, and b) it's hard to defend when a PM challenges. My response is usually " this is how long this kind of thing has taken in the past". I do a lot of the same projects at different customers, so my gut feel is usually pretty close (and I have to give a ballpark quote, so there's some penalty to being over or under). But if it's something completely new, breaking it down in to detail tasks almost never results in a good estimate.