I’ve been reading a few tech books lately and all of them are concerned with OO concepts, how to apply various solutions to various problems, how to create an agile/loosely-coupled/flexible/etc… architecture, how to interact with domain experts, etc…
What is sorely missing is literature on how to deal with a software product which has already been built. All the above issues are to be used when starting with a clean slate, something that doesn’t happen all the time. Starting with a clean slate is the best that a software developer can hope for, more often than not the developer will get parachuted in a no man’s land of duplicate code, outdated documentation, conflicting requirements, etc…
I understand that putting together a ‘perfect project’ is crucial to avoiding trouble down the road, but I find the current tech books to be a bit disingenious in the sense that they start from the best development scenario, that is they start before one line of code has been written.

I think someone should write a ‘Software Development: stories from the trenches’ book, it is badly needed. I would buy one.

I was reading this interview on infoq with Gavin King when I came across this paragraph:
“Second (change in SEAM) is the new concurrency model. With the death of the old paradigm of coarse-grained synchronous request/response, the assumption that concurrent requests in the same session are very rare is totally turned on its head. It’s now absolutely essential to have strong constructs for managing session-level concurrency.”

It looks like one major change that AJAX brought to development is concurrent access to state that was previously regarded in general as non-concurrent . It is interesting to see how the access to data in a concurrent fashion will be implemented. SEAM suggests that you should do this on the server, as according to this quote: “If you want to build an Ajaxified JSF application using ICEfaces or Ajax4JSF, you will run into all kinds of performance and concurrency problems if you don’t use Seam.”
Another way to implement concurrent access to shared state would be in the client: all the AJAX calls will be routed thru a manager that would determine (based on some configuration, etc…) which calls are to be serialized and which are to be executed immediately. BUT, AJAX is an asynchronous protocol, so you cannot serialize these calls at the client level because you do not know the order in which they will be executed on the server… *
So, it looks like we will have to deal with shared state more and more. The fact that this shared state is usually distributed and replicated (for handling fail-over, for example) makes it even more interesting. It would be interesting to see how this unfolds…
Later edit: I think you could serialize method calls that use AJAX calls in the browser by running them in a browser-based container that waits for a response from ther server to an AJAX call before making the next call. I don’t think I expressed it correctly though and I don’t have time to dwell on it…

It is possible that a legacy system on its way to being decommisioned will try to push legacy behavior to a new system. One example could be a new tax services that has to get input from an old system handling commodity trades. The new tax system has its interface for communicating with the outside world, but the old commodity service is sending tax information using its proprietary format. More than that, the commodity system requires some behavior to be implemented on the system it communicates with: the old “if the 4-th char in the message is a ‘C’ then do this, else do that”. It is pretty clear that this is pretty bad, after all you are trying to scrap the “if the 4-th char …” and replace it with a new set of rules that will be relevant for as long as possible. *

There are a few ways to deal with this type of requests. The first thing to do is to refuse outright trying to deal with this legacy behavior, after all in 5, 10 years the new system will have plenty of legacy behavior on its own. Pushing forward legacy behavior is not a good strategy either, you are basically putting more work at each new wave of system renewal.

Sometimes this is not possible, for example, it is possible that no development is done on the old system within a reasonable time-frame.
One way to interact with this system is to isolate the legacy behavior that will get discarded away from the core of the applications and make it available to this system in some form or another. Abstraction would help very well in this regard, if the business process your application is implementing is well abstracted then you could create a customized implementation that contains the legacy behavior, implementation which could be discarded when the legacy system gets decommissioned for real. If you are working in a flow-based environment you could create a partition of your engine dedicated to legacy workflows and code your legacy behavior in a workflow deployed in this partition. Customized communication channels which talk to the legacy system pushing legacy behavior onto you should help as well for isolating behavior that is prone to become obsolete.

*On a side note: decommissioning a system should actually be the side effect of decommissioning a set of business rules (and not vice-versa).

We are all familiar with the concept of applying various concerns transparently to an application. These concerns are, more often than not, infrastructure concerns such as: concurrency, data-caching, security, running a component in a particular transactional context, etc… A component should not know whether the data it works with comes straight from the DB or from a cache, it should also not know how it is secured within the application. The component should be agnostic of the operational environment.
I think we can apply the same mind-set to business logic. An object describing a FX trade should not care about how it is taxed or how it interacts with various legal entities, these business-logic concerns (such as taxation) should be applied transparently to this object in the appropriate places. To a large extent I am stating the obvious: behavior that is external to a component should be developed outside this component. I see, however, a relationship between applying infrastructure concerns transparently and applying business logic concerns transparently and I see also the failures to do so which end up in components that are bloated and very tightly coupled. I see this relationship, but I find myself unable to express it, I can say only that a good separation of concerns can be achieved if we try to think of various business logic components as components that have to be applied transparently onto a running application.
One last point: a (key) difference between infrastructure concerns and business logic concerns is that the former are way better delimitated: security is so different from data-caching that it is impossible (actually, we should not use this word, everything, even the most horrific architecture, is very much possible, check this out if you don’t think so) to build a component that handles these 2 concerns at the same time. Business logic concerns on the other hand are a lot more fuzzy and harder to delimitate.