Agile software development is about working in small batch sizes, and taking engineering seriously. If anyone tells you otherwise they are probably selling you something.

I wish I knew where this come from, so far search hasn't turned anything up. Any ideas?

Done is better than perfect, or "the best" is the enemy of "the good". Perfectionism is a form of procrastination. It assumes that time is an infinite resource, that other tasks can wait while you add "just one more touch" and that "perfect" is attainable.

One of the guiding principles behind Shopify’s apps team. Great advice for any dev team.

Speaking of simplicity.

Isaac Hall, co-founder of Dropbox competitor Syncplicity, answered the Quora question "Why is Dropbox more popular than other tools with similar functionality?"

It's a wonderfully in-depth answer, encompassing PR companies, the press, and how to structure a beta, but despite all of those influences it came down to this:

In the end, it really came down to one incredibly genius idea: Dropbox limited its feature set on purpose. It had one folder and that folder always synced without any issues -- it was magic. Syncplicity could sync every folder on your computer until you hit our quota. (Unfortunately, that feature was used to synchronize C:\Windows\ for dozens of users -- doh!) Our company had too many features and this created confusion amongst our customer base. This in turn led to enough customer support issues that we couldn't innovate on the product, we were too busy fixing things. […]

If you're starting a new company, the best thing you can do is keep your feature set small and focused. Do one thing as best as you possibly can. Your users will beg and beg for more functionality. They will tell you their problems and ask you to fix it. My philosophy is that they're right if their feature request is right only if it works for 80% of your customers. Until you have a lot of resources, stay focused on your core competency.

Rands In Repose interviews the creator of Instapaper, Marco Arment.

When asked about the early decisions he made in order to manage as a one-man shop:

The biggest design decision I’ve made is more of a continuous philosophy: do as few extremely time-consuming features as possible. As a result, Instapaper is a collection of a bunch of very easy things and only a handful of semi-hard things.

Keep it simple, iterate.

The time has arrived that three communities–the business, design, and technology communities–have independently discovered the same thing. That the best way to build new technology products, services, and the businesses that deliver them is to work in small, cross-functional, highly collaborative teams. To use lightweight, informal methods. To use rapid cycles of designing, making, and validating in order to test and learn and improve. To focus on the customer.

Josh Seiden in Agile UX? Lean UX? Customer Development? A multiple discovery moment.

There is some great advice in this piece from Matt Mullenweg about shipping version 1.0.

Usage is like oxygen for ideas. You can never fully anticipate how an audience is going to react to something you’ve created until it’s out there. That means every moment you’re working on something without it being in the public it’s actually dying, deprived of the oxygen of the real world.

You can come up with all the user stories, scenarios and use cases you want, but the moment your product hits the real world, all that goes out of the window.

And never wait until something is completely polished and feature complete.

…if you’re not embarrassed when you ship your first version you waited too long.

Amen to that. Iterate, iterate, iterate.

The coolest thing about a waterfall process is that it allows me personally to succeed, to demonstrate skill and competence, while the end result of the process is a dismal failure. Cleverly built into a waterfall process are a variety of scapegoating mechanisms that allow us to blame other people, or outside influences for failure.

- Jeff Patton.

Most projects start off with a waterfall approach, which is to say that there [sic] started with a plan to turn it into a wireframe, which turns into milestones, which turns into a final product, which then gets fixed because it's broken.

- Jonathan Lambert