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

91–100 of 128 posts

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

#91

Post by icedchai »

ryandrake wrote: post #11
PragmaticPulp wrote: post #7

> You know what I haven’t seen? not once in 15 years? > A company going under. What a wild assertion: The OP hasn’t personally seen a company fail, and therefore software quality doesn’t matter? Bugs and slow delivery are fine? It’s trivially easy to find counterexamples of companies failing because their software products were inferior to newcomers who delivered good results, fast development, and more stable experi…

“My company didn’t go under” is pretty much the lowest bar you can shoot for. This blog post is saying “Staying healthy doesn’t matter because neither I nor anyone I know died so far.”

From personal experience with early stage startups, it is quite a low bar. I've seen companies "acquired" for pennies on the dollar, after almost the entire staff is laid off. Somehow, this is considered a success even though you would've had an better outcome investing your time and money in almost anything else. Employees lost, investors lost. The founder often gets a cushy job they could've had anyway.

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

#92

Post by jackhack »

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.

> If the code you write is uncovering bugs in compiler, you literally are too smart for your own good.

Definitely not in my case -- sometimes we just stumble over these things. As an inexperienced programmer (around 1989 or 1990?) I found a bug in the beta of microsoft's first C++ compiler, shipped on a dozen 5.25" floppy discs. All the other developers around me said "Don't be stupid. It's your code, it's not the compiler!" but I distilled it down to a minimal test case and proved it. The bug?

i=i+i;

That's it. It would give random results based on prior instructions unrelated to i.

I reported it and got a nice note back from the MSFT engineering team. Something like "Wow! I've no idea how we missed this. Good catch!"

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

#93

Post by tshaddox »

cameldrv wrote: post #81
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…

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…

> Software does not have to be wildly unpredictable if you do good estimation work up front.

You also need someone with 1) strong technical and/or product skills, 2) good communication skills and decisiveness, and 3) explicit executive authority. That's the only way to avoid scope creep and bikeshedding.

When you started working on a project without knowing what you're building, or end up delivering a very different project than what was originally planned, it's hard to even say "that project was late." No it wasn't: you just never built whatever you had promised to build by the original deadline.

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

#94

Post by vegetablepotpie »

cameldrv wrote: post #81
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…

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.

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

#95

Post by esafak »

PragmaticPulp wrote: post #7

> You know what I haven’t seen? not once in 15 years? > A company going under. What a wild assertion: The OP hasn’t personally seen a company fail, and therefore software quality doesn’t matter? Bugs and slow delivery are fine? It’s trivially easy to find counterexamples of companies failing because their software products were inferior to newcomers who delivered good results, fast development, and more stable experi…

Friendster is memorable example. It did not scale well, and fed up users flocked to MySpace and Facebook, which came later.

More generally it depends on how competitive the space the product operates in, whether quality is something the buyer values and is able to evaluate! Enterprises for example infamously don't appreciate quality as much consumers because the economic buyer does not use the product.

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

#96

Post by vegetablepotpie »

Palomides wrote: post #82
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…

splitting a project into an open ended "exploratory phase" of undefined length followed by a "main phase" of defined length doesn't seem like it would make any change to the total time taken, just shifting around the unpredictability

Right, and that’s Tesler’s law restated. You’re really just shifting complexity and not reducing it.

Where it makes sense is from a sociocultural perspective. Under Taylorist management philosophy, management is to do the thinking, and workers are to do the doing. Structuring a project where managers take on the exploratory phase fits well within the set of assumptions taught in project management programs.

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

#98

Post by arzke »

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

> That is to start with prior evidence. Rather than making your estimate, start with "How long did it ACTUALLY take the last time someone did something like this?" and only then modifying the estimate for circumstances.

This requires to have prior evidence within your team to start with as not all teams have the same velocity.

Post reply on HN