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

Archive for the ‘Programming’ Category

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:

Advertisements

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