Personal opinion on software development in general, development methodologies, tools and best practices in particular

Last week I attended a talk called ‘Productive Programmer’ at Devoxx, Antwerp, Belgium. It inspired me to write a blog about this interesting subject which can help us all to become more productive and even to end up in hyper productive state. And with ‘all’ I mean everyone working in the IT business: developers, testers, analysts, project leads, consultants, project managers, scrum masters, product owners, … Sorry for the roles I forgot to mention.
For those who attended the talk too: don’t worry, this isn’t a simple copy of the talk, it’s inspired by the talk, my personal experience and knowledge so it covers much more.

Individual improvements

First of all we can improve productivity as an individual.

Multiple clipboards

Though we’re not living in the stone age anymore, it’s still impossible to have multiple items on the clipboard at the same time in most operating systems. Most people use a text editor as buffer but opening the text editor, adding 1 item to the clipboard, pasting it into the text editor, adding another item… and finally copying all the text from the text editor to the location where you need it…is a huge waste of precious time! But don’t worry, a tool called CLCL allows you to have multiple items on the clipboard at once. This tool comes in very handy!

Ban the mouse

In fact we can say that in general, using the mouse is not only less productive than using the keyboard, it also causes RSI. If you use the mouse during your whole career it’s not a matter of ‘if’ you will suffer from RSI, it’s a matter of ‘when’. So knowing keyboard shortcuts doesn’t only save time, it’s also much better for your body. But enough about the body, we’re IT guys, we sit behind our desk the whole day so who cares about the body 😉 So back to productivity then… mousefeed is a very nice Eclipse plugin which tells you the keyboard shortcut if you execute an action by using the mouse. You can even make mousefeed undo your action if you use the mouse. It will only work by using the keyboard. Can be annoying but you know, the best way to learn something is doing it the hard way 😛
IntelliJ’s equivalent of mousefeed is called Key Promoter which does actually the same but afaik it isn’t configurable.

Focus/Locus of attention

A rule of thumb: try to avoid multitasking and too much task switching. Try to concentrate on one single task instead.

For example you can open your mailbox in the morning and after lunch. Read all your mails, reply/forward if needed and close the mailbox when you’re done. It seems stupid but it really helps. You can concentrate on handling mails and pick up a new task afterwards. You can focus on the next task without being distracted by incoming mail alerts.

Same thing can be said about instant messaging. It’s cool that people can reach you by using different ways of communication but when it reduces producitivy, you should really think about the added value for you.

Defining some general guidelines is necessary. If there are too much internal discussions, it’s better to book a meeting room where people can discuss things without disturbing other people. If people have too many non-workrelated chit chats, you can introduce quiet time, …

Automated deployments and navigation

Introduce automated deployment instead of only configuring automated packaging. In fact you’re just automating deployment on the integration environment by integrating this as a build plan in the CI. This way one can check the current state of the application at any time.

Use macro’s to navigate. During development of webapps, developers will test the screens locally. Most of the time they navigate to the page they want to test by performing manual actions like filling in some data, clicking on some links and buttons. Selenium IDE is a firefox plugin which records macro’s. You can record all those manual actions in a macro and Selenium IDE can execute them very fast for you. This saves a lot of time and lets you focus on the core task: testing your page.

Coding practices

Pair programming

Pair programming sounds like a waste of time to some managers. Productivity is reduced with 15%, which is absolutely not much, but the amount of bugs is also reduced with a minimum of 15%! This means that quality is raised but also that no defect control needs to be done afterwards because it’s done at the same time as programming. An extra important advantage is that knowledge is immediately spread over both programmers.


Most of us know popular acronyms about best practices such as KISS (Keep It Simple, Stupid) and DRY (Don’t Repeat Yourself). YAGNI is yet another one to keep in mind. It stands for ‘You Ain’t Gonna Need It’ and means that you don’t have to overengineer, don’t do some premature optimizations, don’t write stuff that may be used by someone… some time… Just write stuff that is needed now, that’s all, folks!

A good idea for an IDE plugin is YAGNI, some Microsoft Clippy clone which annoys you all the time when you’re doing something stupid.

Improving as a team


Communication is very important. Organize the room in a way that communication is stimulated instead of trying to isolate every team member. Stand up meetings can help but it should be a mindset. Just like the team that has code ownership instead of a single team member.

Communication can also be forced by organizing a short daily meeting, like the stand up meetings from Scrum. Everyone knows what team members did and what they will do and impediments will be visible.


As a manager it’s important to keep your team motivated to make them productive. You don’t do this by command-and-control-ism but by trusting the team and expecting that they will succeed. Trust means also that teams are allowed to make mistakes. Teams that are comfortable at making mistakes often find that they also produce extraordinary results.  True success is often comprised of multiple failed efforts that did not sink the team, but rather allowed the team to learn things they could not have learned otherwise.  Working within a corporate culture that recognizes this is a key component to super teams.

Independence and a sense of ownership

The team needs to feel that they can contribute creatively and have some control over the game. This isn’t necessarily total ownership, but some.


Political games inside a company or inside a development team, dumb corporate rules, wrong motivation schemes, communication problems due to personal likes and dislike – just some factors that make cooperation almost impossible.

Job protection is the absolute opposite of cooperation because one will protect his job by keeping some info for himself. Of course that’s contraproductive, knowledge exchange is the key to a great team.

It’s been a while since my last blog post about Vaadin. Summertime you know 😉

But Vaadin was still evolving towards an even better framework. I’ll summarize the new fancy features.

Last week I went to a very interesting talk about Android. THe programming language isn’t Java but is very similar to Java. Creating fancy applications seems still a bit difficult but one can only develop webapps of course. Vaadin also has a framework to develop smartphone applications (webapps) called Touchkit.


A lot of people don’t know that you can develop applications for smartphones with Vaadin TouchKit . These applications have an iPhone look and feel but will run on iPhone, iPad and Android.

TouchKit is optimized to run on smartphones so it’s optimized for low low performance and low memory (ROM) devices.

The well known Vaadin sampler, which demonstrates all Vaadin components along with the Java source code, is also available for Vaadin TouchKit:

If you want to know more about TouchKit (who developed it, why, what’s the roadmap,…) you can read these blog posts:

Add-on directory

The add-on directory that was released this year is a marketplace where themes, UI components, tools, data components and miscellaneous add-ons are distributed to the community. Most of them are free, for some of them you’ll need to have a license.

It’s a very good initiative, no need to write a fancy component because there’s a big chance you’ll find it in the add-on directory. Most of the add-ons have a demo site, source code, project homepage, issue tracker and forum attached. But there was 1 shortcoming: maven integration.

Most Java projects are based on Maven, Spring and Hibernate and Vaadin supported all of these. But if you wanted to use an add-on in your project, you had to download the jar and add it to the classpath. Since I use Maven I do not longer like the idea of commiting jar’s in Subversion. So I added a script to SVN which contained the code to install the add-on jar in the local repository. Next I installed it on Nexus and added the dependency to the pom.xml.

But times change and the guys from Vaadin really listen to the community. They know very well that a framework on itself isn’t good enough. Integration with other common used frameworks is a must these days. So the guys set up a Maven repository, add all existing add-ons to it and all newly added add-ons will be automatically added to that repo.

More info about the add-on maven support can be found here. The code that must be added to the pom.xml file is also available on the add-on directory site.  Easy huh?


Another proove of the fact that Vaadin is still evolving are the amount of talks that cover this framework. Joonas Lehtinen, CEO of Vaadin will present on Devoxx on 17/11/2010:

Another more detailed talk about Vaadin will be the success-story of the conversion of Black Belt Factory (aka Java Black Belt) to Vaadin. It’s scheduled on 30/03/2011 in Brussels and is organised by the  Brussels Java User Group (BruJUG).

The talk will take 3h and will be presented by the CEO of Black Belt Factory.

I will attend the talk, and you?


Vaadin is a Rapid Application Development (RAD) framework for RIA applications. I only know it for a few months but since I started experimenting with it, I’m really in favor of it.

I see a lot of advantages compared to Sun’s Java EE standard front-end framework JSF.

  • First of all Vaadin is a java library, so you only have to write Java to build a complete frontend. No need for a specific frontend language, no need for converters (for comboboxes),… This also implies that you can use the full Java power on the frontend side and that’s an huge advantage because frontend code is now type-safe and easily refactorable. You can unit test your frontend with JUnit. You can also use all existing java libraries on the frontend side, for example LOG4J.
  • Another advantage is the fact that Vaadin is easy to learn (JSF isn’t!) and to use: it’s straigtforward. It feels like developing desktop apps and for me developing desktop apps feels much more intuitive than developing web-apps the way I’m used to.
  • Vaadin uses convention over configuration. No need to register new components, validators or whatever in different xml files. Themes have a default folder and a default folder structure.
  • Vaadin is very well documented. There’s the book of Vaadin wich explains every aspect of the framework very clear. On the site there’s a blog, a FAQ section, a wiki, a forum, examples with Java source code, …
  • It’s very easy to extend. Want to create your own Validator? Just implement an interface or extend another Validator and use it. Want to create your own custom server side component? Just extend the CustomComponent class or extend from another component. There’s also an add-on directory where you can download UI components, data components, tools, themes, …

But enough about Vaadin itself. The purpose of this blog post is not to explain Vaadin itself in detail but how to integrate it with other commonly used frameworks: Maven and Spring.

Vaadin comes with a plugin for Netbeans and Eclipse. These plugins provide a wizard which makes the creation of a new Vaadin project, themes and components (also client side) very easy, it even provides a WYSIWYG editor but that’s still experimental.

But as expected (or not) the project structure created by the plugin is not the structure I want because Vaadin uses its own structure which differs from the well known Maven structure. Though this is not a big pain in the ass because Maven integration is extremely easy to accomplish. The easist way is by using Vaadin’s Maven archetype:

mvn archetype:generate

There are also archetypes ‘vaadin-archetype-sample‘ and ‘vaadin-archetype-widget‘. The first one generates a sample Vaadin app and the second one creates a project to illustrate how to create custom GWT widgets (yup Vaadin is based on GWT). Of course the Vaadin library itself can be found in several Maven repo’s. The only shortcoming at the moment is that the add-ons aren’t ‘Mavenized’ yet. You’ll have to download the jar’s manually. But an issue is created fror that and they’re working on it, so it will be there soon.

To enable Spring in a Vaadin app you’ll have to use SpringApplicationServlet as explained here. That’s all.

Since frontend and controller are now written in java, we can inject Spring managed beans into the Vaadin controller classes. Of course we would like to use annotations instead of all those XML config so we would like to make use of the @autowired annotation for example.

To do that we must put the <context:spring-configured /> element in our applicationcontext and enable component scanning by means of the <context:component-scan /> element to scan out controller classes.

The controller classes can be Spring managed by adding the @Component annotation but it sounds acceptable that you don’t want to make some front-end stuff Spring managed. If you don’t want to do that you can use the @Configurable annotation. It marks a class as eligible for Spring-driven configuration.

Now the last thing that needs to be done is AspectJ weaving, otherwise using the injected Services will cause NullPointerExceptions. You could add the maven-aspectj-plugin to enable compile time weaving. The disadvantage of this approach is that you have to do a Maven compile because compiling in the IDE won’t trigger AspectJ weaving.
You could change the project  into a Maven project instead in Eclipse but then everytime you save your file, Maven compilation will be executed and that’s not what we want.

We can use <context:load-time-weaver /> to enable AspectJ load time weaving. This way we don’t have to run a Maven compile to weave. You’ll have to pass spring-agent.jar to the application when running it to make loadtime weaving work. Once this is done, it’s pure AspectJ LTW which can be configured using ‘META-INF/aop.xml’ which is automatically loaded as AspectJ LTW is initialized by <context:load-time-weaver/>. The last step is to pass ‘-javaagent:path/to/aspectjweaver.jar’ to Tomcat’s VM arguments instead of using the aop.xml and load-time-weaver tag.

If you don’t like load time weaving (it makes hot redeployment fail from time to time), you can remove the <context:load-time-weaver> element and the aop.xml file. Instead you can install AJDT plugin for Eclipse. The project will be recognized as an AspectJ project and yhe only thing you need to do is adding spring-agent.jar to the project’s Inpath.

More Vaadin stuff in one of the next blog posts!

A lot of people heard about Scrum, some of them know what it is, some of them tried it already and for some of them it failed. In this blog post I’ll enumerate things you should do if you want your Scrum project to fail. For those who don’t like failure, keep on reading the descriptions below each topic, they’ll help you to make Scrum succeed.

I won’t cover Scrum basic principles like sprints, daily standups, task board and burndown because I expect you know them. Those are things you must do if you’re implementing Scrum, I think that’s quite obvious.

  1. No or bad retrospectives
  2. How would it be possible to make things better if you’re not looking behind? Retrospectives are required because there every team member can communicate what went good and what could have been better. And of course you’ll have to learn from your mistakes. If that isn’t done, retrospectives are useless.

  3. Bad Product Owner
  4. The Product Owner should be available at any time. He should participate in standups, retrospectives and sprint planning but he should not estimate tasks during sprint planning because estimations are the team’s responsibility. He should be able to prioritize the backlog by business value. For this, he needs to have a vision, a business plan and a release roadmap. He should define the stories in a way that they are clear enough for the team to understand what they mean. On-going changes shouldn’t be present in the Sprint Backlog.

  5. Bad Scrum Master
  6. The Scrum Master should not become  a team administrator. The team should be self-managed. The Scrum Master should not lead but steer the team when needed. He should make final decisions if team members can’t agree. He should be able to make a prioritized impediment list and to remove those impediments as soon as possible. He should keep the team focused and try to improve things constantly: things can always get better.
    Tasks should not be assigned to people, they should pick them up themselves.

  7. Scrum Ceremonies are taking too long
  8. In stand up meetings everyone should say what he has done, what he will do and what’s blocking him. That’s all that should be said. A stand up meeting should not be a social talk and you don’t have to provide detailed information. If one needs detailed info he can get it after the stand up. Stand ups shouldn’t take longer than 10 or 15 minutes depending on the team size.
    Retrospectives and sprint planning meetings should be timeboxed. Stick to the essence of the meetings. Scrum should be fun but it’s not meant to be a playground.

  9. Wrong definition of done

  10. At the end of each sprint the produced software product should be production ready and thus demo-able. This means that it should be tested, not only by unit and integration tests but also manually. And of course the developers should know about the exit criteria the testers are testing against or there’s a mismatch between automated and manual tests.

  11. No velocity tracking
  12. Team velocity should be tracked. The Scrum Master must undertake some action if the team is slowing down. He must find the root cause by means of the 5 why’s method or Ishikawa’s fishbone diagram.

  13. Waterfall within sprint
  14. It’s better to have 75% of the stories 100% done than having 100% of the stories 75% done (cfr. definition of done). Not a single person but the entire team owns the story and testers should be part of the team.

  15. Technical debt
  16. Technical debt must be avoided because otherwise more defects will appear at the end and last iterations would produce less new functionality while every iteration should produce as much functionality as others. Refactorings (and redesigns) should be done immediately when they are needed because they cost too much and take too long if done at the end. Bugs should also be fixed as soon as possible.

  17. Interruptions/PO bypassed
  18. The team should stay focused which means that too many interruptions are bad. One can ask for support of course but new features should be requested to the product owner. He should add it to the backlog and prioritize it again. If it’s an important feature, the team can already deliver it at the end of next sprint. One should not send feature requests to team members directly.

  19. No analysis/documentation
  20. Scrum does not mean that no analysis should be done or no documentation should be written. The way of doing analysis and documenting is just a bit different: it’s a continuous process. Stories in the backlog should be clear enough for the team to split it up in tasks and estimate them during sprint planning (= at the moment the story will be implemented in the sprint, it should be detailed enough) . This means that stories shouldn’t be too detailed from the beginning of the project (but still clear), but stories need to be estimated in story points when creating the backlog.

My advice/conclusion for those who want to try Scrum and want to succeed with it:
Scrum is not a silver bullet. It’s no methodology that defines a lot of rules. Instead it’s a framework which defines some best practices. Of course you’ll have to adopt the basic principles to make it work. But how some things are filled in (when do we do standups, how does a task card look like, …) is up to you and can differ from project to project.

Scrum is a completely new way of thinking and mind-set shifting. It is not just a list of practices: if you “stand-up” it doesn’t mean you do Scrum …


Did you ever do a code review where you recorded an extremely high amount of WTF/m? And did you ever wonder what the cause of all this bad code is? Most of the time cause number 1 are the use of design and coding antipatterns.

If you like definitions, here is one: An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences. The AntiPattern may be the result of a manager or developer not knowing any better, not having sufficient knowledge or experience in solving a particular type of problem, or having applied a perfectly good pattern in the wrong context.

Reinventing the wheel
IMO an antipattern of frequent occurrence is the lack of knowing the existence of some useful frameworks/libraries. Apache commons lang and commons collections are dependencies that should be present in every Java project.
You can write your own fancy for loop for filtering or selecting some objects in a collection or you can use…) or CollectionUtils.filter(…).
You can do some fancy not null checks ending up with a huge if-else construction or you can use StringUtils.isNotBlank(…). It’s up to you.

A general rule is not trying to reinvent the wheel. Some people like to write their own Reflection utils while Apache commons beanutils, Spring’s BeanUtils and BeanWrapper will do the trick.

Cargo cult programming
Cargo cult programming is a style of programming in which patterns and methods are used without understanding why. The term “cargo cult”, originally referred to aboriginal religions which grew up in the South Pacific after World War II. The practices of these groups centered on building elaborate mock-ups of airplanes and military landing strips in the hope of summoning the god-like airplanes that had brought marvelous cargo during the war.

Most of the time this way of programming is used by unskilled or unexperienced programmers that copy-paste some code from somewhere else.

– adding unnecessary comments to self-explanatory code
– adding deletion code for objects that garbage would have collected automatically with no problem
– creating factories to build simple objects

Coding by exception/Expection handling
Instead of checking for some specific corner case values like null values, some people like to catch a NullPointerException and do some logic in the catch block. This way of coding is called expection handling because the exception is expected to happen.

Exceptions are invented to inform you of the fact that something really bad happened but they’re not meant to be thrown often. That’s why they are called ‘exceptions’. If they occur, please handle them carefully but never abuse them to execute some logic that could have been implemented with a simple if-else check.

Avoiding/swallowing exceptions
Referring to the previous antipattern, when an exception is thrown that means that something unexpected happened. The last thing you should do is swallow these exceptions instead of processing its useful information.

For example, if you have a method that should only return 1 object because you expect it be unique, perfoming a DB query that returns a list of results, checking if the list’s size equals 1 and then performing a query that can only return 1 unique result (if not an exception is thrown). If you’re implementing something like that, it means that it could be possible that the expected object is not unique which means that implementation differs from what the analysis says.

Inheritance hell
Inheritance should be handled with care. It’s very useful but you should only use it what it’s intended for. If the inheritance tree becomes to bloated, something is wrong. Do not write abstract classes for 1 specific case. Use composition instead. The strategy pattern can come in handy here.

For example if your JSF managed bean ‘EditUserManagedBean’ extends AbstractEditingManagedBean which extends AbstractSelectionManagedBean which extends AsbtractParentDetailManagedBean which extends AbstractManagedBean you should know that something is wrong and that there should be other ways to implement this behaviour 😉

Gold plating & Premature optimization
Some people like to enhance their code by continuing to work on it well past the point where the extra effort is adding some value instead of sticking to the requirements. The mistake made here is thinking the end user would be much more delighted to see the additional or enhanced features in the product, than what the user asked for or expected. The user might be disappointed in the results, and the extra effort by the developer might be futile. This process is referred to as gold plating.

Gold plating is related to premature optimization. Premature optimization refers to thinking about possible issues that could arise in the future but that are not the case at this moment. You should only think about what is asked and what is required, not about what eventually could be useful for future purposes. A frequent occuring premature optimization is the premature performance optimization. If there are no preformance issues at this moment, do not try to handle them, handle them when they happen.


Why webapps?

Sometimes I wonder why we are always writing web applications instead of desktop applications. It seems that web applications have a lot of advantages that desktop applications don’t have. But is this really true? Is it because of these so called advantages that most applications are web applications nowadays?

Actually, I don’t know why customers prefer these kind of apps, all I know is that it can be quite frustrating to write them from time to time. First of all you have to know the underlying protocols TCP, IP, HTTP, …) by heart. In fact that’s not really complex but a lot of web frameworks put their specific flow logic on top of that.

JSF for example, Sun’s current web application technology standard: if you do not know the JSF lifecycle by heart, you can spend a lot of hours on fixing stupid bugs which could have been avoided by knowing each part of the lifecycle very well. A common heard complaint is that JSF is just too complex, and I admit, it really is. And wait until you use it together with Spring Webflow, for example to add some extra scopes like page scope, flash scope, flow scope and conversation scope because request scope, session scope and application scope don’t meet your needs. Trying to access JSF’s FacesContext will fail because you need to use Webflow’s ContextHolder. Yet another example of leaky abstractions.

Browser incompatibility
Enough about complexity now, I think I made a point here. Another big disadvantage of web frameworks -maybe the biggest one- is the browser incompatibility. We need to support Internet Explorer (ouch) and firefox in most of the cases and if possible Chrome, Opera and Safari too. The biggest pain in the ass is IE6 -every developer knows that- and still a lot of people and companies use it as their default browser. It has a lot of security problems, doesn’t have tabs, it’s just outdated, but what I hate about it are all the css hacks you need to tackle specific IE6 problems wich can introduce problems in other browsers. Why do customers still ask to support this crappy piece of software? It’s 9 years old! Drop it please!

To solve the browser incompatibility issues a lot of frameworks are created with the aim of letting the programmer only focus on the requirements, the business, the use cases, the functionality, without the need to spend a lot of time and money on fixing these issues. Richfaces, GWT, Wicket, Vaadin, you name it. It’s a rarity but sometimes these frameworks don’t tackle all the browser incompatibility issues very well which means you have to solve it yourself and again, you need to know how the framework works and what it does. So as I said before, the problem of leaky abstractions can never be solved. They will always be there.

Web 2.0 issues
The fact that you sometimes need to fix bugs in those web application frameworks is not the main problem, the real problem is that those bugs are javaScript or css bugs. Ever tried to debug javaScript? Yes there are tools like Firebug but what if the bug does only occur in IE? Good luck! And the web 2.0 evolution makes it even worse, everyone wants Rich Internet Applications (RIA) because they want the rich experience of desktop applications… Why not just writing desktop applications? I guess that would be too easy 😉 Oh and then I’m not talking about the need to install a browser plugin to make these rich features available (Flex for example).

AJAX can do a lot, but again, it’s based on javaScript 😦 It’s not only difficult to debug, it’s a client side scripting language. And what I dislike about client side scripting languages is the absence of compile-time safety, it’s untestable and can not be refactored.
GWT’s aim is very good. Just write Java code which will be compiled to javaScript. You can test, debug and refactor it with ease and there’s compile-time safety.
Wicket drops the need to use and know custom tags (like jsp’s core tags, JSF’s default tags, richfaces tags) and lets you write plain HTML. So the markup is done with HTML while the business logic is done in Java code. Components are added to the view in Javacode too. This code is linked to the html page by means of wicket:id.
But Vaadin goes even further, it’s based on GWT which means that there’s no need to use HTML. LayoutManagers are used to do create complex layouts. IMHO the biggest advantage is that Vaadin has very clear documentation (Book of Vaadin) and provides commercial support, something a lot of companies really want and are willing to pay for.

Model View Controller
It seems that finally the strict MVC pattern is introduced into webapps , something I really missed (I don’t wanna think about Servlets: ‘HTML in Java code’ and plain JSP: ‘Java code in HTML pages’). So it’s a good evolution. The core evolution is bringing all features and richness of desktop applications to the web but still I wonder why we just cannot use desktop applications. It’s less complicated, you don’t need any plugins, you can use plain MVC, there’s no browser incompatility, it’s easy testable, dubuggable and refactorable, there’s compile-time safety, you can use events (loose coupling) you have all features available and you can set it up as a client-server application by means of Java Webstart.


It’s widely accepted that it’s a good idea to use standards in software applications. But is this really true?

Let’s take JPA (1.0) vs Hibernate as an example. A lot of people use Hibernate as JPA implementation in their project. The idea is that one can easily switch to another ORM framework that implements JPA.
That sounds as a very good pro but what is the chance that within that specific project another implementation than Hibernate will be used? Why would you want to change?

Standards are made to introduce a general way of working. If you know JPA you don’t have to learn specific implementations like Hibernate, iBATIS or TopLink . That’s true. But what if the standard doesn’t support everything that a specific implementation can do? Will you still use the standard even if you lose some features? In my opinion the answer to that question is definitely ‘no’!

Did you ever try to make use of delete-orphan with JPA? You just can’t do that for the simple reason that it’s not supported by JPA. Solution: use the Hibernate implementation instead.

Another example: Criteria API. You can use Hibernate’s Criteria API for retrieving entities from the DB. It’s not included in JPA. Same for Hibernate Validator. It’s not (yet) included in JPA. So we still use Hibernate specific code.

I know it’s included in JPA 2 but to be honest, how long will it take till a lot of projects will use JPA 2? It can take some time until a new version of some framework will be adopted by a lot of people. The point is that standards seem like a good idea but most of the time not enough features are available at the time the first stable version is released. They’re immature at the moment a lot of people start using them. Which means that the introduction of a lot of standards comes too late.

In my opinion standards can be useful in a long-term project subject to a lot of change like a framework or something similar. But in most of the fixed price software projects an immature standard can be contraproductive instead of generating a lot of added value.