Kicking the tires: A trial month at 37signals
37signals.com
Kicking the tires: A trial month at 37signals
1–10 of 18 posts
Re: Kicking the tires: A trial month at 37signals
#2A 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?
Re: Kicking the tires: A trial month at 37signals
#3A 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.
Re: Kicking the tires: A trial month at 37signals
#4A 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.
Re: Kicking the tires: A trial month at 37signals
#5Every 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.
Re: Kicking the tires: A trial month at 37signals
#6A 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?
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.
Re: Kicking the tires: A trial month at 37signals
#7A 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 12…
There's an enormous middle ground between the two extremes you're portraying, though.
Re: Kicking the tires: A trial month at 37signals
#8A 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 12…
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.
Re: Kicking the tires: A trial month at 37signals
#9Earlier quoted context omitted.
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 12…
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.
Re: Kicking the tires: A trial month at 37signals
#10A 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?
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.