Jason Fried: How to Kill a Bad Idea | Hacker News Reader

Jason Fried: How to Kill a Bad Idea

inc.com

66 pointsduck33 comments

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.

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.

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.

Of couse he isn't.

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

Apparently every store in the world is in the construction business. Who knew?

If the toilet or sinks in my restaurant don't work, the customer will hold me responsible. It a light is burned out or a chair is broken they will hold me responsible. I am still not in the plumbing, electricity, or furniture business.

If you have a website, you are at least in the marketing business; rather, your website is a marketing tool, for good or bad. If your website has any features other than basic marketing (prices, times, list of products or services, location, etc), such as purchases, mailing lists, and other such things, then the product you are giving your customers is software. That is in addition to whatever your core business is about.

Someone mentioned a dentist. If his website includes anything interactive, then part of his product to you is software. It might be a stretch to say he is in the "software business", but he (or an employee or contractor) is definitely delivering a software product.

Peter Drucker in "Management: Tasks, Responsibilities, and Pratices" offers the following definition of business and its' key functions:

"Because the purpose of business is to create and keep a customer, the business enterprise has two--and only two--basic functions: marketing and innovation. Marketing and innovation produce results; all the rest are costs. Marketing is the distinguishing, unique function of the business."

If you accept his logic, which I do, then to be in business is to be in the marketing and innovation business.

Using a service does not mean you are "in" that business, any more then being in a shop does not mean you own that shop.

Marketers are in the marketing business. Programmers are in the programming business. Having a website that you use as a marketing tool doesn't make you a marketer, it means you use a product for marketing.

That is just shifting the blame. If you use a product for marketing, you are marketing. Yes, in general, "using a service" does not mean you are in that business. But if you ask your users to take part in this service or tool you are using, you are now providing that service.

Chairs in your office for your customers? You have taken on the responsibilities of being a host.

We can debate indirect services, such as electricity to run a website, and I would say that that line of discussion is pointless. I rely on my electric company, but my customers rely on my website, and the customers blame me, not the provider I chose to host this feature, not the electric company that provides power to the web services provider.

Remember that the customer does not care about your problems. They care about theirs, and they see you as their cause.

For starters, you're comparison is completely off with what Jason said. A business might need electricity, plumbing, or furniture to operate, but how are these the same as a website? Are you saying that a website is equal to a chair at your doctors clinic? Saying a website is the same as utilities and structural needs of a physical space is a bit irresponsible. Second, what does whatever 'software' tools you use or if you're a developer/engineer have to do with a company being in the software business? They're not mutually inclusive, nor exclusive for that matter.

Most businesses with a website are in the software business the same way most businesses with personnel that deals with clients are in the customer relations business and the same way most businesses with a product are in the marketing business. Using whatever tools you use to create a piece of software which you later put at your clients disposal automagically enters your company into the world of the software business. Granted most companies have simple websites that you don't really need to give much thought to after launch as a company, but that doesn't exempt you from the fact that you're offering a service based on software the moment you put that website up.

Calling an HTML page "software" is stretching the definition of software to its extreme though; it's not so much akin to suggesting that businesses with client-facing personnel are in the customer relations business as suggesting that their mere ability to field a question puts them in the business of education.

I'll buy the argument that operating an e-commerce facility so that customers' requirements being met and payments being received depends on some non-trivial lines of code have entered the software business though.

I'd say it's the other way around. If you're working on an industry that would benefit from "teaching" your customers a thing or two, and you go ahead and answer each and every question, you'd be in the education business. Wether you use something as simple as an HTML page or something as complex a Rails stack is of no consequence to the fact that the end user is still interacting with a computer, programs, and data.

Hell I've seen some programs back in the day which where made just to display a box of with text. That's software also. Boring, small and useless software, but software nonetheless. The Irc warez scene used to be full with these type of ridiculous programs, though at least some had awesome 8 bit music.

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.

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.

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

My observation is that enterprise software usually sucks, though not for a lack of features. Usually it has to do with extraordinarily poor useability and massive amounts of clutter, due to featuritis (needing to meet the demands of all those Massive Companies).

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.

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

Unfortunately the unix philosophy does not extend to enterprise software because the rank and file employees can not be expected to effectively synthesize their own optimal workflows from a collection of small, flexible tools.

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.

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

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.

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

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.

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.

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?

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.

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

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.

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

Reply on news.ycombinator.com