Productivity versus design
Wednesday 5 April 2006 @ 3:06 pm
Filed under:

In his excellent written article The state of design Steven Devijver makes some intriguing comments on common design principles. While advertising the principle of simplicity, he focuses on the effect EJB technology had on current practices. Major target of critique is the inherited (as in taken from the olf J2EE world) use of data transfer objects while everyone seems to have forgotten the idea of rich domain models. You can agree with him or not (as one can follow on the discussion full of lengthy replies at, but one point he makes seems evident: when dealing with an object oriented world (language, platform) why restrict yourselves to behaviourless classes? It’s a bit of missed opportunity he forgot to mention how complex OO can make life and how delighting DTO’s can be. I do agree with Steven we not always get the best out of the OO instruments we are using but sometimes I also wonder for whatever reason we decided it must be OO (not even mentioning the additional layer on top dealing with cross cutting concerns). Not everybody is a PhD in applied computer science! At the end, a design will be settled by the fact it resulted in a piece of software that works and that was build within budget.

The last months I’ve been busy exploring productivity boosts around web application development. And during this quest I discovered there are only two major streams to follow: You either simplify everything you can and make life as easy as possible especially by underdesigning your app, or you don’t care about complexity that comes with ‘well designed’ OO and rely on the tools you use. No middle of the road! Setting up a rich domain model without the tools to maintain it? Forget it! But on the other hand you can also forget to build an utterly complex application without any design. It seems to be either the complete low- or the complete high-end of bandwith. So you either end up in a Ruby on Rails alike world with simple models (indeed, DTO’s without behaviour), simple controllers and a couple of useful helpers, or you find yourself behind a ‘do everything a normal programmer does not want to do by himself‘ kind of RAD environment. And it’s exactly this perspective you have to use when looking at ‘the state of design’: It’s all about productivity.

So, that said it’s time to drop in the bit over-acted and bold statement Java is not a very productive language. Neither is C++, neiter is C#, neither is any 3GL (not going to argue a language producing byte code that get interpretered by a virtual machine is not pure 3GL!). When you’re planning to write a data driven web application by hand using java, no matter which (set of) frameworks you’re planning to lay as foundation, the language you’ve choosen will become your biggest enemy. You might have the most elegant framework you could find (yep, of course it is Spring), you can have the most elegant design (including those lovely rich domain models) but the chance you got beaten by a bunch of scriptkiddies who just met the Rails environment is quite high. Unless you got tooling! Heavy tooling! And once you’ve got your ironwork, I bet you won’t care about design at all. That is up to the tools and embedded (meta) frameworks you bring with you. So, if you ask me what the state of design is, I would say it has been forgotten. Design has left the building. For the sake of productivity.

— By Okke van 't Verlaat   Comments (0)   PermaLink


Sha256 mining

Blog Categories

Browse by Date
April 2006

Upcoming Events

Monthly Archives

Recent Comments


XML Feeds Option

Get Firefox  Powered by WordPress

code validations
Valid RSS 2.0  Valid Atom 0.3
Valid W3C XHTML 1.0  Valid W3C CSS