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

Archive for the ‘Software Development’ Category

Vaadin, Maven and Spring


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
-DarchetypeGroupId=com.vaadin
-DarchetypeArtifactId=vaadin-archetype-clean
-DarchetypeVersion=LATEST
-DgroupId=your.company
-DartifactId=project-name
-Dversion=1.0
-Dpackaging=war

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!

Advertisements

How to make Scrum fail


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 …

References:

Programming antipatterns


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 CollectionUtils.select(…) 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.

Examples:
– 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.

References:
http://en.wikipedia.org/wiki/Anti-pattern#Programming_anti-patterns

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?

Complexity
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.

References:

Standards: Pros and cons


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.

Focus on quality


Why do a lot of people say that testing is a waste of time? Because it takes time to write software tests? Hmm looks kinda strange don’t you think?

Software analysis, design, programming, bugfixing,… are all time consuming activities that are part of the application development process and it’s accepted that those activities take a lot of time so no one ever thinks about skipping them. So why would people skip testing? Because they like bugs? Because they hate visibility? Because they like bad quality?
Oh now I remember, because tests are obsolete and cost time and money. And we’re getting out of time or out of budget so we skip tests. Big mistake!

Tests are also part of the development process! Why? For many reasons!

  • Tests create visibility and a safety net. By writing tests you can pinpoint bugs as soon as possible. And you can fix them as soon as possible.
  • Tests reduce the amount of bugs in new and existing features. Because we see bugs by writing tests, we can fix them and reduce the amount of bugs.
  • Tests allow refactoring. Because there’s a safety net, you can refactor without fear. Tests will be broken if the refactoring failed.
  • Tests reduce the cost of change. Because you see and fix bugs as soon as possible, you don’t introduce extremely long bugfixing phases. The longer the bugfixing phase, the more money that will be spent to fix the bugs. The graph below explains everything.

Most bugs are introduced in the coding phase and this phase is the cheapest one to repair bugs in. So we can conlude that quality is what we should focus on. You can do this by writing enough tests but there are other ways to do it:

  • Don’t overdesign. Of course you should think about the design first but don’t program with the idea that maybe this feature could be useful. A  software application is not meant to exist of several selfmade subframeworks that contain unused features. Thinking about those features and writing them is a waste of time in fact.
  • Design as late as possible. If you write some code, do not think about reuseablity at that moment. Extract the code at the moment you wrote the same code twice.
  • Refactor as much as possible. When time’s ready, refactor code to keep it clear, readable and maintainable. Code duplication is a bad practice.
  • Use tools to track possible bugs. Findbugs and PMD are very useful.
  • Make use of continuous integration. CI will tell you that something will be broken, so if CI is green, you don’t have to bother about it.
  • Do code reviews of each others code. Every developer has an other point of view and will detect bugs and bad coding practices that you didn’t notice because it’s your code.

So if you don’t like to focus on quality but on costs, remember that by focusing on costs, quality won’t improve. No, quality will even be worse, meaning that it will even be more expensive to guarantuee a product without major bugs and thus costs will raise by fixing a lot of bugs at the end of development! If you focus on quality from the beginning, costs will be reduced and quality will even get better.

An easy formula can illustrate this:

So please please if you’re thinking about dropping tests to save money, think again! Focusing on quality is the only way to reduce costs.

References:

http://onjava.com/pub/a/onjava/2003/04/02/javaxpckbk.html

http://blogs.windriver.com/graham/2010/01/service-and-repair-is-not-the-only-option.html

http://en.wikipedia.org/wiki/W._Edwards_Deming