6 ms·

Jason Fried: How to Kill a Bad Idea

66 points by duck 16y ago

deleted 16y ago
[deleted]
- duck 16y ago
  Good point, done.
mcknz 16y ago
Reminds me of http://c2.com/cgi/wiki?SecondSystemEffect http://c2.com/cgi/wiki?SecondSystemEffect
- AndrewO 16y ago
  Agreed. I'll hand it to Jason Fried though: it's good to see someone try to relate the concepts in Mythical Man Month to non-programmers. I recommended MMM to a friend when problems at his workplace sounded like things that came up in software design or project management. But when I reviewed the book, I found that a lot of the big-picture concepts required if not understanding, then at least familiarity with programming and/or older computer systems. It's still a good book, but I ended up feeling like he wouldn't get what I got out of it.
  - quanticle 16y ago
    I disagree. I found a lot of MMM to be applicable to my experience, despite the fact that I've never done any mainframe or systems programming professionally. The one portion of the book that could be updated is Brooks' vision of the ideal project team. Many of the positions he's envisioned (toolsmith, language lawyer, etc.) are outdated now that individual programmers have so many more resources at their disposal. If we're talking about project management issues, though, I'd recommend Yourdon's "Death March" over "The Mythical Man-Month". That book has a lot more to say on how to deal with management that refuses to pick two out of "good, fast, cheap" and insists that all three are achievable.
pchristensen 16y ago
Is duck calling Jason Fried a bad idea and calling for his assassination? I think that's taking opinionated a little too far :)
- duck 16y ago
  No, but I did managed to title it "incorrectly" twice, so I'm glad a mod came in and changed it to what it is now. :) I had a laugh reading your comment though and thought how one day there will be an app for that.
TheSOB88 16y ago
I don't feel like he explains this well enough. The water bottle metaphor wasn't really extended to the point where it actually illustrated his points - "Imagine what would happen if more stuff was added to it. Pretty soon it wouldn't be functional. The physics would push back." That's like saying, "What would happen? It wouldn't work. Something bad would happen." It's too vague - you need to show in what ways a water bottle could get bloated, and then how that applies to software. For example, if water bottles were filled with ads, you wouldn't be able to tell if the water was clean inside. Likewise, if your site is filled with ads, people have a hard time finding the content they want to "drink".
skmurphy 16y ago
I disagree with his opening thesis: "Are you in the software business? I bet most of you would answer no. So let me put it another way: Do you have a website? If the answer is yes, you're in the software business. A website is software. It has utility, and that utility is accessed via an interface on a computer or mobile device. That's software." Most business with a website are no more in the software business than they are in the electricity business or the plumbing business or the furniture business, even though without these things they would not be able to operate. Using software tools does not mean you are a software engineer/developer any more than flipping on a light switch or changing a bulb makes you an electrician.
- TheSOB88 16y ago
  The difference is the customer is not affected by electricity/plumbing/furniture that the company is responsible. Customers are affected by the company's website, which is a type of software.
  - SMrF 16y ago
    My dentist has some pretty crummy chairs in the waiting room. This certainly affects my visits to the dentist. My dentist is not in the furniture business. My dentist also has a crappy website. He is not in the software business.
    - TheSOB88 16y ago
      Of couse he isn't.
    - sp4rki 16y ago
      Does your dentist have receptionist who takes care of appointments and generally treats you nicely while you wait? He's in the customer service business. Does your dentist have his diplomas, fellowships, and awards on his shelf? He's in the marketing business. Does your dentist work on your teeth and makes you suffer and withstand amazing pains? He's in the dentistry business. Does your dentist have a website? He's in the software business, regardless of if the website is a simple website so you can find his phone number or if the website provides a way to check your appointment date (or some other service).
rwmj 16y ago
What a load of drivel. Stopped reading at "Contrast that with software. What are the criteria for evaluating software?" To the author: there are many criteria. Different from physical things, for sure, but solid scientific criteria nevertheless. Such as usability, bug densities, features, specifications.
eftpotrm 16y ago
There seems to be a growing assumption in software that small, simple, focused is always best. I disagree. I have no problem with software being carefully managed to ensure that it remains coherent and that new features added are genuinely useful and not at the expense of existing features. But this can only go so far! Would I prefer to develop software in Visual Studio 5 rather than 20xx to avoid bloat? Would a professional graphic designer prefer to use a 15 year old version of Photoshop because it's not suffered feature bloat? It doesn't make sense; the extra features have been added because people asked for them, because people find them useful. Something as simple as auto-checkout source control in VS2005 made my day when I first found it, saved me so much needless hassle, yet it's a feature outside the app's core purpose and so unnecessary? Rubbish. What we want is well designed, coherent applications with equality of 'fit and finish' throughout. This is easier to achieve with a simpler application, so simple is being trumpeted as a virtue in itself. It isn't, though - we should be looking to develop applications as complex and powerful as both we can manage to develop well and our users can manage to use easily. This is complex, though, so we're dumbing down to 'simpler is better' and forgetting _why_ we're asking for simplicity - to retain a focus on quality.
- quanticle 16y ago
  >There seems to be a growing assumption in software that small, simple, focused is always best. Growing assumption? No, its an assumption that's always been there. I mean, isn't this the core of the Unix philosophy - small sharp tools? I'd rather have three separate programs that each are really good at what they do than a single program that's mediocre at what it does. >Would I prefer to develop software in Visual Studio 5 rather than 20xx to avoid bloat? I'd rather develop software in vim than either, and that goes back to what I was saying above. Vim is a tool that does one thing - edit text. I don't need my text editor to automatically suggest my next function call. I don't want my text editor to automatically compile code in the background. I don't want my text editor to take up hundreds of megabytes of memory to load metadata that I'll never use. I don't want my text editor to handle source control. I want my text editor to edit text. >What we want is well designed, coherent applications with equality of 'fit and finish' throughout. This is easier to achieve with a simpler application, so simple is being trumpeted as a virtue in itself. It isn't, though - we should be looking to develop applications as complex and powerful as both we can manage to develop well and our users can manage to use easily. Specialization doesn't imply simplicity or lack of sophistication. Look at vim. Its unbelievably complex. I've spent years working with it, and I'm still learning new things about it. Its just that all the complexity and sophistication is focused towards one goal - making text editing faster. I can code faster in vim than I could in Visual Studio. The way I see it, a lot of VS's aids are like training wheels - they're great when you're starting out, but if you want to go fast, you'll have to leave them behind.
InfinityX0 16y ago
The title makes no sense with the article, in my opinion. It's more a narrative of how software is better with less, and how they came to that conclusion. Of course, Inc is in the pageview business. Or should I say software business?
cromulent 16y ago
I have a lot of respect for Jason, his company, and his contributions. However, the idea that all software should be pruned to the essentials does not work in all cases. Simple software does not always scale at the enterprise level. What I mean by that is that resisting a commonly requested feature for Basecamp means that maybe 5000 of your x-million customers have a problem and need a workaround 5 times a day - 25000 workarounds, but only 5 times per company per day. If you resist a feature for Massive Company 1, then they have to execute a workaround 700,000 times per day. That doesn't scale. Then, if you resist feature 2 for Massive Company 2, they have to execute a workaround 600,000 times a day. So, software aimed at the enterprise gets bloated and terrible to use. However, this leaves a gap at the bottom for those who can choose a good minimal feature set to exploit. We should not condemn them.
- dasil003 16y ago
  The trickiest part of enterprise software is requirement gathering. You basically have a situation where no single individual has a detailed enough picture of operations in order to distill requirements down to the essentials. The 37signals philosophy could certainly be applied to some extent if the key people had the right training and the appreciation for the complexity costs of software, but the particular challenges of doing this in the enterprise, and fraught with obstacles which 37signals wisely chooses to avoid by their very business model. And what percentage of stakeholders in a large enterprise have anything approaching the usability or complexity sense of the average 37signals employee? Certainly everyone creating software should be aware of what 37signals has to say, but they don't actually offer any insight on the truly hard problems of enterprise software. They choose not to solve those problems, but it doesn't mean they aren't real.
- sp4rki 16y ago
  It's not that all software should be straight forward, simple, and as you say 'pruned to the essentials'. It's not a case of simple, it's a case of as simple as it can be. If your product or app or whatever needs to be more complicated because of some business need, then it should be more complicated, but there's a point where more features can be too much and it will decrease the quality of the software. Again, it's not 'keep it simple stupid', it's more like 'keep it as simple as you can while satisfying your requirements'.
j_baker 16y ago
"Let's start by looking at a physical object -- say, a standard 16-ounce water bottle. Think Evian, Poland Spring, Fiji, or something like that." That's all I had to read to know that Jason Fried was giving that lecture. Seriously though. Is there anyone here who pays any attention to Jason Fried and hasn't heard the water bottle analogy? It's been in every public presentation that I've ever heard him give.
pbiggar 16y ago
I find it ironic that he uses Highrise as his example. I used Highrise for a while, until the lack of some features I needed (mostly the ability to tweak the basic preferences) caused me to quit using it and cancel my subscription. My feeling is that developing good software requires balancing saying 'yes' with saying 'no'. 37signals seem to advocate an extreme 'no' position with their software, which I think is probably as bad as saying 'yes' to everything.

66 points by duck 16y ago

deleted 16y ago

[deleted]

duck 16y ago
Good point, done.

mcknz 16y ago

Reminds me of http://c2.com/cgi/wiki?SecondSystemEffect http://c2.com/cgi/wiki?SecondSystemEffect

AndrewO 16y ago
Agreed. I'll hand it to Jason Fried though: it's good to see someone try to relate the concepts in Mythical Man Month to non-programmers. I recommended MMM to a friend when problems at his workplace sounded like things that came up in software design or project management. But when I reviewed the book, I found that a lot of the big-picture concepts required if not understanding, then at least familiarity with programming and/or older computer systems. It's still a good book, but I ended up feeling like he wouldn't get what I got out of it.
- quanticle 16y ago
  I disagree. I found a lot of MMM to be applicable to my experience, despite the fact that I've never done any mainframe or systems programming professionally. The one portion of the book that could be updated is Brooks' vision of the ideal project team. Many of the positions he's envisioned (toolsmith, language lawyer, etc.) are outdated now that individual programmers have so many more resources at their disposal. If we're talking about project management issues, though, I'd recommend Yourdon's "Death March" over "The Mythical Man-Month". That book has a lot more to say on how to deal with management that refuses to pick two out of "good, fast, cheap" and insists that all three are achievable.

pchristensen 16y ago

Is duck calling Jason Fried a bad idea and calling for his assassination? I think that's taking opinionated a little too far :)

duck 16y ago
No, but I did managed to title it "incorrectly" twice, so I'm glad a mod came in and changed it to what it is now. :) I had a laugh reading your comment though and thought how one day there will be an app for that.

TheSOB88 16y ago

I don't feel like he explains this well enough. The water bottle metaphor wasn't really extended to the point where it actually illustrated his points - "Imagine what would happen if more stuff was added to it. Pretty soon it wouldn't be functional. The physics would push back." That's like saying, "What would happen? It wouldn't work. Something bad would happen." It's too vague - you need to show in what ways a water bottle could get bloated, and then how that applies to software. For example, if water bottles were filled with ads, you wouldn't be able to tell if the water was clean inside. Likewise, if your site is filled with ads, people have a hard time finding the content they want to "drink".

skmurphy 16y ago

I disagree with his opening thesis: "Are you in the software business? I bet most of you would answer no. So let me put it another way: Do you have a website? If the answer is yes, you're in the software business. A website is software. It has utility, and that utility is accessed via an interface on a computer or mobile device. That's software." Most business with a website are no more in the software business than they are in the electricity business or the plumbing business or the furniture business, even though without these things they would not be able to operate. Using software tools does not mean you are a software engineer/developer any more than flipping on a light switch or changing a bulb makes you an electrician.

TheSOB88 16y ago
The difference is the customer is not affected by electricity/plumbing/furniture that the company is responsible. Customers are affected by the company's website, which is a type of software.
- SMrF 16y ago
  My dentist has some pretty crummy chairs in the waiting room. This certainly affects my visits to the dentist. My dentist is not in the furniture business. My dentist also has a crappy website. He is not in the software business.
  - TheSOB88 16y ago
    Of couse he isn't.
  - sp4rki 16y ago
    Does your dentist have receptionist who takes care of appointments and generally treats you nicely while you wait? He's in the customer service business. Does your dentist have his diplomas, fellowships, and awards on his shelf? He's in the marketing business. Does your dentist work on your teeth and makes you suffer and withstand amazing pains? He's in the dentistry business. Does your dentist have a website? He's in the software business, regardless of if the website is a simple website so you can find his phone number or if the website provides a way to check your appointment date (or some other service).

rwmj 16y ago

What a load of drivel. Stopped reading at "Contrast that with software. What are the criteria for evaluating software?" To the author: there are many criteria. Different from physical things, for sure, but solid scientific criteria nevertheless. Such as usability, bug densities, features, specifications.

eftpotrm 16y ago

There seems to be a growing assumption in software that small, simple, focused is always best. I disagree. I have no problem with software being carefully managed to ensure that it remains coherent and that new features added are genuinely useful and not at the expense of existing features. But this can only go so far! Would I prefer to develop software in Visual Studio 5 rather than 20xx to avoid bloat? Would a professional graphic designer prefer to use a 15 year old version of Photoshop because it's not suffered feature bloat? It doesn't make sense; the extra features have been added because people asked for them, because people find them useful. Something as simple as auto-checkout source control in VS2005 made my day when I first found it, saved me so much needless hassle, yet it's a feature outside the app's core purpose and so unnecessary? Rubbish. What we want is well designed, coherent applications with equality of 'fit and finish' throughout. This is easier to achieve with a simpler application, so simple is being trumpeted as a virtue in itself. It isn't, though - we should be looking to develop applications as complex and powerful as both we can manage to develop well and our users can manage to use easily. This is complex, though, so we're dumbing down to 'simpler is better' and forgetting _why_ we're asking for simplicity - to retain a focus on quality.

quanticle 16y ago
>There seems to be a growing assumption in software that small, simple, focused is always best. Growing assumption? No, its an assumption that's always been there. I mean, isn't this the core of the Unix philosophy - small sharp tools? I'd rather have three separate programs that each are really good at what they do than a single program that's mediocre at what it does. >Would I prefer to develop software in Visual Studio 5 rather than 20xx to avoid bloat? I'd rather develop software in vim than either, and that goes back to what I was saying above. Vim is a tool that does one thing - edit text. I don't need my text editor to automatically suggest my next function call. I don't want my text editor to automatically compile code in the background. I don't want my text editor to take up hundreds of megabytes of memory to load metadata that I'll never use. I don't want my text editor to handle source control. I want my text editor to edit text. >What we want is well designed, coherent applications with equality of 'fit and finish' throughout. This is easier to achieve with a simpler application, so simple is being trumpeted as a virtue in itself. It isn't, though - we should be looking to develop applications as complex and powerful as both we can manage to develop well and our users can manage to use easily. Specialization doesn't imply simplicity or lack of sophistication. Look at vim. Its unbelievably complex. I've spent years working with it, and I'm still learning new things about it. Its just that all the complexity and sophistication is focused towards one goal - making text editing faster. I can code faster in vim than I could in Visual Studio. The way I see it, a lot of VS's aids are like training wheels - they're great when you're starting out, but if you want to go fast, you'll have to leave them behind.

InfinityX0 16y ago

The title makes no sense with the article, in my opinion. It's more a narrative of how software is better with less, and how they came to that conclusion. Of course, Inc is in the pageview business. Or should I say software business?

cromulent 16y ago

I have a lot of respect for Jason, his company, and his contributions. However, the idea that all software should be pruned to the essentials does not work in all cases. Simple software does not always scale at the enterprise level. What I mean by that is that resisting a commonly requested feature for Basecamp means that maybe 5000 of your x-million customers have a problem and need a workaround 5 times a day - 25000 workarounds, but only 5 times per company per day. If you resist a feature for Massive Company 1, then they have to execute a workaround 700,000 times per day. That doesn't scale. Then, if you resist feature 2 for Massive Company 2, they have to execute a workaround 600,000 times a day. So, software aimed at the enterprise gets bloated and terrible to use. However, this leaves a gap at the bottom for those who can choose a good minimal feature set to exploit. We should not condemn them.

dasil003 16y ago
The trickiest part of enterprise software is requirement gathering. You basically have a situation where no single individual has a detailed enough picture of operations in order to distill requirements down to the essentials. The 37signals philosophy could certainly be applied to some extent if the key people had the right training and the appreciation for the complexity costs of software, but the particular challenges of doing this in the enterprise, and fraught with obstacles which 37signals wisely chooses to avoid by their very business model. And what percentage of stakeholders in a large enterprise have anything approaching the usability or complexity sense of the average 37signals employee? Certainly everyone creating software should be aware of what 37signals has to say, but they don't actually offer any insight on the truly hard problems of enterprise software. They choose not to solve those problems, but it doesn't mean they aren't real.
sp4rki 16y ago
It's not that all software should be straight forward, simple, and as you say 'pruned to the essentials'. It's not a case of simple, it's a case of as simple as it can be. If your product or app or whatever needs to be more complicated because of some business need, then it should be more complicated, but there's a point where more features can be too much and it will decrease the quality of the software. Again, it's not 'keep it simple stupid', it's more like 'keep it as simple as you can while satisfying your requirements'.

j_baker 16y ago

"Let's start by looking at a physical object -- say, a standard 16-ounce water bottle. Think Evian, Poland Spring, Fiji, or something like that." That's all I had to read to know that Jason Fried was giving that lecture. Seriously though. Is there anyone here who pays any attention to Jason Fried and hasn't heard the water bottle analogy? It's been in every public presentation that I've ever heard him give.

pbiggar 16y ago

I find it ironic that he uses Highrise as his example. I used Highrise for a while, until the lack of some features I needed (mostly the ability to tweak the basic preferences) caused me to quit using it and cancel my subscription. My feeling is that developing good software requires balancing saying 'yes' with saying 'no'. 37signals seem to advocate an extreme 'no' position with their software, which I think is probably as bad as saying 'yes' to everything.