The hardest part about making good software that ships on time is knowing what and when to sacrifice. As programmers and designers, we often fall in love with our requirements and are unable to kill our darlings. We mistake what we said we’ll do with what must be done. It’s rarely so; you can always do less.
What stops most people from doing less is the fear of failure. The misconception that if you don’t get it all done, the rest is worth nothing at all. That without this feature or that tweak, nobody will want to use it at all. Bollocks. Most software has a tiny essence that justifies its existence, everything after that is wants and desires mistaken for needs and necessities.
The easiest way to force the insight of what can be lived without is by playing a game of constraints: You have to ship on Friday, you can’t add more people, you can’t work nights. Fixed resources, fixed time. All that’s left to give is scope. It’s amazing how creative the cuts and sharp the sacrifices become when you’re backed into a corner. It’s when you have to choose that you make the best choices.
For every 1 day estimates of a task, there’s a simpler version of that you can do in 3 hours, and an even simpler still you can do in 30 minutes. Back yourself into a corner and these versions will vividly appear before your eye. You can always do less.
David wrote this on Jan 14 2010 There are 55 comments.
Dan 14 Jan 10
Awesome. I also love the brevity of the post.
Carl 14 Jan 10
Don’t be such a suck up Dan.
DL Redden 14 Jan 10
I couldn’t agree more. In spite of knowing this and even thinking about it almost daily, it is so easy to get caught up with “it must do this” or “no one will want it if it doesn’t to that.” It just takes practice and constant reminder to make sure that you whittle that feature or task down into something that actually has to be done and not something that will just take up your precious time.
Miles K. Forrest 14 Jan 10
Ouch. You just took away my security blanket and stomped it into the ground. You’re right, though. What do I really want, a product that’s awesome, or an ego that thinks I’m awesome while the product suffers?
Martin Leblanc 14 Jan 10
That’s a great way to look at software development.
Tony 14 Jan 10
Occam’s razor through self-coercion.
I find it interesting that many developers I’ve worked with seem to equate quality to complexity. Or equate extensibility to complexity.
That’s the opposite of my favorite definition of genius: “The ability to make the complex simple.”
When did we start losing site of some of the basic tenants of the computer sciences and discrete mathematics? Shorter, more efficient solutions are desirable.
Ryan Platte 14 Jan 10
The use of the word “requirement” is inaccurate for the same reason.
DHH 14 Jan 10
Ryan, it’s the core of what this point is about. You think something is a requirement even when it’s not. Requirements are rarely stone tablets. More like putty dough.
Joe Holdcroft 14 Jan 10
Good point: things can always be done simpler/faster.
However this becomes an issue if it means sacrificing doing something “the right way” to do it “the quick way”.
..unless of course you have scope to change it to “the right way” further down the line. If that’s the case, this is the ideal way to work. Build quickly now, refine nicely later.
Brock Gunter-Smith 14 Jan 10
Absolutely. This is something we’ve learned the hard way over the years. We now involve our end users far more routinely in at least keeping them informed of WHY we have to eventually SHIP something and that they play a critical role with their own management teams in influencing the perceived priority of feature requests…but that there is ultimately a priority sequence and that to get updates out the door you have the draw the line somewhere.
andres 14 Jan 10
I still don’t see why you used four paragraphs in the post.
Eric J Gruber 14 Jan 10
”... without this feature or that tweak, nobody will want to use it at all.”
And there lies the birth of scope creep.
Talk about hitting home. Great post!
Janniche Haugen 14 Jan 10
Hear hear!
Rohan Dey 14 Jan 10
Can this apply even for services industry where clients wish list is some kind of court order
Chris Cuilla 14 Jan 10
“As programmers and designers, we often fall in love with our requirements and are unable to kill our darlings.”
This is so true.
With software-as-a-service it’s much easier to do less (to “ship”) and add more later (as required) since it’s so easy to deploy a new version. Eric Ries over at startuplessonslearned.com even talks about doing multiple deployments a day.
I think it takes real practice, discipline and focus to break away from the mindset that it has to be completely “done” and done right. That mindset almost becomes a (subconscious) crutch or excuse to not get something out there. It’s never going to be done. It’s never going to be completely right. Ship it and iterate.
Tony 14 Jan 10
@Ryan and DHH : I find that most client “requirements” are statements of what they think they want, not what they actually need. Enter scope creep. A good reason to keep solutions simple and to the point.
Andion 14 Jan 10
The first two comments made me ROFL :D
Rob 14 Jan 10
Do you have to do more first, then learn how to do less?
RS 14 Jan 10
Part of your formula can include a standard level of quality for everything in scope. If you have high coding and design standards (we do) then it’s all the more reason to trim scope so that the few things you do can be done properly.
phil mcthomas 14 Jan 10
Excellent use of “bollocks”. Well played.
Nithin Bekal 14 Jan 10
I wish I could do less with the project I’m working on. Unfortunately, I don’t have a choice since the client would never agree to reduce the requirements even though there isn’t enough time. However, this approach would work great if you’re working on your own projects and all the requirements are decided by you.
Bill Karwin 14 Jan 10
Henry David Thoreau said, “Simplify. Simplify.”
However, I prefer the simpler version, “Simplify.”
Doug Adams 14 Jan 10
(Great stuff here lately.)
So now my PostIt sez: Don’t be afraid to release early, release often.
DHH 14 Jan 10
I found this assumption to be malleable surprisingly often: “the client would never agree to reduce the requirements”. Many consultants have a lot of assumptions about what their clients would and wouldn’t accept. Some times those a faulty when countered with giving the client all the facts (“you can either have a system that tries to do it all that won’t work well or we can be reasonable and make a slightly smaller system that’ll work well”).
Tony 14 Jan 10
@DHH: Absolutely. I once had a client walk in with a bound book of requirements, with a whole section devoted to an idea they had for the software to anticipate the users actions.
It was way too complex. I asked them “have you ever tried to use microsoft word with all the automatic help turned on?”. They paused, and then tore out those pages and tossed them in the trash right front of me.
Of course, I’ve made the mistake of letting the client drive too much as well. The client is paying for the developer’s expertise on these issues, and I’ve found many to be reasonable when, as you say, they are presented with all the facts in a way they can understand.
Mark Ransom 14 Jan 10
I am getting ready to release a small side project that caused me to see this all too clearly. I had a ton of awesome features that I thought would really make the site useful and cool, I threw together a ton of placeholder models and views (15 or 20) that I was going to use to support all of these features. Then I started building and using the site and realized that all of that stuff was just getting in the way, and really wasn’t important to the core of what I was trying to do. I’ve been slashing and cutting ever since, and I wish I’d just kept things simple (in my head) from the start.
Thanks Mark
Anonymous Coward 14 Jan 10
- Antoine de Saint-Exupery
Kristin 14 Jan 10
We’ve been thinking about this a lot lately.
As an exercise, think about all the web apps that could be re-thought and simplified by reducing the main call to action to One Button.
Jumpchart : “Add Page“ – Every other function comes second to the creation of the basic building block- even the name of the site.
Flickr : “Upload a Photo” – Ownership, and everything else about a photo is just meta information. Getting it on the server is the beginning.
Delicious : “Add a Link” -Same as Flickr. Everything else is metadata, including ownership.
Youtube : “Upload a Video” -Same story: everything else is metadata about the item.
In its simplest form, everything boils down to a nugget of information- the details that give the item context are secondary.
Don Schenck 14 Jan 10
@Mark Ransom: Brilliant! I experienced the exact same thing over the past few weeks while working on my own project.
Quarrelsome 14 Jan 10
There is also an “attitude” benefit about doing less or rather, setting the expectations to less.
I’m just finishing up a demo that I had a very silly time-frame for (a “do your best” kinda thing). The first thing I set out to do was state how much time we had, how much I was going to try to do but also the amount I was likely to achieve (not much).
Turns out I can achieve a little bit more than we expected and everyone is mad happy!
Had we aimed for more but achieved the same people would be disappointed. But as we reduced expectations and went for the simplest things first there is a lot more confidence and good feeling about the project. :)
Adriaan 14 Jan 10
Couldn’t agree more, it is the 80/20 rule. With most ‘Fat’ applications you’ll use 20% of the functionality 80% of the time – think of office applications like Word, etc. So if you focus on the top 20% of functionality in your own application, you’ll make 80% of your users happy.
Eivind Uggedal 14 Jan 10
That was exactly what I did with http://wasitup.com – it’s the first project that I’ve completed. I’ve had several large ideas before, started to implement them, and finally giving up due to the complexity.
Tommy 14 Jan 10
This is one I needed. I’ve been infatuated w/ trying to write pristine sql statements to complete a project that I’m totally behind on.
Wasted a day trying to impress myself instead of getting the $#@! thing done :)
Much Obliged!!
Darcy Murphy 14 Jan 10
“What stops most people from doing less is the fear of failure.”
Correction: it’s the fear of being fired.
We don’t all have the luxury of working for someone who is actually understanding and sympathetic of the development process. Once it’s on paper, requirements are fucking gospel to some employers, whether or not the requirement is intelligent.
Otherwise, yeah, I agree.
swheat 14 Jan 10
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”
C. A. R. Hoare
Phil McClure 14 Jan 10
I’ve found 37signals point of view on this very helpful. I’m developing an application at the minute and have forced myself to apply this rule on several occasions. As David says, it can be hard to leave some features behind. However, the more lean your product is, the adaptable it is when you get user feedback.
Focus on doing less stuff very well rather than packing in lots of sub-standard features. Great advice.
Jean-Philippe Cyr 14 Jan 10
This is something you learn the hard way, but this is true, you can ALWAYS do less. Being an editor is your job. You need to say No, before saying Yes in order to focus on the important things. A good exercise is to take what you have defined and cut in half, then in half again. When you think you have just enough, your core features, cut it again in half! There you go, this is what you need to do.
Salt can always be added, but certainly not easily removed.
Rudy Godoy 14 Jan 10
In my experience most project management failures have to do more with trying to put technology on top/priority instead of focusing on what’s important for the business.
Non-tech people tends to become technology fanatics. Pushing technical people to show off their tech habilities. Technical people often oversees technology and forgets that software involves people and processes.
pwb 14 Jan 10
I’ve had a horrendous time trying to get my co-workers to agree with this. It’s infuriating.
simurg 14 Jan 10
Very good point. But it could be much better if you could add an example as well.
John 14 Jan 10
I think my website is proof you can do too little. ;-)
John 15 Jan 10
Hey guys, I was wondering where the buttons are to re-post this blog entry to Digg, Reddit, Twitter, Del.icio.us, Facebook, Linkedin, FriendFeed, StumbleUpon, Metafilter, Slashdot, Tumblr, email it to my mom, send it via SMS , print it, or request a telegram of it?
Sachin 15 Jan 10
everybody agrees with what you said but nobody will implement this (rather its hard)..practical scenarios are much different where customer is the king and wants every said feature implemented…
Andrew Webb 15 Jan 10
I would actually go further and say you can always do nothing. Sometimes doing a little can cause unexpected issues. So ask yourself can you go with what you have without doing anything.
pattesdemouches 15 Jan 10
And it’s the same in everywhere : the largest part of creativity is learning how to play within the constraint.
Nithin Bekal 15 Jan 10
@DHH. Well, the “client wouldn’t agree to change requirements” argument I put forward earlier has changed to “the client refused point blank when I suggested change”. After two hours of explaining my point about why their requirements were way too complex, I got nowhere today.
As if that wasn’t enough, they asked us to do even more than what was originally planned. Sometimes you have to accept that some clients just wouldn’t budge on requirements. :(
DHH 15 Jan 10
Nithin. Sorry to hear that. Hopefully you’ll be in a position to hire the right customer soon.
AHE 15 Jan 10
Although I agree with with the general “less is more”/”release fast and often” notion – I have one comment.
I my world, doing less often means more work for the engineers.
For example: we’re doing content recommendations widgets for blogs.Our newest widget contains a thumbnail widget. When the user installs the widget, I could have asked how many images he wants to display and the max size of the image.
In order to avoid this step, we are calculating the width of the blog and change it automatically. More work for the engineer but we have slashed an unnecessary setting.
IMHO , the key is to differentiate between core functionality and prioritizing everything else.
Gebze Emlak 15 Jan 10
I’ve had a horrendous time trying to get my co-workers to agree with this. It’s infuriating.
Demir Doğrama 16 Jan 10
I’m sure a lot of documentation was very good friends dalanacakdır fault
Andrew Conard 16 Jan 10
Demir – I appreciate the insights from this post. I am a pastor in a United Methodist Church and the temptation to do more is present much of the time. Adding constraints will be helpful, I am looking forward to incorporating some of these principles into my life in ministry.
Bobby Santiago 17 Jan 10
Came across an interesting Hacker News post, and after reading this post we decided to see if we could come up with a solution that addressed that problem (hook up with a cofounder).
To get the fear of failure out of the way, we strove to launch in the least amount of time – 24 hours, to be exact, offering one main feature (upload your elevator speech and spiel).
Two developers, 24 hours.
It really does force you to scrimp on the trappings associated with launching an app – the result is our rather spartan Find My Cofounder app.
TechSlam 18 Jan 10
@Nithin
I can understand what you mite be going through. Even I am facing the same situation, where client is absolutely nut.
Anonymous Coward 18 Jan 10
bjkgjhgh
Auction 20 Jan 10
Do less and have less. The fas is that who is used to have less will never turn for more!
This discussion is closed.