Kicking the tires: A trial month at 37signals | Hacker News Reader

Kicking the tires: A trial month at 37signals

37signals.com

47 pointswlll17 comments

Every time I read about 37signals and how they work I get a wave of jealousy and impatience. Its refreshing to know that there are some companies out there that treat their employees like humans and not cogs in the machine. Its also refreshing to know you can run a business at the scale of 37signals without huge bureaucracies.

I know they aren't the only ones who do this but they are vocal about it, and when your living/working in enterprise land (MKE/Midwest) its good to remember it doesn't need to be this way.

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?

There exist plenty of organizations where a manager would have reported in April 2012: "Hey Bob, the $PEON_1846 on the QR team in $LOCATION reported that $COMMIT breaks requirement 1,735: todos must allow embedding the following restricted subset of HTML. Refer to requirements documents /shares/documents/basecamp/specs/dashboard/subcomponents/todo/functional_spec.xls sheet Content Embeds page 3. Submitted as issue 124,436 in the tracker, assigned to the June milestone. Get it done by then, otherwise we can't fix it until September prior to the Q4 code freeze, but turn in your TPS reports first."

Basecamp would be a very different product if it was made that way, though.

There are non-zero costs associated with giving people the authority to do productive work. On the plus side, this enables them to do productive work.

P.S. Having worked at an organization which did development that way, I can tell you that having copious documentation does not mean requirement 1,735 will be implemented, but it guarantees requirement 1,735 will be written about somewhere, which is what that organization type ends up optimizing for.

It can be worse than that.

Unfortunately adding issue 124,436 into the tracker puts the manager responsible for $SYSTEM over quota for exceptions. Most likely that item or one similar will be placed on a completed project just to get back under quota. Nobody needs issue 98,402 fixed if issue 124,436 prevents you from reaching it, right?

I wish this wasn't the world we lived in, but such management tactics will never really die.

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 do indeed embed HTML. OK, let's do this the long way."

This would allow you to bill, ballpark, $10,000 for "Enhancement: forgetting to close a tag in a todo no longer borks site."

But, while not being TPS Reports Inc, that is still a pretty different environment than what 37Signals operates in.

@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.

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.

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.

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.

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.

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 that the engineer can turn around right away and push a fix. Low ceremony helps here, "Oops, forgot to add this file to the source repo" can be fixed fast.

I've been with clients where a "continuous deployment" strategy would have meant, "continuously putting out fires, throwing any idea of development process out the window". But, Nick said his job was essentially dev support of QA, where you might not want to wait for the next two week iteration to schedule a ticket to fix a bug in production.

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.

Reply on news.ycombinator.com