Tel que raconté par le maitre.

I was reading this post from Bill Burke’s blog and I found myself shocked by the sheer number of annotations required for making a business object WS-BA compatible (if I understand well the post).
One thing that I don’t like about using annotations is that they tend to stay with the code. I think that these documentation provided by annotations should be outside of the code because in this case you are coupling your business component to an external concern: you are coupling your component to the WS specification.
What you get in Bill’s post is the first stage of annotation creep: you need to externalize your component in order to plug it into an operational environment and you do it thru an annotation. Next operational environment comes with a brand-new set of annotations. And so on…
I keep thinking that the best way to deal with all these annotations would be to sub-class the original interface and apply annotations to it. You will have quite a lot of problems: the classes which are mapped to the original interface will need to be sub-classed as well and their sub-classes mapped to the annotated interface. You will have problems when updating the original interface, you will find that you need to update all its annotated sub-interfaces. And a whole other set of problems.
You feel like you almost need to define inheritance in annotations: an interface would inherit the methods from an interface and the annotations from a different place and you would work with this new interface properly annotated for the operational environment. My opinion is that annotations, like any other type of static, hard-to-change documentation, have serious limitations when it comes to exposing a class to many, varied environments and when you are using it for documenting operational concerns. No wonder so many people prefer XML…

BTW, this post uses Bill Burke’s post only for displaying an example of annotation-creep.

Later edit: If you think about the way annotations are currently used (putting them all over your code base in order to insert a component into various frameworks) they can be thought of as some sort of cross-cutting concerns (they are cross-cutting to a certain extent). I wonder if using something like an aspect would not do a better job of expressing the various concerns that annotations are currently used for. Aspects are orthogonal to the code-base at the same time, a pretty neat thing.
Wouldn’t it make sense to WS-BA-enable your whole application by specifying a point-cut and then applying annotations against this point-cut? It would be a lot easier and it would de-couple your code-base from external concerns. I am not sure if it is doable (I could think of a solution, but it is not pretty).
I think that the way annotations are currently used is not 100% OK and that it poses some maintainability problems in the future. Putting information into annotations is partly a response to XML-creep (as Bill Burke pointed out in the comments) but it is a solution far from perfect. What we are dealing with here is the need to add some information to a component in order to plug it into a framework. Annotations, as well as XML, are not doing a good job because they address this problem (plugging the component into the framework) at the individual level, at the component level. What we really need is a mechanism that would let you plug a whole set of components into a framework easily (I suggested using point-cuts).

Later Edit 2.0: I think that adding querying capabilities at the code-base level (similar to AspectJ`s point-cut language) along with a mechanism to interpret these queries into Java would be the killer feature that Java lovers wait for. It would create a whole new way of developing: for example AOP would be implemented by joining point-cuts to an interception mechanism. A lot of the current mappings (in XML or in annotations) could be solved by defining a point-cut and then a mechanism to interpret this point cut. In the above case you would define a point-cut of your components that you want to WS-BA-enable and a mechanism for working with the components returned by this point-cut. Embedding a framework into an application would consist of creating a point-cut and then passing it to the framework in order to process it.
This would be application-level introspection and reflection and it would do away with both annotation-creep and XML-creep. I can`t dwell too much on it cause I gotta go to sleep.

Later Edit 3: In this post Bill Burke argues about using meta-annotation in order to de-couple your code-base from framework specific annotations. Adding a level of indirection between framework-specific annotations will free your application from framework-specific dependencies, this is for sure, but you will still tie your code to a representation (the representation specified by your annotations that serve as end-points for the original framework specific annotations). I am not sure that this is desired. I still think that your code-base should not be polluted by any external concerns.
It is interesting to see what will happen:
1) Will the world continue with annotation-creep and XML-creep for plugging their applications into various frameworks?
2) Will the world settle for a mid-way solution, like the meta-annotation solution suggested by Bill for the same problem?
3) Will the world try to solve this thru a different design?
4) Will the world decide that frame-work plugging is so costly that we might as well migrate to a different language/platform in order to reduce these costs?
It is all a question of supply and demand basic economics: plugging an application into a framework is currently a pretty costly operation. If the demand for this operation rises significantly (the number of times an application is plugged into a framework increases) it would make sense to make an investment (new methodology, new framework, etc…) in order to slash the costs. Either you make the investment or your language/platform becomes so costly so that it will prove cost-effective to move to a different language/platform.

I was thinking about how blogs combat for spamming thru comments when I came across this idea:
There are entry barriers for comments because the user, along with a third-party, do the job of filtering comments, but as far as I know there are no entry barriers for track-backs.
A spammer could use track-backs quite efficiently because track-backs are managed usually thru third-parties (such as Technorati, Google, etc…) which will probably not be able to defend against this. These third parties will not be able to defend against this type of spam because they delegate nothing towards the blog against which they compile track-backs (at least they do not do this right now). The user should make the final decision on whether the track-back is a real track-back or spam and decide whether to display that track-back or not.

When will we have track-back spam? And what shape will take the defense against it?

Later edit: Obviously track-back spam has a much higher cost than blog comments spam so this may make it un-profitable.
On the defense side: you are essentially using a third-party service (like Technorati search) over which you don’t have much control. You could set-up a filter on your site that would filter the results that this third-party gives you.
So, it looks like track-back spam is not the way to go. Mind you, if track-back spam would have been profitable we would have had it a long time ago.

Yet another short post on a topic dear to XP-developers everywhere.

Testing as documentation.
Testing is not documentation. Or rather put is poor documentation. Sure you encapsulate the desired behavior of your application in tests, but this doesn’t mean that you actually document it. One of the reasons that testing is not documentation because in order to get the desired behavior out of a test (especially a non-commented test) you need to reverse engineer the test. As you can imagine this is a very error-prone process. You could make your tests more readable by commenting them but those comments are the actual documentation and not the tests themselves. If tests were documentation then documenting the tests would be as documenting the documentation, a mind-numbing concept on its own.

Tests, and unit tests especially, are low-level entities, they are close to the code. Documentation requires views of the application at different levels, from the low-level (small pieces of code) to high-level (functionality).While you could put together a series of tests which would test the application at a higher-level (and you should probably do so in order to test your application at this level) I don’t think you can navigate the tests easily in order to determine which are high-level, which are low-level, etc…

Yet another reason for which testing is not documentation is the fact that documentation and testing have 2 different reasons to exist: documentation is about informing a developer about the application (and this includes a lot more than functionality) while testing is about making sure that certain desired functionality is being implemented correctly. Documenting an application requires that you express some concepts in the most efficient and less error-prone way so that a developer can pick up the documentation and understand it as easily as possible.
This process of encapsulating knowledge in order to make it available to someone is a very tricky process and the failure of various methodologies would be witness to this. My impression is that this is a process which requires a lot of research, particularly in knowledge management, and that the test as documentation solution advanced by the XP-guys is just another milestone on the road to greater confusion.
Some people may find test as documentation to work for them, but I think they are a very small minority. Documenting an application is a process that is particular to a development team and assuming that all development teams can be reduced to a common denominator (such as test-is-documentation) is a pretty big mistake.

Test-driven development.
Yet another interesting use of testing. First of all, do you really want to start new development with a compilation error (talk about starting on the right foot)? Probably not.
The biggest problem that I have with TDD is that it encourages you to write a test before you write a class this test is supposed to test. As you expect, you get a compilation error. However, one problem that arises is that you reference the target class in the test itself, and you do this by usually putting the target class in a dummy package. Once all is fine you re-factor your code base and the target class gets assigned to its proper package.
This is a classic example of designing after coding: moving the target class to its proper package is a design issue (assigning a package to a class is basically managing the relationships between your classes) which you get to do after the class is coded. I think that this is a pretty bad arrangement, ideally you design before you code.
I know that design is seriously looked down in the XP community and TDD is symptomatic of this attitude.

Another short article on agile development.
You are probably familiar with people complaining that software development is one of the most error-prone and wasteful industries (if cars were manufactured by developers they would consume 50 gallons of gas per 100 miles, would require a visit to the mechanic every second week and would break down after 2 miles, or something like that).
Pair programming is that concept taken to extremes: apparently programmers would be more productive if one is working while the other looks over its shoulder. It is pathetic that such a concept which wastes the amount of available workforce exists only in software development (tell to a car mechanic, a painter, a doctor, etc… that it should have someone behind its back consistently in order to do its job well and it will ask you to have your head examined).
It is bad and it tells you that software engineering is a a very diverse field that has a pretty big management problem and that is willing to try every conceivable solution in order to put some efficiency in delivering products.

It also has a pretty big overhead and shows an impossibility in delegating a task to someone. The ideal software developer is working autonomously, has a fair understanding of the domain and a good grip on the technology involved in its day-to-day job. The ideal pair programmer is a developer which outside of its pair is like a fish out of water. You pick your ideal developer.

Some questions for pair-programming enthusiats: Pair programming shows a distrust in the persons paired up: when will you trust a person to work on its own? Does a software developer needs on-going tutoring in order to work? Isn`t it possible to teach that person how to write better code, to have some in-house workshops on coding in order to show some best practices? If you consider your workforce to be so deficient so that they need to be continously tutored don`t you think that you should probably do something about that? How do you prevent 2 developers working in pairs from re-enforcing the bad habits that they share?
The usual argument to defend pair programming is the following: programmer A can do task X in three minutes and task Y in twenty-five minutes, while the times will be reversed for programmer B. Put these two programmers together and they’ll be able to complete tasks X and tasks Y in three + three minutes. (This has been copied-and-pasted from Cedric Beust’s blog).
As you can imagine this is a pretty bad arrangement: at best it just displays that you don`t know your workforce well and you end up assigning tasks to the wrong persons, at worst you end up hiding deficiencies in your workforce: one person`s deficiencies could be hidden by its pair and you could end up assuming that each person of the pair reflects that pair`s capabilities. A pretty bad assumption.

All in all, pair programming is another software development practice that smacks of despair. I end this post here under the constraint of time. As you can imagine there is a lot more to be said about this practice, but I don`t have the time.

I don’t have time to carefully write this so I’ll just give a few thoughts on this apparent contradiction:
Waterfall was the main way to produce software, actually to code it, because the requirements didn’t change. A marketing team was going out, analyzing the market, coming out with target user and its needs and was sending this down to the software development department who would implement it. There was no need for iterations because nothing was going to change. However, if you think about it, iterative processes were probably used in the marketing department in order to define the target user (you needed to keep on refining the target user with each batch of data that came in).

Iterations are mostly needed for dealing with uncertainties and change. They avoid costly and risky investments. Being able to deal with uncertainties opened the door to a greater interaction between the software developers and their customers, in some cases the software developers working with their customers at the company department level (a B2C software developer would work with the procurement department of a customer, a document management software developer would work with the HR department of the same company, etc…).
The main change in software development was the change in the way software is distributed, via the web with very low distribution costs. Once these distributions costs went down it made sense to create customized versions of your product and distribute it to a larger set of customers, rather than to the “target” customer. A shrink-wrapped software package could not be sold to 25 different types of customers each customer being able to demand its own needs.

After the distribution costs went down customization costs went down: you needed to customize an application easily and reliably. Abstraction played a big part in this.

Around the time the waterfall model started to crack at its seams and software development started to move towards iterations a transition from products (targeting only one type of customer) to services (targeting multiple and very different types of customers) appeared. Again, my opinion is that transition is due to the change in the way software is distributed and to the fact that you could customize it more easily than before.

My opinion is that there is not a fundamental contradiction between the waterfall model and the iterative models, they are 2 different ways of creating software which spun out of different environments.

Later edit: These practices are not actually mutually exclusive, they can be used by the same team on approximately the same project. A while ago when I was working for an ASP we had to re-write our B2B application, this decision was reached after a lot of study. We went over all our customers that were using our previous B2B app, we looked at all their requirements, all their needs, the way we implemented them and we created an abstraction of our application that was targetting 70-80% of the needs of our customers. This, along with the default implementation, took about a month and it falls pretty well within the waterfall model and the dreaded Big Design Up Front. Next, however, we changed the way we continued developing the application: we did small incremental changes as we interacted with our future customers and as we got more information about their needs. Creating the skeleton of the application could be done in the waterfall model: we had data to analyze (the data was our customer`s requirements), to model and to code. However, when dealing with our future customers we had no such data (we needed to extract it from the customers) so it made a lot of sense to switch to iterations.
As I said above, I believe that iterations work well with uncertainty and change.