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.
Dan
on 14 Jan 10Awesome. I also love the brevity of the post.
Carl
on 14 Jan 10Don’t be such a suck up Dan.
DL Redden
on 14 Jan 10I 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
on 14 Jan 10Ouch. 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
on 14 Jan 10That’s a great way to look at software development.
Tony
on 14 Jan 10Occam’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
on 14 Jan 10The use of the word “requirement” is inaccurate for the same reason.
DHH
on 14 Jan 10Ryan, 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
on 14 Jan 10Good 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
on 14 Jan 10Absolutely. 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
on 14 Jan 10I still don’t see why you used four paragraphs in the post.
Eric J Gruber
on 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
on 14 Jan 10Hear hear!
Rohan Dey
on 14 Jan 10Can this apply even for services industry where clients wish list is some kind of court order
Chris Cuilla
on 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
on 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
on 14 Jan 10The first two comments made me ROFL :D
Rob
on 14 Jan 10Do you have to do more first, then learn how to do less?
RS
on 14 Jan 10Part 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
on 14 Jan 10Excellent use of “bollocks”. Well played.
Nithin Bekal
on 14 Jan 10I 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
on 14 Jan 10Henry David Thoreau said, “Simplify. Simplify.”
However, I prefer the simpler version, “Simplify.”
Doug Adams
on 14 Jan 10(Great stuff here lately.)
So now my PostIt sez: Don’t be afraid to release early, release often.
DHH
on 14 Jan 10I 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
on 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
on 14 Jan 10I 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
on 14 Jan 10- Antoine de Saint-Exupery
Kristin
on 14 Jan 10We’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
on 14 Jan 10@Mark Ransom: Brilliant! I experienced the exact same thing over the past few weeks while working on my own project.
Quarrelsome
on 14 Jan 10There 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
on 14 Jan 10Couldn’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
on 14 Jan 10That 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
on 14 Jan 10This 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
on 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
on 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
on 14 Jan 10I’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
on 14 Jan 10This 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
on 14 Jan 10In 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
on 14 Jan 10I’ve had a horrendous time trying to get my co-workers to agree with this. It’s infuriating.
simurg
on 14 Jan 10Very good point. But it could be much better if you could add an example as well.
John
on 14 Jan 10I think my website is proof you can do too little. ;-)
John
on 15 Jan 10Hey 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
on 15 Jan 10everybody 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
on 15 Jan 10I 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
on 15 Jan 10And it’s the same in everywhere : the largest part of creativity is learning how to play within the constraint.
Nithin Bekal
on 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
on 15 Jan 10Nithin. Sorry to hear that. Hopefully you’ll be in a position to hire the right customer soon.
AHE
on 15 Jan 10Although 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
on 15 Jan 10I’ve had a horrendous time trying to get my co-workers to agree with this. It’s infuriating.
Demir Doğrama
on 16 Jan 10I’m sure a lot of documentation was very good friends dalanacakdır fault
Andrew Conard
on 16 Jan 10Demir – 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
on 17 Jan 10Came 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
on 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
on 18 Jan 10bjkgjhgh
Auction
on 20 Jan 10Do less and have less. The fas is that who is used to have less will never turn for more!
This discussion is closed.