Monday, May 24, 2010

Just Do It

I've recently discovered 37Signals and have become a big fan. Like their apps and the way they think. I've really enjoyed their recent book Rework and their earlier book on web apps development, Getting Real. The latter book in particular really struck home with me, especially the technique recommended for building web apps:

1. Learn about the job that needs to be done (which is very different from just gathering requirements).
2. Stick to including only essential features
3. Put up a UI prototype based on what you know.
4. Gather feedback on your prototype.
5. Revise your prototype for the feedback you receive.
6. Repeat steps 3 and 4 until you get something worth putting up in production.
7. Build the necessary back-end coding.
8. Put your app up in production

If your app needs more after the first production release, rinse-wash-repeat.

The upshot here is to get up and do something...just do it. The book also suggests that this technique applies to much more than web apps and, after some consideration, I agree.

Last week, I had the good fortune to attend an OTN Architecture Day focused on SOA. The major concerns I heard repeated by others in attendance: it's darn near impossible to make a strong business case for SOA. And they're right. When you just consider Oracle's flavor of SOA, the breadth of the architecture is so wide that it's hard to envision how anyone could build a business case that covers it all. It's like trying to boil the ocean.

A better scenario would be to make a business case based on a job that needs to be done (or currently gets done in a cumbersome way) and make a business case specific to that job that needs doing. Maybe it's building reports with BI Publisher, or putting together some dashboards with OBIEE, or building a custom process with BPEL. Take a small case and limit your scope, then write a business case for resolving the issue with a small piece of SOA. Stick to essential features, which will keep the cost down, and bring it up quickly. Bring in your SOA incrementally, piece by piece in a way that makes sense, rather than attempting to swallow the entire pill at once. Any guesses on the process I'd recommend following to bring up your first SOA increments?

We could apply the same approach to implementing Enterprise Applications. Chuck most of those ugly written deliverables into the garbage…nobody reads them once the implementation is done anyway. Substitute "conference room pilot" for "UI Prototype" in the steps listed above. Switch out "back-end coding" for conversions, interfaces and bolt-on customizations. Looks much more do-able in a shorter time span now, doesn't it?

I think this stuff applies in many more areas of life, both inside and outside of IT. Looking forward to hearing your thoughts in the comments. In the meantime, you can check out 37Signals at signal vs noise.

2 comments:

oraclenerd said...

I have been reading them for 5 years or so now. Love their approach to design, be it UI or application (sometimes one in the same).

I try to espouse those core principles...but going up against the corporate machine is often difficult and sometimes dangerous. :)

Misha Vaughan said...

Hey Floyd,

Like you I thought Rework rocked. I did knot know about Getting Real though. Thanks for the pointer.

You KNOW my interest is peaked when someone says build a prototype and iterate before coding :-).

Cheers!

misha