This post was sparked of by Ayende's Go with high end solutions post, in which he talks about the benefits of creating applications which have a complex architecture, which resolves in less complex application code.
A while back I had the chance to review an application framework which had a few shortcomings:
- no IOC/DI
- no AOP
- no generics (and this thing was written for .net 3.5)
- copy pasted code all over the place
- crappy implementation of the Provider model
I organized a workshop for the various architects involved in the applications creation in which I presented a number of recommendations for the framework. During this workshop I got shot down, for
- the approach I proposed was too complicated for a normal developer (mort anyone?)
- there is no business value in modifying a framework that works
:sigh:
While I subscribe to the whole "If it aint broken, don't fix it" principle, I can't accept the statements above.
Complexity is something that can be hidden behind interfaces, thus being invisible to the normal developer.
You can drive a car without knowing how a combustion engine works..
Off course, it's more than interesting to know how the framework works, but it's not necessary.
In fact, when your framework encapsulates the complexity, development becomes easier.
Easier development = faster development = less costly development.
Sadly, there are no real numbers on this, but I have a gut feeling that the ROI on a good, intelligent framework is quite high. Additionally, there is no excuse for developing something that conforms to the standards of five years ago, when .net was young and List<T> was someone's wet dream.
I'm not advocating implementing the latest and greatest silver bullet every time MS pushes something out,
but using coding styles that have been around for years (AOP, IOC,DI) shouldn't scare an architect into a stupor.
The fact that it does might indicate that it's time to brush up on your skillset.
0.02 $
0 comments:
Post a Comment