Summa

Planning for application modernization projects frequently stalls because decision makers are frozen in their tracks by uncertainty around the wide range of options and approaches to replacing, improving, rehab’ing or reusing a legacy system. Build versus buy; go fast versus go slow; good versus cheap; user impact; technologies to use (and not use); level of reuse of legacy “stuff”; historical data access; data quality and IT skills are just a few of the considerations that boggle architecture decisions and confound planners. This article outlines some of the metaphors and patterns that have been useful to break the gridlock.

Continue Reading Add comment

You get in to work, grab a cup of coffee, and start your day with a nice, simple, easy-to-read method that stores a value object in the database. By lunch, it has ballooned to 8 lines of code, most of which handle exceptional cases, and make sure that maintenance developers can handle them in testing and production. In this post, I will describe four approaches that I have seen for minimizing this problem and describe some pros and cons for each. The four approaches are, in no particular order:

* Aspect-Oriented Programming (AOP): define an advice class that gets executed whenever any method throws an exception. Log the exception in the advice.

* The catch-all method (i.e. highest interface/tier logging): Log no exceptions at lower levels and allow all runtime exceptions to bubble up. At the highest tier (such as a web UI, main executable, Web Service, etc.), catch all exceptions and log them.

* Self-logging exceptions: Define a base exception class that logs itself in the constructor (takes a message and possibly a Class as parameters). All exceptions in the application must extend from this base class (3rd party or library exceptions must be caught and re-thrown), but no application code should ever log an exception.

* Developer logging: As above, each developer logs exceptions as they see fit.

Continue Reading 4 comments