

Jason Fried: How to Kill a Bad Idea - duck
http://www.inc.com/magazine/20101201/how-to-kill-a-bad-idea.html

======
skmurphy
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
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
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.

~~~
sp4rki
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).

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

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

~~~
eftpotrm
Maybe, within the Unix world, but there's a large software world beyond Unix,
and that world seems to be grabbing onto 'simple is best' rather hard for my
liking at present.

I'm pleased for you that you like the Vi family of editors - I'm relatively
familiar with them, but can't stand them. I'll never understand its continuing
popularity; I know other editors I'd judge as powerful in practical usage but
which are no harder for an ordinary user than Notepad. When I want a straight
text editor I use one, but there's more to developing code than just editing
text and that's why I like Visual Studio (not that it's the best IDE
necessarily, just the one I use for work) - it gives me a single, coherent,
consistent interface for developing the program in a way that I find vastly
more productive than when I was having to use plain text editors and jump
between tools to accomplish routine tasks. I don't for one minute miss having
to compile code to find I'd made a one-character typo that didn't compile, or
had made a type referencing error. Nor do I miss having a separate window to
jump to whenever I realised I needed to check out an individual file while on
a bug hunt. I don't dispute IDEs have their training wheels and some of them
get in the way, but plain editors have their obstructive limitations too. I
use IDEs willingly having come from the other approach, not in ignorance of
it.

To get back to my original point - we shouldn't be looking to make our tools
simple but to make them ruthlessly focused on improving the user experience
for our users. Talking paperclips are a bad idea but I don't believe that
source control integration in an environment that will largely be used with
source control is anything but a boon to developers or that other similar
examples in other software are bad. We should be looking to make software as
powerful as we can keep under control, not as simple / narrowly focused (I'm
aware they're not the same but I don't believe the article would cite Vim as
an example of simplicity) as we can manage. Workflow is good, context switch
is bad.

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

~~~
duck
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_.

------
mcknz
Reminds me of <http://c2.com/cgi/wiki?SecondSystemEffect>

~~~
AndrewO
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
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.

------
InfinityX0
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?

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

------
j_baker
"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.

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

------
TheSOB88
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".

