EDABlog

A colleague of mine once stated that creativity is rare in technical people I had my doubts at the time as I’m fairly creative and often build unorthodox solutions tailor made to the problem but the longer I’m in the industry the more I agree.

The biggest symptom of this is something I called book syndrome. This is where famous author xyz ( eg Lowly , Fowler etc etc ) writes a strategy in a book and people use it in completely in inappropriate circumstances. When challenged on the solution they use the authority of the author to emphasize they are doing the right thing. While this technique may provide some job protection it is questionable that the famous author intended to apply it where it was applied ( eg Juval Lowly SOA 1 service per class  ) and in many cases like Fowler there are many methods yet a single patterns is repeated ad nauseum without any concern for the special cases for each project..

And it is not just books, Universities have a lot to answer for drumming in OO yet for a lot of small to medium projects scripts and RAD provide better and more consistent results  (   OO /RAD is Software theory relevant) . The fact is the bedrock of nearly all programming theory is based on 90% of the cost of an application being maintenance while true in the 50-80s this is clearly not true in the huge amount of small applications and scripts that never enter software studies ; in fact most of these programs never change over the life time of the program ( and are completely rewritten in a new technology after 10-15 years) is completely at odds with most of software development theory. I’m not against OO but I am against using OO in many inappropriate situations ( eg blindly following book – book syndrome) – even in an OO house RAD development will be faster , cheaper and deliver more reliable project deliveries.

The whole concept of an OO development house , an SOA house or a RAD house seems very wrong . Each has their pros and cons for each project and any competent team should be familiar with all techniques and use them where appropriate.

Every project needs to be taken on its own merits and facts like these are FAR more important whether OO is better than RAD or SOA.
 - Amount of change /maintenance over the life of the project
 - Fixed price contract
 - Team skills (Architecting for the team)
  - Breaking down the work ( eg SOA service layer and RAD front ends)