Plenty of applications are exist in more than one era, chances are these kind of applications would have more than one frameworks in their application.

For example, Data Access Layer pattern has significant changes over the years. When I was writing my first .Net application in college, we were using SqlConnection directly in our UI , then on my first time in my professional career, I was introduced to Active Record pattern. Few years later, Data Mapper seems the make sense way to build Data Access Layer.

There! I have been introduced to more than three style of architectures in the relatively short period of time, how about if a product survives more than two or three years? than we are going to see a plenty of frameworks in there.

Obviously this leads to major confuse in maintenance. When developers need to fix or enhance in the old modules, they would see a different set of frameworks in there, which one to follow?

This condition usually happen when in maintenance phase, architects and/or developers see another very good framework which solves their day to day or (even their future) problems, or it is feature rich than theirs.

In DAL, plenty of us have used Custom DAL in years, but with the availability of 3rd party ORM, such as NHibernate and SubSonic, another question has arised, why we need to maintenance our own DAL? why not using the existing solution in the market? especially since these ORMs already matured and have a very good community/vendor supports available.

Which One to Follow?

This is tricky one, if we need to fix/enhance a legacy module which contains multiple framework, then choosing the newest framework would make that particular module much even harder to maintain in the future.

I would prefer to continue using the legacy framework, since that would sit nicely in the picture, or at least in that legacy module.

How to Solve Permanently?

Of course, the very thing to solve this is to avoid it in the first place

I would think this is a Technical Debt, as the architects or the stakeholders choose to incorporate new framework without upgrading the existing one and leaving the problem to be fixed in the future.

Why? Plenty of reasons surely, a favourite reason is no budget.

How to fix this? Well, I think these three would do, however, none of them would reduce cost to zero, just to minimize the cost:

• I think this is where the big decision should has been taken in the first place, when the time has come to choose whether to incorporate or not a new framework, the stakeholders should calculate about the upgrade cost too … To avoid more cost in the future: maintenance that is.
• Or, choose to upgrade all of legacy frameworks gradually. This is more make sense in the real world, since stakeholders can have their new framework up and running first, see if everything is working out okay, then incorporate it in everything.
• And of course, the another option is to not upgrade legacy framework at all. This is can be acceptable and in line with the magic mantra: “If it’s not broken, don’t fix it” As long as the legacy module working out just fine, than leave it there as it is, don’t put an effort to fix it.

The last effort then again would cause a Technical Debt, however, if one’s company is certain that a particular module doesn’t need a maintainance or enhancement in the future, then perhaps leave it behind is the cheapest option.

But, that mindset would bring another set of problem itself. One of them is increasing integration conflict in the end of the development iteration.

Let say there is a changes in Data Access API, or Domain Model. These changes would have plenty effects in upper layers above them: facade, service, presentation, etc. If developers not get latest these changes early, they will continue to develop by the wrong code base for plenty of items, when finally developers decided to get latest, the error would be massive.

That can be avoided by get latest often, let say every morning, so that developers can detect early what are newer integration conflicts this time.

Compile Error

This kind of problem is quite easy, compiler would point which line is causing the error. How to fix it would also (usually) straightforward, although no one would disagree that this is annoying, especially since previously your code is working out okay.

Lucky for us, we can use Continuous Integration tools for early detection to this kind of error, one of them is Cruise Control .Net. Unless, the error is intended, so that developers can follow the new API rather than the old one.

Runtime Error

This is the real problem, since we should test our modules before we can see what wrong with them. Regression testing obviously need to be done too, if the changes happen in the middle of development … headache.

The one way out is to assign tester to do the regression testing, while the current developed module can be tested by developers themselves.

Conclusion

Although there is no easy way out, I still believe that changes can occur any time, even in the middle or in the end of development iteration. And I believe we should check in and get latest often to get the earliest possible any integration conflict, leaving us with enough time to fix any error found.

class TaxService
{
private ILogger _logger = null;
public TaxService()
{
_logger = LoggerFactory.CreateLogger(this);
}

public void LogicA(object A, object B)
{
// Do important stuff here
_logger.InspectStates(A);
}
}

At above code, I initialised _logger in the TaxService’s constructor. Although this is quite good enough rather than creating concrete ILogger implementation class, however, I found this inisialisation is somewhat distracting users from TaxService main intention.

Then, I can rewrite my above code to use Dependency Injection, so that TaxService shouldn’t have to know how to create _logger explicitly:

class TaxService
{
private ILogger _logger = null;

[Inject]
public ILogger Logger
{
get { return _logger; };
set { _logger = value; };
}

public TaxService()
{
}

public void LogicA(object A, object B)
{
// Do important stuff here
_logger.InspectStates(A);
}
}

Boom! suddenly TaxService class doesn’t care how _logger is inisialised, by this, developers who develop and use this class can consentrate on how TaxService should work and ignore all of the infrastructure issues.

Usually there are two ways for DI containers to do the type bindings, by XML or by binding on code. Ninject uses binding on code, which is basically it’s a fluent interface pattern to declare type bindings policy:

Bind.To();

I’m not sure which one is better. However, I usually thought that by having type binding policy written in XML, we can put it away from our general code, which then the code will look much more cleaner. Once it is established, I don’t have to see it again for a long long time.

When I use binding on code, somehow I found that the declaration is quite verbose and may distract me from my real problem. Anyway, it is just the matter of taste in the end.

Like my friend always told me:  “asking people to use automatic unit testing, instead of manual testing, is just like to ask them to change their mindset of development”. Yap, it is in my mindset that I can do mental unit test toward my code , which is speedier rather than I need to write a unit test first.

But, after reading up Jimmy Nilsson’s Applying Domain-Drive Design and Patterns, I realized that I need unit test to make sure my code satisfied the requirement that it need to fulfill, and survive across refactoring processes.

Not to mention refactoring is just way too common thing to do in development phase (and maintenance), how can we be sure that our code is as good as it was?

Without Unit Test, we should test the refactored code manually, that’s hard.

Obviously unit test need to be built with very attention to detail, to make sure all requirements are there to test.

There … I change my mind again, I’ll use automatic unit testing from now on.

Tools are also widely available for this practice, my favourites are NUnit and Visual Studio Unit Testing.

However, my last project shows the biggest problem with them: inflexibility to handle changes, not natural and too frigid. Although they are, obviously, still useful in many projects.

Now, in the next project, we are going to adopt Scrum methodology, since changes may be often to happen and we have luxury for having our client working with us in almost entire project duration.

I take my time to read Agile book, and I think this methodology is great in term of flexibility to handle changes. Can’t wait to practice it in the real world. (start on Monday, March 2, 2009 anyway )