Kicking the tires: A trial month at 37signals • Hacker News Board

Re: Kicking the tires: A trial month at 37signals

#11

Post by ceejayoz » Fri, Jan 13, 2012, 9:37 PM UTC

patio11 wrote: post #9

ceejayoz wrote: post #7

Earlier quoted context omitted.

There's an enormous middle ground between the two extremes you're portraying, though.

True. If, for example, you're a consulting company, you could have an intermediate developer sit down and watch every junior developer as he codes. The intermediate developer could then say "Oh, dude, nice try but stripping all HTML will probably bork at least some customers' sites. Here, let me open a console on prod and fire a quick SQL query that would get me fired at TPS Reports Inc. Ahh yes, it appears customers…

@qrush is a far, far better programmer than I. Still, "let's find out how many todo items this is going to affect first" seems like a fairly logical checkpoint on a large production system.

Re: Kicking the tires: A trial month at 37signals

#12

Post by sanderjd » Fri, Jan 13, 2012, 9:56 PM UTC

qrush wrote: post #3

jdludlow wrote: post #2

A brand new Basecamp developer is allowed to push a change like "disable HTML support" directly into production, without anyone pointing out that it might be a bad idea? Seriously?

To clarify here, I was fixing invalid HTML in todos, not disabling it entirely. There were some HTML tags people used that I wasn't aware of. Let's be honest, we're all human here and make mistakes, I took responsibility for it and learned a lot in the process.

It has nothing to do with you screwing up. Of course every individual person makes mistakes pretty much constantly, which is why there is a whole team developing an application, and why there is pair programming, and why there are code reviews, and why there are tests. As a customer of Basecamp, it doesn't worry me that you made that mistake - totally easy mistake to make - but that nobody else noticed it and no automated tests caught it. It seems to me that 37signals may have gone too far the opposite way in their rejection of process and stifling rules.

Re: Kicking the tires: A trial month at 37signals

#13

Post by jdludlow » Fri, Jan 13, 2012, 11:09 PM UTC

sanderjd wrote: post #12

qrush wrote: post #3

Earlier quoted context omitted.

To clarify here, I was fixing invalid HTML in todos, not disabling it entirely. There were some HTML tags people used that I wasn't aware of. Let's be honest, we're all human here and make mistakes, I took responsibility for it and learned a lot in the process.

It has nothing to do with you screwing up. Of course every individual person makes mistakes pretty much constantly, which is why there is a whole team developing an application, and why there is pair programming, and why there are code reviews, and why there are tests. As a customer of Basecamp, it doesn't worry me that you made that mistake - totally easy mistake to make - but that nobody else noticed it and no auto…

Yes, this is what I meant. Sorry if my original post came off too strongly. I didn't mean "haha you screwed up." We've all screwed up. It was more a commentary on how no other devs, unit tests, or human testers caught this before it went live.

Re: Kicking the tires: A trial month at 37signals

#14

Post by jeffrydegrande » Fri, Jan 13, 2012, 11:18 PM UTC

sanderjd wrote: post #12

qrush wrote: post #3

Earlier quoted context omitted.

To clarify here, I was fixing invalid HTML in todos, not disabling it entirely. There were some HTML tags people used that I wasn't aware of. Let's be honest, we're all human here and make mistakes, I took responsibility for it and learned a lot in the process.

It has nothing to do with you screwing up. Of course every individual person makes mistakes pretty much constantly, which is why there is a whole team developing an application, and why there is pair programming, and why there are code reviews, and why there are tests. As a customer of Basecamp, it doesn't worry me that you made that mistake - totally easy mistake to make - but that nobody else noticed it and no auto…

Nick says he wasn't aware of a couple of tags. I think it's fair to assume there were tests, and plenty of them but a use case was overlooked. Which I think is perfectly reasonable. Automated tests don't catch what you don't know.

This doesn't say anything about 37s and how they work. I guess the only thing that matters is how much time it took for a fix to be deployed.

Re: Kicking the tires: A trial month at 37signals

#15

Post by bdonlan » Sat, Jan 14, 2012, 1:14 AM UTC

leftnode wrote: post #10

rpwilcox wrote: post #6

Earlier quoted context omitted.

One of the cool things about continuous deployment is that rush of, "Here's a new feature, right now! You don't have to wait! It doesn't break any specs, so it must work and be a good idea!" One of the downsides is that bugs like this creep in, because there's no QA step. (and code review is not QA). So, push something that accidentally breaks the app? Oops. The good thing about a continuous deployment strategy is th…

Of course, you can have an intermediary staging system set up so you continuously deploy to it first, and if everything looks good, then deploy to production.

Sure, but that wouldn't catch this issue unless you're looking at customer data that uses these particular html tags.

Re: Kicking the tires: A trial month at 37signals

#16

Post by sanderjd » Sat, Jan 14, 2012, 1:22 AM UTC

jeffrydegrande wrote: post #14

sanderjd wrote: post #12

Earlier quoted context omitted.

It has nothing to do with you screwing up. Of course every individual person makes mistakes pretty much constantly, which is why there is a whole team developing an application, and why there is pair programming, and why there are code reviews, and why there are tests. As a customer of Basecamp, it doesn't worry me that you made that mistake - totally easy mistake to make - but that nobody else noticed it and no auto…

Nick says he wasn't aware of a couple of tags. I think it's fair to assume there were tests, and plenty of them but a use case was overlooked. Which I think is perfectly reasonable. Automated tests don't catch what you don't know. This doesn't say anything about 37s and how they work. I guess the only thing that matters is how much time it took for a fix to be deployed.

It is reasonable, and testing can't catch everything, but it does say something about them, though I don't think it's anything they wouldn't say about themselves - their top priority is not assuring quality, but assuring that quality lapses can be, and are, quickly rectified. That's fine, but it's not for every application or every team.

Re: Kicking the tires: A trial month at 37signals

#17

Post by weaksauce » Sat, Jan 14, 2012, 6:09 AM UTC

patio11 wrote: post #9

ceejayoz wrote: post #7

Earlier quoted context omitted.

There's an enormous middle ground between the two extremes you're portraying, though.

True. If, for example, you're a consulting company, you could have an intermediate developer sit down and watch every junior developer as he codes. The intermediate developer could then say "Oh, dude, nice try but stripping all HTML will probably bork at least some customers' sites. Here, let me open a console on prod and fire a quick SQL query that would get me fired at TPS Reports Inc. Ahh yes, it appears customers…

what's wrong with adding tags at the end of the user editable areas that are unmatched so the rest of the page does not break when they add unbalanced html? I think they should parse it and make sure it's legit html before blindly saving it(xss possibilities if anything is public facing et. al.).

Re: Kicking the tires: A trial month at 37signals

#18

Post by patio11 » Sat, Jan 14, 2012, 6:45 AM UTC

weaksauce wrote: post #17

patio11 wrote: post #9

Earlier quoted context omitted.

True. If, for example, you're a consulting company, you could have an intermediate developer sit down and watch every junior developer as he codes. The intermediate developer could then say "Oh, dude, nice try but stripping all HTML will probably bork at least some customers' sites. Here, let me open a console on prod and fire a quick SQL query that would get me fired at TPS Reports Inc. Ahh yes, it appears customers…

what's wrong with adding tags at the end of the user editable areas that are unmatched so the rest of the page does not break when they add unbalanced html? I think they should parse it and make sure it's legit html before blindly saving it(xss possibilities if anything is public facing et. al.).

I think if you have two developers continue this conversation to its logical conclusion with bouts of coding and testing interspersed, you will bill $10k.