When you are involved in development work it seems that you need to ensure that every possible contingency is catered for, all relevant standards are used, the software is repurposable, the service complies fully with accessibility guidelines, can be used by every browser and on every platform, etc., etc.

No wonder software seems to take so long to be developed! But is this the only approach which can be taken to software development?

My colleague Paul Walk recently introduced me to the concept of “embracing constraints“. This approach was used by 37Signals in the development of the Basecamp Web-based project management service, and they have described why they chose this approach:

Let limitations guide you to creative solutions

There’s never enough to go around. Not enough time. Not enough money. Not enough people.

That’s a good thing.

Instead of freaking out about these constraints, embrace them. Let them guide you. Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage.

When 37signals was building Basecamp, we had plenty of limitations. We had:

  • A design firm to run
  • Existing client work
  • A 7-hour time difference (David was doing the programming in Denmark, the rest of us were in the States)
  • A small team
  • No outside funding

We felt the “not enough” blues. So we kept our plate small. That way we could only put so much on it. We took big tasks and broke them up into small bits that we tackled one at a time. We moved step by step and prioritized as we went along.

That forced us to come up with creative solutions. We lowered our cost of change by always building less software. We gave people just enough features to solve their own problems their own way — and then we got out of the way. The time difference and distance between us made us more efficient in our communication. Instead of meeting in person, we communicated almost exclusively via im and email which forced us to get to the point quickly.

Constraints are often advantages in disguise. Forget about venture capital, long release cycles, and quick hires. Instead, work with what you have.

This seems to be a development philosophy which is being adopted within the Web 2.0 development world. For example Jon Udell has commented on Dabble DB which is “a web-based workgroup database that, in the style of 37Signals, focuses on simplicity and embraces constraints. Dabble doesn’t aim to do full-blown database application development, or sophisticated query, or heavy transactions. Its mission, instead, is to enable teams to easily manage and flexibly evolve modest (say, 30- to 50-megabyte) quantities of structured data.

This makes me wonder whether current approaches to development within the public sector are too heavyweight and we shouldn’t start to ’embrace constraints.’