SpringSource expect to integrate Grails in dm server, the OSGi paltform.

Ruby on Rails has now a serioous competitor.

Separation of Concern (SoC) is really important to me and goes beyond simple separation of layers os a software implementation. I should add “cohesive”, but this is part of the same idea: everythings doing the right thing in the rigth area.

This principle does apply obviously to the source code as a programming practice, useing a tool as maven that introduce some structure into the code organization. But it also apply to the architecture (SCA), the deliverables (DLL…and its hell), platform (OSGi / Spring DM server), components/framework (IoC, MEF), and methodologies (Agile).

The last one could be amazing, but I think the rational is the same: change adpoption. Kevlin Henney in his post Manage component dependencies for improved system quality says:

Another consideration in managing dependencies is the question of change. The dependency structure of a system can enable or discourage change, which makes dependency management a question of architecture, not merely one of fine-grained code quality

Having a system allowing effective depedency management at compile-time will ease test infrastructure setup (abaility to test a piece of code without having the entire system setup), hence quality…humm…be sure to automate your test to really ensure quality (doing manual repetive stuff is the best way to do it in a bad way over the time).

Having a system allowing effective depedency management at run-time will ease deployement as you will be able to do hotswapping of components even when they are running as for OSGi platforms.

Having a system allowing effective depedency management at run-time with version management, will allow multi-tenant applications and smooth upgrade…and probably start to solve the DLL’s hell.

Since that time, I downloaded lots of useless software on my mobile phone…no more space to deploy my application. I tried to deploy directly on the storage card but the way to do so did not pop immediately. I googlized around this topic to get the tip and did not find anything. 

The tip is simple: go in the properties of your .Net mobile project, in the “Device” tab, you click on the button on the right of “Output file folder” and select “Root folder”, then enter the full path “\Storage Card\Program Files\MyApp”.

My first though is: “does adding unit test on legacy code makes sense?”. I beleive it does not. You would like to refactore your code and be sure not to break any feature? Refactoring makes sense only to make your code evolve to change design or add feature and so on. Legacy code that support features you are not aware of (no unit test) … does not need to evolve…does need only to be replaced by other code (with test around this time). So I found this simply useless. 

The second issue I see is the feasibility of the solution proposed by Llewellyn. One nice side effect of unit testing is the decoupling. And usually, legacy code without tests around has a lot of coupling between classes, thrid parties and databases. Even if the legacy code was well written, you always have a damned coupling somewhere deep inside. So there is no way to instanciate the class you would like only for test purpose.

To summarize: you have some legacy code which works (new code has 99% of the bugs) but you don’t know what it does exactly. Why would you like to add test around? I usually add test to describe what I want tmy code to do and reuse these test to ensure evolution (refactoring, redesign…etc). In the case of legacy code: isolate it as much as possible, consider it as a black box and the only possible evolution is replacement!

The article Data on the outside vs. the inside from Pat Helland highlight some of this concept.

As I mentionned in this post about persistance, it’s very common to see RDBMS primary keys appearing in entity definition. This is a mistake for a couple of reasons. First, entities should be loosely coupled from the persistance type (RDMS, file, memoty…etc). Using a primary key is introducing technical details from the implementation in the model. The second reason I see is about the immutability of the key.

When i’m talking about key, it’s about the part of the reference of a business entity that identify it. For example, in a REST environement you could reference purchase orders using  this url : customer/C00123/PO/PO00112. In this case the key is the PO number (PO00112). 

The goal of a model (or schema) is to support business application in describing things. 2 things that may seam different are in fact the same from the business perspective. For example, from an asset management perspective, if a laptop already acquired is replaced by another one (of almost the same model) because of a technical problem/failure, the second laptop is concidered as the same. In this particular case, nothing change in the description of the laptop even if physically there are 2 distinc laptops.

So to define the key, you need to answer to this question: from the business perspective, what qualify/reference uniquely an entity type. In the case of laptop for AssetManagement it’s the AssetTag, in the case of employee in HR it will probably be the social number…etc.

Immutability of such key means that key of an entity can’t change. If you want to change it because you assigned a temporary one for example) that measn your application should expose a process for this and in fact you will create a new entity with the new key and look at all attributes and relationship to apply them on the new entity. And this process should trigger all audit system.

O’Reilly is creating on line books that are “community centric” : dedicated to a community and community-authored”. Everyone can contribute to this books composed of articles that are rated by the community.

Having a look at the 97 Things Every Software Architect Should Know is worthy.

In his post “We’re not resources”, Mark Gregory Turansky is writing:

Talent matters.

Winning organizations build winning teams, they don’t schedule resources and they don’t break up a winning team. They pay top dollar for top talent knowing that it’s entirely talent that makes a winning team.

I had the opportunity to see this during my (short) carrier. Large team tends to force this “resource” direction (large company also obviously). Having a small team (lets say 5 to 7) of talent and senior can produce far more than a “regular” team of 30.

In the case of a large team, I prefer split into small teams (preferably using the architecture components as a guidance … yes I know, some agile folks will not agree) with leaders having a good leadership and management skills to do people management, not resource management.

Where I disagree from Mark’s point of view is the direct relation he emphasys between talent and dollars. Sure, talent people are more expensive, but dollars is not a way to get people efficient, simply a way to get them in. This article form Mary Poppendiek highlights very well this point.

Another skill that makes the difference  (in addition to talent) is sense of responsibilities (I’m back to an agile point of view ). The best talented developer will not help that much if he (or she) cares only about his code, do not try to understand code/work of the others, do not try to help level 3 support even if it’s a totally unkown area of the software for him/her.

Having teams sharing the responsibility of what they deliver, composed of talent, and leaded by a people manager (vs resource manager) is one of the best cocktail to quickly create creative softwares.

I’m in agreement with Ayende (yes again!), even if I would not use the same wording, I prefer to do deprecation and black boxing (which is almost the same at the end).

Back to the initial question: How to handle legacy code?

I’ve heard in the past, managers saying “what are the estimates to get ride of the C++ code? » This is simply stupid: arguing that code is wrong due to his language is simple a non-sense. More over, I would add that legacy code is obviously less buggy than brand new code as less tested (even if you are doing TDD). Some may argue that there are intrinsic reasons to get ride of C++ because of the language itself: the interoperability in a JEE stack for example. I can’t say it’s totally wrong but JNI works well here, and anyway my point is that managers tends to think that removing/rewriting a piece of code and keep the exact same feature is simple, costless, without danger and will allow the implementation of lots of wonderful new features. This is 100% wrong.

First, legacy code is often a spaghetti plate: lots of dependencies. Even if you are using Spring or Windsor, this is a question of maturity of the developers and best practices, more than tooling.

Secondly, legacy code often encapsulates the business logic. Replacing such code can’t be done at the exact same level of features. If your legacy code was not written using TDD (or at least with a very large coverage by tests)…which almost never the case…you will lose some features, or have different behaviour. The best thing that can occur is that you discover yourself the discrepancies before the customers.

The suggestion of Ayende to embed an isolated version of legacy code in a new project is interesting. But I think it should not be just isolated, but also black boxed: I mean the legacy code should be seen as external code base (as a middle ware for example). The idea behind this is that legacy code is less buggy that new code, so take it as is, do not look inside use the interface it exposes and that’s it! So I think there is no need for new developers to learn the legacy code, only the legacy behaviour. Obviously, you will find some defects in legacy code, so you need at least one or tow developers that know about this code base.

Ok, fine, we have a big black box in the middle of our code: will I keep it for years? Obviously not, so that’s why we have to make this black box smaller each time it’s possible. The overall strategy is to have features leaving the old legacy code base to be reimplemented in the new code base. When I say “reimplemented”, it can’t be with the exact same behaviour…the feature has to be better, embrace new requirement, be more appealing…etc. Having the exact same behaviour would be very hard and will include what is not really nice in the feature.

Should I remove the code of the features that I remove from legacy code base? No. Even removing some code can create defects. If it’s not the case, it may be painless to remove all the dependencies. So I prefer deprecate the feature, I mean: keep the code, document the feature is replaced by another one, remove it from all the user interfaces and check that the new code base do not use this feature. This is safe and costless than removing the code.

This approach has some issues, may not feet your requirements or is simply not accurate for you. But, I think it provide a reasonable approach for legacy code management. What is important to be aware is that legacy code is very often the code that makes $$ and the code that is less buggy.

First, S2AP makes a big jump in the notion of application server…it’s not an application server but an application platform which is different and open new horizons. The application servers stand for containing applications. These application can be web app, web services…etc, but they are monolothics. With JMX and ear, you can go further in decoupling by allowing multiple micro appplications to be delivered inside the same enveloppe: the ear. But this is not enough: you still deliver an entire ear, you do not handle multiple versions of the same application, you get worried by transitive depedencies for third parties, communication between ear are remote calls. S2AP takes a real new approach. It provide separation/decoupling and allow integration betweens components without remote call (yes, this can be discussed : RPC and AOP proxy vs web service and remote calls). IMHO, this is why we are talking about application platform and not application server as it provide support for multiple components tightly coupled which are all belonging to the same application.

Various technologies tried to hide (or abstract) the fact a method call was remote or not. this is clearly a mistake. Remote calls are integration points, local calls are not. Integration points are fragility and low performances points. Developers and architects must be aware of all of them to ensure reliability and good performances. More over, developping applications mostly based on remote calls is an error and should raise a red flag. With S2AP we get a new approach which keep capabilities of regular applciation server. From a PaaS point of view, it is a significant technolgy jump (we will see the Microsoft response with Oslo project), and an instance of S2AP will be used to deploy all the applications of the SaaS vendor.

Those who read a previous post on my vision of PaaS, could argue S2AP is far from the Software Factory approach. I agree, but S2AP present at least one interesting characteristic: the hot deployment. This is an essential piece of technology to allow deployment of components. The next step are to better project management and source control management capabilities (a kind of mavenization), and allow deployement from one S2AP to another. This way a developper could have it’s S2AP instance to develop (and test) applicitions, then automatique deployment on the S2AP production system. Of course, this last step requires far more than just a hot deployment capabilities…but at least we have the key technological piece. More over all this inetgrations (SCM, PM, Eclipse, test and deployment) can be developed out of S2AP…I hope a lot of satellite projects will appear in that area.

 To conclude, S2AP is a very interesting opportunity for PaaS as it allows a decoupling and componentization of applciations inside a platform and not inside an ear.