Joe Homs

My friends and fellow ThoughtWorkers Michael Schubert, Jay Fields, and Stephen Chu were just complimented by Martin Fowler.

This isn’t to say that there’s no benefit in a business-writable DSL. Indeed a couple of years ago some colleagues of mine built a system that included just that, and it was much appreciated by the business. It’s just that the effort in creating a decent editing environment, meaningful error messages, debugging and testing tools raises the cost significantly.

What Martin doesn’t go on to explain is that this project vastly improved efficiency for a whole organization.  They went from a situation where it took months with dozens of programmers to change some business rules in their software to minutes with all sorts of extras they couldn’t get before like “what-if” simulations.

Jay wrote about some of the things they learned in this presentation on InfoQ and much more on his blog about DSLs.

via MF Bliki: BusinessReadableDSL.

An occupational hazard of being a consultant is that you get to see lots of the same problems in many different organizations.

It seems that sometimes little thought is given to how an organization can move from one technology to another or to move from legacy systems (where legacy means it doesn’t fit the organization anymore) to better solutions.

Today’s decisions can be tomorrow’s botleneck or bad design. It’s just a matter of time.

What can you do to help your future organization? Things like SOA can help. Great tests around your application are essential if you ever make the choice to change.

I’m looking for something better. I don’t know if you can ever get to a system that is that responsive to change. I’d like to see one that is.