Wow, there is so much wisdom here, I don't know where to start. So I'll just say that I have encountered almost every one of these situations at one point or another, and Jason is almost dead on.
The most important one for me is probably #3 "Get Rid of Abstractions". I learned this one the hard way. Now I just work on the problem at hand and worry about how to extend it later. It's a lot easier to generalize a specific case than to write something generalized in the first place. Could have saved me years.
Here here - In our project, its packed with generic features - most of them haven't be used ever and were released ages ago. Often they really complicate the application with lookup tables and weird logic that never sees the light of day, 'just incase'!
I just finished an app with 51 separate modules, every one hard coded in infinite detail, and much of the code duplicated, 4000 LOC in all. Crazy, right? I used to think so, too. I could have written one very flexible parameter driven module in a few hundred LOC.
But guess what? Even though I bitched and moaned the whole time I wrote the monster, I was able to refactor and "genericize" it in one day. Start to finish time was much shorter than if I had written the flexible module first (that is, if I had ever finished).
This was a non-intuitive lesson for me. Write the specific case and extend later. I always used to try to write the most comprehensive "able to do anything" code until I realized that sometimes, the long way around is actually quicker.
This seems like a great idea if you are committed to immediately refactoring. The problem is that most people move onto something else as soon as they have something that works. In this case, the code becomes a maintenance nightmare until someone actually takes the time to refactor it.
When immediate refactoring is unlikely (either due to laziness, lack of focus, or feature deadlines), some kind of balance has to be reached on what should be more general and reusable and what should be hard-coded and specific. And then we're right back where we started.
But reading and thinking about your posts has been very insightful. On my next project, I will try your approach. I agree that in the long run, it is likely to be a more efficient use of time. I imagine, though, that someone coding in this style will either have to have a great memory or take good notes in order to know where similar code is located. Especially consider the case of generalizing the code from one project to another project.
Like I said, it wasn't easy doing it this way. Every bone in my body screamed, "What's wrong with you? Stop replicating code! Write flexible functions!" But I struggled on until everything worked perfectly.
Here's the good news: I couldn't wait to refactor. I was "in the zone" the whole day. And it felt great. I finally got to clean up the mess that I made, and best of all, I didn't have to struggle trying to figure out how to handle that strange outlying case: it was all already there!
I don't know if I'd try this in someone else's shop. You're right; they'd probably pull me off before I got to refactor, leaving a mess for someone else with nothing learned.
I'm a huge fan of 37 signals' products and company philosophy. I bet this presentation is going to be the total opposite of most people speaking at the conference - I mean who else is going to get up there and talk about "Planning is vastly overrated" and "Underdoing."
Most presenters are going to focus on all of the amazing features their products offer...however, 37 signals is still more successful than 95% of those other companies.
Was a highly dynamic and fast moving presentation. Was impressed with Jason's delivery. Definitely a rock star of Web 2.0 as the house was packed. He makes the ideas sound even better than they read on SvN and Getting Real.
I think that the company succeeds for the same reason why their philosophy does: they are completely honest about what they do. When they say you're getting a project management system, that's exactly what you get. When they're asked about how they work, they answer it honestly. It's refreshing because they do exactly what they want to do and it works for them.
There are some things I don't like about them - namely, the splash page you get for their products - but there's no denying that they've made a set of utterly amazing products and that their blog is possibly the most interesting one I'm subscribed to right now.
Underdoing - if you forget about all those details that people tell you that you must have, and instead make a really useful product, people will find ways around those details, and buy it.
#6 is the one that resonates most strongly with me. in my last position there was one of these tiny-dog managers that'd pop in every 15 minutes or so and ask if something was done. at which point i'd spend five minutes explaining why it wasn't. he was the single biggest hindrance to my productivity. managers, don't be that guy. watch the trac task list if you must. don't harass the developers.
#3 - i take a little issue with this one, but not much. if it's straightforward to make something a little more flexible, the payoff is generally good. this depends on a few things: how sure are you that you'll be moving in that direction, how much work is it to add in the extra flex, how difficult will it be to connect up later?
it's worth thinking about, if only for a few minutes. the payoff could be huge, and even it's not, it's rarely wasted time.
#1 resonates most strongly with me right now. The feeling of accomplishment when you complete a project creates that sense of momentum and excitement going into the next one.
Like Jason, I've noticed that quality of work seemingly diminishes toward the end of a long project when people are motivated mostly to simply complete the project.
"13. Give up on hard problems - there is nothing wrong with being lazy. There is an abundance of easy problems that need to be solved. The really hard problems are probably better left to your competitors. Solve a bunch of simple things. Most people’s problems are simple and you can probably solve 10 in a month over 1 in 10 months."
Hard problems are a lot more fun to solve. How do you attract top talent if you are only solving easy things?
They're more fun, BUT they result in more work being done for less of a benefit.
Look at the sites that have succeeded the most and you'll see that they all solve basic problems, and that's resulted in most of them making tons of money. More specialized sites are more fascinating, but they attract fewer people and tend to be much less successful in absolute terms.
Exactly. Those are resultant problems from a fairly simple opening idea. YouTube: how can we put video online? Google: how can we make searches relevant?
And, while the details are usually tricky, I find that Google's solutions to problems tend to always be brilliantly simple. Like their translate features: they figure out a basic problem and they solve it simply and often unexpectedly. Calling it a Gordion knot is actually the perfect description, yeah.
> Not afraid that people will take their ideas and build a restaurant right beside of them.
Really? Then how come all the bitcheness around HuddleChat How disingenuous. (the lesson is correct, too bad they don't live by it)
I quote "We're flattered Google thinks Campfire is a great product, we're just disappointed that they stooped so low to basically copy it feature for feature, layout for layout," said 37Signals founder Jason Fried.
I know HN is suppose to be a cuddlefest where only the "right kind" of people are but I really think you guys need a devil's advocate post once in awhile to shine some reality on your rampant fanboyism.
I think there's a lot of independent thinking here. The important thing is to keep it civil - to say things that you'd feel comfortable saying directly to the people involved.
Personally, I am kind of skeptical of 37S in that they talk a good talk, but... I have a sneaking suspicion that their true scarcity power comes from things like Rails and their blog. Or maybe not; it's hard to tell without doing some very in depth research.
28 comments
[ 4.0 ms ] story [ 63.2 ms ] threadThe most important one for me is probably #3 "Get Rid of Abstractions". I learned this one the hard way. Now I just work on the problem at hand and worry about how to extend it later. It's a lot easier to generalize a specific case than to write something generalized in the first place. Could have saved me years.
I just finished an app with 51 separate modules, every one hard coded in infinite detail, and much of the code duplicated, 4000 LOC in all. Crazy, right? I used to think so, too. I could have written one very flexible parameter driven module in a few hundred LOC.
But guess what? Even though I bitched and moaned the whole time I wrote the monster, I was able to refactor and "genericize" it in one day. Start to finish time was much shorter than if I had written the flexible module first (that is, if I had ever finished).
This was a non-intuitive lesson for me. Write the specific case and extend later. I always used to try to write the most comprehensive "able to do anything" code until I realized that sometimes, the long way around is actually quicker.
Thanks again Jason, for #3.
When immediate refactoring is unlikely (either due to laziness, lack of focus, or feature deadlines), some kind of balance has to be reached on what should be more general and reusable and what should be hard-coded and specific. And then we're right back where we started.
But reading and thinking about your posts has been very insightful. On my next project, I will try your approach. I agree that in the long run, it is likely to be a more efficient use of time. I imagine, though, that someone coding in this style will either have to have a great memory or take good notes in order to know where similar code is located. Especially consider the case of generalizing the code from one project to another project.
Here's the good news: I couldn't wait to refactor. I was "in the zone" the whole day. And it felt great. I finally got to clean up the mess that I made, and best of all, I didn't have to struggle trying to figure out how to handle that strange outlying case: it was all already there!
I don't know if I'd try this in someone else's shop. You're right; they'd probably pull me off before I got to refactor, leaving a mess for someone else with nothing learned.
Most presenters are going to focus on all of the amazing features their products offer...however, 37 signals is still more successful than 95% of those other companies.
There are some things I don't like about them - namely, the splash page you get for their products - but there's no denying that they've made a set of utterly amazing products and that their blog is possibly the most interesting one I'm subscribed to right now.
#3 - i take a little issue with this one, but not much. if it's straightforward to make something a little more flexible, the payoff is generally good. this depends on a few things: how sure are you that you'll be moving in that direction, how much work is it to add in the extra flex, how difficult will it be to connect up later?
it's worth thinking about, if only for a few minutes. the payoff could be huge, and even it's not, it's rarely wasted time.
Like Jason, I've noticed that quality of work seemingly diminishes toward the end of a long project when people are motivated mostly to simply complete the project.
Hard problems are a lot more fun to solve. How do you attract top talent if you are only solving easy things?
Look at the sites that have succeeded the most and you'll see that they all solve basic problems, and that's resulted in most of them making tons of money. More specialized sites are more fascinating, but they attract fewer people and tend to be much less successful in absolute terms.
Is search not a hard problem?
YouTube solved the video codec Gordian knot, Google did the same with relevant search. Not easy problems, but they have huge benefits.
And, while the details are usually tricky, I find that Google's solutions to problems tend to always be brilliantly simple. Like their translate features: they figure out a basic problem and they solve it simply and often unexpectedly. Calling it a Gordion knot is actually the perfect description, yeah.
A hard problem is just a bunch of easy problems tangled up together.
Really? Then how come all the bitcheness around HuddleChat How disingenuous. (the lesson is correct, too bad they don't live by it)
I quote "We're flattered Google thinks Campfire is a great product, we're just disappointed that they stooped so low to basically copy it feature for feature, layout for layout," said 37Signals founder Jason Fried.
I know HN is suppose to be a cuddlefest where only the "right kind" of people are but I really think you guys need a devil's advocate post once in awhile to shine some reality on your rampant fanboyism.
Personally, I am kind of skeptical of 37S in that they talk a good talk, but... I have a sneaking suspicion that their true scarcity power comes from things like Rails and their blog. Or maybe not; it's hard to tell without doing some very in depth research.
Google lost so much credibility taking huddlechat down IMHO.