Embracing Constraints
Posted by Brian Kelly on 20 Jun 2007
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.’
UK Web Focus (Brian Kelly) 
Phil Wilson said
Quite a lot of agile stuff goes past on http://wiki.bath.ac.uk/display/bucswebdev/Bookmarks and we work in a pretty agile way in our team, as do Warwick. It’s not necessarily synonymous with “embrace constraints”, but we do have a copy of “Getting Real” on our bookshelf in the office :)
FWIW I think this is a general move in software development across the board, and not just applicable to the public sector.
In my totally personal opinion (and not reflecting the opinion of my employer at all), I rather suspect that the heavyweight approaches are much more entrenched in the business-focussed and research-focussed sections of development. These are the two areas where “solutions” are a) sold by enterprise vendors and b) created with blue-sky limitations (cough). I would expect user-centred development to be able to respond much more quickly to this kind of shift in development.
Peter Miller said
Dabble’s very user-centred and pretty flexible though it has some odd limitations. Support’s above average and they have a policy of continuous improvement rather than rolling out major version changes. Things break occasionally but they’re generally fixed pretty fast.
Juliette White said
It’s be interesting to get some data on software development approaches and processes across universities – my guess is that there is actually quite a spectrum.
I think one of the differences is that in the public sector you don’t have making money as a measure of success. You’re judged by how professional your application is and meeting standards, wide browser-compatibility etc. are the type of yardsticks that get used. It’s very hard to explain to people that in some cases, it’s just not worth the cost of doing certain things. In business, it generally makes economic sense to ship stuff that has bugs (within limits of course!) whereas in the public sector, any bugs or usability issues at all are held up as signs of lack of professionalism and so I suspect developers learn to be cautious.
Mark Sammons said
I agree with the concept of embracing constraints.
I find it interesting that this is being tied to the “Web 2.0 development world” because, to me, it almost seems opposite to what people have talked about with Web 2.0 to date. Since O’Reilly started this crazy journey, people have talked about Web 2.0 development being an almost organic approach – throw something together, put it up, slap “Beta” on it and change it based on feedback – the “perpetual beta”. Embracing Constraints though sounds more like, knowing what you want to achieve at the beginning based on the constraints you have and sticking to that goal.
Juliette hit the nail on the head – this is nothing to do with Web 2.0, its about the way the public sector has worked. Projects have, as you suggest, added more and more “must have” requirements. The simple fact is, many of these requirements are not “must haves” at all and of those that are, many are simply economically unrealistic (accessibility being an exception because of the legal ramifications of not matching the requirements).
The thing is, these days are numbered. The institutions are getting wise to this and starting to bring in better processes. The likes of ITIL and, notably, PRINCE2 are being introduced at Universities, for example, at a great pace and these really do change the landscape for projects.
Phil Wilson said
“its about the way the public sector has worked.”
This is incomplete. The private sector is exactly the same (although still light years ahead of the public sector, in my limited experience). Also, in practice, I don’t really believe in processes like PRINCE2, mainly because they’re sold as exercises in paying consultants lots of money, not as a practical way of improving internal processes.
Mark Sammons said
Whilst I don’t think that every aspect of the likes of PRINCE2 are being adopted, there are some aspects of it which are being adopted in some Universities (including Edinburgh) which are useful in this context – for example, justifying the business case for a project.
These are the things that define real constraints – artificially defined constraints are, in my opinion, pretty pointless, because it gives leeway for people to “just add this feature” or “let me polish this bit up”, etc.
I guess a lot can depend on the culture you come from but having seen too many projects here spiral away into resource-black-hole silliness, I’m jaded towards this whole area!
Embracing constraints by jonezy.org said
[…] the design and development world there is a lot of talk about constraints and embracing them to foster creativity. I love this movement and subscribe to it (at least I try […]
The ‘Cities Visited’ Facebook Application « UK Web Focus said
[…] blog. But as I suggested on the eFoundations blog, this can be regarded as an example of “embracing constraints“. And rather than having to wait for the application to be fully-featured but it is released, […]