“Growth now depended more on the operation of markets, something that sits uneasily with the institutional inheritance. Innovation-based growth  is risky, uncomfortably so for security-oriented European societies. It responds to financial incentives, which is difficult to reconcile with the value Europeans assign to earnings equality. It requires continous reallocation of labor resources, which is at odds with the importance they attach to job security”.
Barry Eichengreen - The European Economy since 1945: Coordinated capitalism and beyond.

A pretty good picture of the difficult environment that Europe has to navigate.

Watching Eric Evans explaining how to incorporate agile methods in domain driven design gives you an understanding of some of the differences and commonalities between domain driven development and agile methods.

Agile methods grew out of the fact that up-front design which involved months of analysis was getting out of synch with the world which required faster development cycles and the need to adapt to a world changing at high speed (*). However, the responsiveness of agile methods and their focus on the next iteration limited development the scope at which development is carried out and eliminated the design phase out of the development process. The result were applications for which development slowed, if not even stopped, once the application reached a certain complexity.

Eric argues that in order to fix this problem we need to bring domain driven design back into the picture, but different from the top-down, process-heavy manner in which it was conducted before. The main reason modelling an application iteratively is that the development of an application is a learning process, a process of discovering and annotating a particular domain.

Some agile techniques such as the ability of reacting swiftly to changes and to be able to perform significant changes late in the game are presented, but they seem to me to be liabilities rather than assets. Performing a significant change late in the game is a very expensive operation since it is essentially a re-organization of the concepts encapsulated in the model followed by the confusion generated by the dissemination of the new model; such things should be avoided at all costs. Rapid changes in the model are also bad since they can create confusion.

One agile practice which I think benefits domain driven design is the break-down of the design process in iterations during which new domain concepts are inserted into the model. It is very important that these iterations also make sure that the model stays in synch with the domain in order to avoid late, massive and expensive domain re-factorings. In order to do this Eric outlines a series of diagnosis measures used for detecting when the model is straying away from the model.
While these measures are necessary what is missing in this process is a way for the domain expert to validate the model. The knowledge transfers have no feed-back loop from the domain experts. The developer seems the sole owner of the model, ideally the domain expert could become more engaged in the definition of the model rather than a passive disseminator of knowledge.

Modelling brand new domains or domains in a state of change will probably always be error-prone because the development of an application in a such a domain is a discovery process for all the parties involved (from users to business analysts to developers) whose end-result is defining the domain. In such an environment probably the only way to define and disseminate domain knowledge is to set-up sessions with domain experts. However, knowledge transfers in mature domains should be handled differently in order to leverage the existing knowledge. It is a good idea to get into the domain by first reading up on it and then engaging in knowledge-transfers with domain experts.

Eric Evans covers a lot of ground in his talk from the methodology of transferring domain knowledge to diagnosing misalignments between the model and the domain, solutions to correcting such misalignments and strategies for coordinating teams working on the same project. However, I wish he would have talked a bit about the structure and skill-sets of the teams involved in domain-driven development, of the ways to disseminate domain knowledge into a team and of how to engage the domain experts in reviewing and providing feed back on the domain being developed.
All in all a very good presentation which I encourage people to watch.

* The rejection of the analysis phase by agilists could partially be explained by the fact that the agile movement started at a point where appeared brand new domains (such as e-commerce, e-marketing, content management) which were in a continous state of transformation and for which there was no prior knowledge. Analysis in this case was viewed, to a certain extent correctly, as a process which requires significant investements (in order to overcome the lack of knowledge) without a clear return (the results could be obsolete in a few months due to unforeseen changes).
At the same time the revolution in communications created the opportunity to add on stakeholders previously considered un-related to the domain. Encapsulating requirements in an application from unfoereseen stakeholders meant that the domains became more prone to change and harder to predict.
These factors contributed to the misconception that analysis hinders rather than helps.

In this post I will go briefly over some important issues regarding regression testing and they can be used for managing complexity that I have come across in my experience.

A batch of regression tests covering an appropriate part of an application is a very good strategy to deal with growing complexity. Furthermore, the more complex the application the higher the need for regression tests because as systems become more complex the components that make them up tend to become unwieldy (*). In a heterogeneous team with a high variation in skill sets the regression tests are probably best written and carried out by the most experienced members of the team (it goes without saying that the implementation of some functional aspect and the test covering it should be done by 2 separate persons). If the tests are written by the most experienced team members this renders them more expensive, as a result care should be taken regarding the scope of these tests. I generally consider that regression tests should cover higher-value use-cases at a higher scope and that this scope has implications for the testing infrastructure.

The tests themselves should be isolated from testing infrastructure concerns and should focus mostly on the domain that is being covered. A pretty good discussion of these items can be found here. However, the tests should also be run in an environment as close to the production environment as possible, having seen an instance where tests covering an application deployed on a legacy database were passing without even inserting a single record in the DB only to have the application have problems later in PROD because of legacy datastructures.

Manual regression tests are expensive and this high cost has some bad side effects apart from having a higher price-tag: manual regression tests tend to be executed late in the release process. Also, by the fact that they take longer (being manual) they tend to cut deeper into the safety buffer dedicated to fixing bugs found during the release process. In order to solve this problem the regression tests should be in a format which allows them to be carried out early in the development process in order to detect problems early, ideally as close as possible to the development. This would mandate that the regression tests have a high degree of automation and a certain level of embedment into the development process.

Ideally, automated regression tests should be written in a format that ensures that the tests can be manipulated with ease by both developers (in order to be able to run them at an early stage in the development process) and by domain experts/business analysts (in order to prove their validity). A solution which may satisfy these 2 different audiences could be regression tests written in the programming language of the application by experienced team members and which are read-able by domain experts (**). For complex domains the testing infrastructure may need to be adapted in order to satisfy the second point as well.

* Components become out of synch with the required functionality as the complexity that they need to cover grows. Most of the time this misalignment is due the fact that the development pace is too fast and the information for correctly re-designing components for new functionality is unavailable. As components become unwieldy the need to refactoring appears and with it the need for regression tests which are a key component in the refactoring process.

** In practice, however, it is pretty costly to create a test environment that satisfies these 2 different audiences. This is why automated regression tests are typically written in the language used for development with senior team members acting as domain experts for writing tests of validating tests written by team members.

This Infoq presentation on DDD reminded me of some opinions that I wrote a while ago about DDD and about how it can be effectively applied in a typical development environment.

From my experience there are a few obstacles to using DDD in a typical development environment and one of them is the vagueness which accompanies the definition of different artifacts (entities, value objects, etc…), vagueness which sometimes may generate conflicts (*). The same vagueness works against the size of the development team and the distance between developers (**). DDD is probably best applied in settings which minimize both the potential conflicts and additional overhead of creating and distributing new concepts: small teams of experienced developers in close geographical proximity.
DDD projects tend to exhibit a high degree of closeness between the code and the domain which is a pretty good thing. Code which binds to the domain closely tends to “document” the domain and drive down the time for making knowledge transfers.

Given that DDD is best applied at the high-end spectrum of the IT workforce it follows that it can act as a big differentiator in the productivity of development teams as it further increases the productivity of experienced developers away from the productivity of less experienced developers. However, the gains in productivity may be counter-balanced by the reduced size of the available developer pool and the higher costs and dependencies associated with it.

I would conclude with the fact that the current way of promoting DDD probably works against it. Typically DDD is portrayed as an art-form or craft available to the lucky few which can appreciate and exploit its finesse. This is a pretty good way of driving the typical IT project manager away, IT managers really disliking to rely on artisans rather than on professionals.
For DDD to be applied at a larger scale it needs to be accepted by the business and for this it needs a more “professional” image. Rather than focusing on the “beauty” of various DDD patterns the  DDD community should probably focus a lot more on how to better formulate and deliver DDD best practices to a large audience. This, or it risks to remain at the fringes of software development.

* These conflicts are usually generated when developers cannot agree on a particular design. Given that DDD pushes design right into the core of the software development process these conflicts are bound to appear more often. In order to minimize these conflicts a certain level of experience in software modeling, of communication skills and, to a certain degree, of negotiation skills is needed. All this, in return, requires experienced developers. It may also require to have a domain expert handy (which is typical of DDD projects where the domain expert is a key person in the development process) in order to proof-read the design.

** Size and geographical proximity of teams are determined by the costs of effective communication (costs which usually increase with size and distance). To these communication costs we need to add the costs of debating vague concepts, of defining them and disseminating the knowledge required for manipulating them. These additional communication costs come at the expense of the usual communication costs and require them to be reduced.

From my experience I see that replication of data usually helps deal with performance problems, but that sometimes this replication involves replication of functionality, sometimes you end-up replicating some data on a different system (let’s call this the client system) and then you find yourself needing to code on the client system some piece of business logic which resides on the system from where data comes originally from (let’s call this system the master system).

More often than not this is a pretty scenario, because every modification to the business logic done on the master system has to be re-coded on the client system. Sometimes you find that you need to coordinate the releases of these 2 separate systems in order make the whole picture functionally consistent. One way to avoid re-coding the business logic on the client system is to expose the business logic on the master system thru some remoting mechanism (EJBs, Hessian, etc…) and then have the client system pass the data that it replicated locally to the master system in a synchronous call. While this solves the fact having the same business logic reside in 2 places it makes the client system dependent on the master system (*).

One solution to the above conundrum that is to replicate the data, along with the results of carrying out that piece of business logic on that data, to the client system. With this arrangement the client system does not need to have the master system up and running and it also does not need to re-code the same business logic inside. If you manage to use this (this approach doesn’t work in all cases) you will find yourself exporting business logic asynchronously by exporting both data and the results of carrying out that business logic on the data.

If I don’t write another post till January I wish you a Happy New Year!!!!!

* There is a physical dependency (the client systems needs the master system up and running for it to service calls) and possibly a library depedency which may couple the release cycles of these 2 systems (if the client system communicates with the master system thru objects rather than thry wire protocols you will need to synchronize the release cycles of these 2 systems in order to make sure that the client system doesn’t run in PROD with obsolete libraries).

Recently I was working on a business flow to which we had to add a new requirement: grouping a particular type of transactions under a file. The file had to be unique per day, it had to be created on the fly when the transaction batch starts getting processed and the transactions had to be assigned to it at the end of processing. The first solution that one could think of is to change the flow to check if the file exists (and if no then we would create it) and after this check we would assign the transactions to that trade file.

However, doing only this would pose a concurrency problem, namely that two or more transactions batches arrive at the same time when no trade file has been created yet. If each transaction batch would check if the trade file exists concurrently and try to create it, again concurrently, we could end up with duplicate trade files. One way to avoid duplicate trade files is to detect if a trade file needs to get created, allow one of the transaction batches to create the file while blocking the other transaction batches till the trade file gets created. We looked at the costs of blocking and as the costs looked pretty small (we would be blocking only once time per day when the file gets created) we decided to go ahead with blocking.

However, this approach clearly doesn’t scale, and we implemented it because it the conditions for blocking happen very rarely (as I was saying once per day) and it would not be feasible in the case of a higher amount of contention. We looked at some non-blocking alternatives and it looks like a good one would be to allow the transactions to check if trade file exists and if not then to create the trade file on the fly (without blocking) and at the end of transaction processing send further a message saying that there is a risk that some data is inconsistent (namely that there is the risk that some files have duplicates and transactions are assigned to duplicate files) and establish a procedure for repairing the transactions (if necessary). This would allow for non-blocking flows and higher thru-put, but it would come at the expense of a period of time in which data is inconsistent (in our case there is the risk that some transactions will be assigned to duplicate trade files till the duplicate trade files get fixed).

If inconsistent data is OK for the business and the rest of the application (it could be that these repair procedures as well as inconsistent data affect other parts of the application) and if blocking flows are creating significant performance problems then allowing for data to be inconsistent for a certain period of time while providing a mechanism for detection and repair of inconsistencies would probably solve the problem.

Another solution to this problem would be to detect messages which may cause blocking and create a new stage in the flow which deals with such messages.

Typically knowledge is considered to be an asset, some going as far as saying that knowledge is power. Well, when you design interactions between systems is better to avoid systems know to much about each other. Having deep knowledge about a system with which you are integrating is both a moral hazard (it gives you the opportunity to hack your way out of problems) and creates high transaction/interaction costs (typically the costs of transferring this deep knowledge to someone else).
The same reasoning goes for interaction between modules in a single system, please check out this article

P.S. I was shocked to see the date on that article: 1971. The fact that we are still struggling with these problems shows a pretty big problem with computer science. Most people equate computer science with exotic algorithms, it would be about time to add to this equation software modelling. It is pathetic when useful concepts for writing software developed 30 years ago are still unknown to the typical developer.
Software development has a pretty big educational problem (most developers educate themselves on their own and learn on the job), it would not be a bad idea to address it.

Decidedly, this is the acquisition season. After Oracle buying BEA it is now the time for VMWare to acquire SpringSource. I wonder what VMWare gets from this acquisition and different from a partnership with SpringSource and the only thing that I can think of is the exclusivity of selling certain types of higher-value virtual machines.
To make this more clear: VMWare probably has a cloud offering, similar to Amazon Elastic Compute Cloud offering. EC2 has started by selling bare-bones images and moved onto selling higher-value images, also known as Amazon Machine Images (the idea is that you could sell/make available your software - application server, database, content management server, etc… - as an Amazon image and charge per usage for the use of the original Amazon image + the use of your application). It is possible that VMWare will move onto selling higher-value virtual machines thru its cloud offering as well. Now that VMWare has acquired SpringSource it is very likely that they will start selling enterprise virtual machines equiped with all the packages present in SpringSource’s portfolio (which also includes some higher-value packages such as Spring Batch, Spring Integration, etc…). As SpringSource is now under VMWare I would not be very surprised if VMWare will get the exclusivity of providing enterprise, Spring-enabled, higher-value virtual machines (apparently this is not the case, check below). Not sure if it is feasible, but VMWare could even adapt Spring’s higher-value packages into specialized virtual machines (for example , a virtual machine running Spring Batch fine-tuned for batching needs).

If this happens it could happen that VMWare will become the premier hosting service for cloud-deployed enterprise Java applications and for specialized, Java-powered, cloud-deployed enterprise services. If the cloud is the future of application hosting (frankly, I would not bet the farm on it) then VMWare will be the hub where Java applications will be hosted (the difference between hosting a Spring application with VMWare and with a different cloud provider would be the difference between a virtual machine specialized for running Spring applications and an all-purpose virtual machine. This difference in the efficiency of hosting a Spring application would drive more users to VMWare’s clouds).

Still, 420 million dollars is a pretty big sum of money, especially in the current economic climate, and we will have to see if VMWare and SpringSource will find the synergies which will make them pairing together more than the sum of their parts.

Congratulations to Rod Johnson, Adrian Colyer, Juergen Hoeller and the rest of the Spring team and all the best to VMWare and SpringSource!!

Later edit: It looks like you can buy Spring-images on Amazon’s Cloud thru a company called Cloud Foundry which was acquired by SpringSource. I am still trying to figure out why VMWare bought Spring Source rather than entering a licensing agreement with them. I guess we have to wait and see.

Later edit: According to Adrian Colyer this is the future of how Java applications will be deployed. Still, I don’t buy into the cloud hype, I think that for the near future cloud adoption will be determined mostly by prices for different pieces of hardware. Maybe at one point there will be a difference in the efficiency of managing applications deployed in a cloud versus the ones deployed outside which would compensate for the differences in price of hosting an instance locally or on the cloud, but I don’t think we are near this point.

I have been reading lately A History of Economics: The Past as the Present by John Kenneth Galbraith and one of its main ideas, namely that economic concepts are the product of the times and societies they are born rather than the other way around, made me look at the concept of copyright from a different perspective.

The copyright concept is tied to the ability to make copies: when this ability did not exist (such as prior to the phonograph) or was severely impaired (such as during the vinyl era) the concept of copyright did not exist because there was no need for it. Copyright appeared when music recording moved to a medium which allowed for music to be copied easily enough for music buyers to make their own copies (roughly around the introduction of the compact cassette), hence the introduction of the right to copy. In the current environment characterized by very low copy costs and very inefficient means of enforcing rights to owning a copy you could say that the concept of copyright is living its last moments.

Copyright may appear to future historians as a concept which lasted for a period of time during which the ability to copy content was both developed enough to worry content creators and distributors about people getting content without paying for it and at the same time it was under-developed enough to allow the content creators and distributors to develop mechanisms for controlling content copies. Once the ability to copy and share content became  utiquitous the right to a copy of content ceased to exist as the means of enforcing this right started to weaken.

The question that is posed quite frequently is what will happen to musicians since they will not be able to profit from copyright due anymore? I would say that you could compare their fate to the fate of musicians before the concept of copyright started to exist; which means looking at music before the introduction of the compact cassette ( whose low copying costs allowed for easier manufacture of copies, which in turn allowed for greater diversity in music): musicians would either attain the status of Enrico Caruso and make their living by selling music copies or would rely on gigs building a more or less devoted following. The main difference between a musician relying on gigs in 1910 and 2010 would be that the musician living in the 2010’s would act at a global scale (in terms of distributing and marketing his music, of setting up a tour, of building a fanbase, etc…) while the musician living in the 1910’s would probably have acted at a local scale.