Many of us have read books which talk about maintenance effort versus the initial build effort right? For those who haven't, the synopsis is: maintenence time = 10 or 100 times the initial development time.
Are we taking this fact into a lot of consideration?
To explain what I mean, let's walk through a couple of scenarios:
Versicorp
Versicorp has a development team that is bleeding edge. They are on top of the blogging world and grok AOP, IoC, and Groovy. They are even enlightened enough to send their entire team to TheServerSide Symposium :).
Three plus years ago they were writing a product, and were asking themselves:
- How should we handle persistence?
- What about the presentation tier?
amoung many other questions.
At this time they concluded:
Persistence: I don't want to hand code JDBC! We need to use EJB and Entity Beans. That is where everyone is going, and it allows me to encapsulate my data model. A few people argued for TOPLink, but they lost out
Presentation: I don't want to hard code "out.println(...)" in Servlets. Let's use JSP, and build our own controller mechanism to create a nice MVC system
They build the product and it was successful.
A year later they were onto another product and asked the same questions.
This time different conclusions were had:
Persistence: Oh man, I can't believe we used Entity Beans. Look at how everyone is trashing them... let's never mention the fact that we used them in the past! Now we need to move on to transparent persistence, and JDO!
Presentation: Our own MVC framework is OK, but it isn't as feature rich as the other solutions out there. We really need to just go with the de facto standard Struts
They build the product and it was successful.
Another year later they get onto another product, same question.
Persistence: JDO was nice, but we should really try Hibernate
Presentation: Struts it too bloated. They are fighting over JavaServer Faces, Tapestry, or WebWork 2. They also want to tie in with Spring for the business services
I am sure this product will be successful too.
If we take a look at what this company now has. They have 3 products on TOTALLY DIFFERENT systems. They have kept up with technology, but have to understand many products to be able to maintain their successful products. They have a couple of choices now:
1. Migrate to latest and greatest: Do they take the first two products and rewrite them to use their latest frameworks?
2. Keep the knowledge: Keep training their support staff to understand the legacy systems?
There are sacrifices either way, and at what point does it make sense to spend time and resources on migrating old products, when they could be used on new products? Maybe the old product is ready for a new version anyway, so it can be folded in?
Protege
Protege has a development team that is equally skilled as Versicorp. They are very customer focused, and don't all keep up on the tech to the same extent as Versicorp does... but they don't keep their heads in the sand.
They have also written three products, yet they had different answers to the technology questions:
Product A:
Persistence: They created their own JDBC wrapper, using a combination of the DAO and Command patterns
Presentation: They also created their own MVC framework
Product B:
Persistence: They continued to use their own JDBC wrapper (and tweaked it where needed)
Presentation: They continued to use their own simple MVC framework
Product C:
Persistence: They continued to use their own JDBC wrapper (and tweaked it where needed)
Presentation: They continued to use their own simple MVC framework
As you can see, Protege decided to stick to their guns. Their JDBC wrapper is very simple, and they could bring anyone out of college and put them to work immediately (as long as they know SQL). They ended up spending minimal time on the frameworks themselves, and instead put in the time on the business problem at hand. It may not be sexy to be working in this manner, but can you really argue that it is wrong?
Does IoC and Transparency help us migrate now?
One trend in the industry that definitely will help us move up the stack as we build more projects is the wave of lightweight containers and transparent persistence.
The hope here is that our object model can be written in a "pure" way, and that we can then tack on persistence, and tie components together via dependency injection. I do feel that this should enable us to move up the food chain a little easier as things change around us, but it is still a little work.
Some people will want to work at Protege, and others will want to work at Versicorp, but I definitely think that there are arguments for both approaches.
What do you think?
Previous Topic
