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

Incuriosity Will Kill Your Infrastructure

yellerapp.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Incuriosity Will Kill Your Infrastructure

#11

Post by MichaelGG »

pjungwir wrote: post #5

Not just your infrastructure, your code base too. I've seen a lot of developers practice what I call "debugging by superstition," where they make random changes until it appears to work. I prefer to keep digging until I understand. Sometimes I make a hypothesis and test it, which superficially resembles debugging by superstition but is different. One benefit of experience is that you gain a better intuition about you…

Yes I get very annoyed when I see some strange looking code written because the right way "didn't work" or "there was a problem". Sometimes that's a legitimate reason, with legacy/buggy/messy systems, when you just don't have the time or effort to do it right. But then at least document the hack as what it is. And what the general issue with the obvious approach was.

Re: Incuriosity Will Kill Your Infrastructure

#12

Post by isaacaggrey »

optimusclimb wrote: post #9

So what I want to know, is, as per all the recent agile/scrum discussions - how does the modern "do sprint planning/commit to a number of sprint points to do/tasks to work on/be the product manager's monkeys" align with, "you saw something that's probably representative of a major problem in your system, but stopping what you're doing to investigate it will kill your velocity, and make your team's statistics look bad…

Any time a sprint commitment must be broken the decision rests on the team's product manager who is best (or _should_ be best) suited to understanding the tradeoff between sprint completion and a potential emergency bug situation. If the PM decides it's not worth it, then that's on them. It's worth noting, you may want to include a wide enough distribution so it's known that you noticed but PM didn't want you to work on it in order to cover yourself.

As for how to account for that work in your velocity, I don't believe it is realistic to size a story for fixing a potential issue (not to mention the difficulties in sizing bugs anyway [1]). However, it is possible (or at least a bit easier) to size a story for research that answers a specific question as its acceptance criteria -- in this case, the acceptance criteria for this article's situation would've been something like 1) "will latency continue to rise?" and 2) if so and it is unacceptable, what is the cause and add an implementation story to the backlog"

Some may say "well, how do you know how what is causing the issue", and if no one really can figure it out the answer to the research story question and the bug has manifested itself as an emergency, then sure your velocity will tank as you break the sprint(s), but it's up to the team/business to understand how to remove outliers for an accurate velocity.

[1]: http://www.agileforall.com/2010/05/agile-antipattern-sizing-...

Re: Incuriosity Will Kill Your Infrastructure

#13

Post by optimusclimb »

isaacaggrey wrote: post #12
optimusclimb wrote: post #9

So what I want to know, is, as per all the recent agile/scrum discussions - how does the modern "do sprint planning/commit to a number of sprint points to do/tasks to work on/be the product manager's monkeys" align with, "you saw something that's probably representative of a major problem in your system, but stopping what you're doing to investigate it will kill your velocity, and make your team's statistics look bad…

Any time a sprint commitment must be broken the decision rests on the team's product manager who is best (or _should_ be best) suited to understanding the tradeoff between sprint completion and a potential emergency bug situation. If the PM decides it's not worth it, then that's on them. It's worth noting, you may want to include a wide enough distribution so it's known that you noticed but PM didn't want you to work…

Yeah, I figured someone would respond that way. I have a feeling that the more process that lies around making such fixes...the more likely the system is likely to be under performing (and or broken) long term.

Re: Incuriosity Will Kill Your Infrastructure

#16

Post by t__crayford »

jd007 wrote: post #4

Not related to the post, but after going to the main Yeller page, I noticed that at the bottom one of the features listed is "HTTPS Everywhere (we don't even allow HTTP over our API or website)", yet the site is not over SSL at all. In fact manually entering HTTPS in the URL shows that the certificate is not valid.

Hi (author/founder of Yeller) here.

You're totally right, I need to change the wording there. The marketing site doesn't run over https - I'm bootstrapping, with relatively limited funds, and so can't properly afford the SSL costs for a CDN (my current one wants to charge $600 or so a month for serving ssl requests).

The webapp and the api are all HTTPS only.

I should change the wording on that page to reflect that.

Re: Incuriosity Will Kill Your Infrastructure

#18

Post by t__crayford »

mattbreeden wrote: post #14

Can't find any way to contact you guys, so hopefully you'll read it here. On OSX Chrome v 41, the 'Subscribe to your free one month course' button extends a decent amount beyond the pink box on the right side.

Post author/founder of Yeller here:

Huh, interesting. That's my setup as well. I'm not super great at CSS (yet), so not too surprised by a few minor visual bugs like that. I'll fix it soon. Thanks so much.

Re: Incuriosity Will Kill Your Infrastructure

#19

Post by protomyth »

pjungwir wrote: post #5

Not just your infrastructure, your code base too. I've seen a lot of developers practice what I call "debugging by superstition," where they make random changes until it appears to work. I prefer to keep digging until I understand. Sometimes I make a hypothesis and test it, which superficially resembles debugging by superstition but is different. One benefit of experience is that you gain a better intuition about you…

I saw this in a code base once:

  Line above commented out seems to fix Bug 34541
This makes for an impressive code land mine and creates some seriously unhealthy superstitions.

Re: Incuriosity Will Kill Your Infrastructure

#20

Post by mvc »

optimusclimb wrote: post #9

So what I want to know, is, as per all the recent agile/scrum discussions - how does the modern "do sprint planning/commit to a number of sprint points to do/tasks to work on/be the product manager's monkeys" align with, "you saw something that's probably representative of a major problem in your system, but stopping what you're doing to investigate it will kill your velocity, and make your team's statistics look bad…

Your sprint budget should be some percentage less than the average velocity over the past 3 sprints. That allows for bugs to be fixed mid-sprint without affecting velocity.

Velocity shouldn't be used to measure how "good" the team is.

Post reply on HN