Keeping technology standing still

Recalling projects I’ve seen, I realized that there was a strong correlation between the technological landscape of the project and the actual number of developers leaving the project (and the company). The more the technology was fixed, the more it became boring and frustrating for developers. Software developers are not normal workers, but strange animals that actually like coding, and they can do a hell of a job as long as they have some fun out of it. Tom deMarco’s Peopleware makes a perfect portrait of the software developer and of his peculiar needs.

Trading fun for productivity?
Still, it looked like sort of a bargain: one can choose to keep the technology fixed, to pay less in training and refactoring while increasing the risk of an early departure from the project. Unfortunately, as long as the project continues, the chances of this event steadily increase so you must carefully consider this option. What is somehow hidden is that developers are not at all the same, and the one who is more prone to get bored might be just the most curious one, the most brilliant or the most passionate. So if you’re assuming that one over five of your developers might be leaving, chances are high that you’re losing 30% of the workforce instead.

The other hidden part of the bargain is that if somebody leaves in the middle, you have to pay a productivity price in training time as well. If the base technology is outdated, or – worse – proprietary, learning cost for newcomers will increase over time.

Updating the landscape
Ok, not all projects are intended to be “eternally open” (so this thought can’t be applied everywhere), but if you have a long living project and you’re trying to save money by stopping the evolution you are actually creating a huge cost area in the future that will materialize in the form of “the big refactoring mayhem” or of “the application that can’t be changed”. Maybe it won’t be your personal problem as a PM but in both ways you end up wasting money in the long term.

Tags: Agile, Project Management

RAD development and domain modeling

Java web programming suffered bad development performances in the last years, mainly related to the complexity of the presentation layer. As a coordinator for J2EE learning classes, I found often embarrassing to define a competence stack for the web programmers which included Java, J2EE concepts such as Servlets and JSPs, a bit of XML and HTML (and HTTP of course) some JavaScript and a MVC (so some Design Pattern concepts got in as well) framework, normally Struts. Given that in another language, such as Delphi or Visual Basic, programming for the presentation layer is made ultra-simple, this pile of necessary knowledge really looked scary.

Moving from Struts to JSF

Although the JSF approach is far from being perfect, it’s just a great leap forward compared to the old mainstream Struts:

- at the architectural level, JSF removed the need for a layer, making it possible for the presentation layer to manage model objects instead of dealing with extra-flat ActionForm classes. In many cases, inability to handle data which was not a String led to an extra layer of DTOs to simply handle transportation and type translation between the web layer and the business layer (pretty boring stuff indeed)

- in the IDE, designing a web user interface has become simpler and more productive since JSF support is built-in and not only an a not-so-well-designed-plugin. Many components are designed on top of basic layers (Servlets and JSPs), so you normally shouldn’t bother about them.

Data Aware components

JSF toolkits offer also the possibility to use data-aware components in a web oriented paradigm. This way you can expose a RowSet directly on the web page and rely on the data-aware component for synchronizing page data with the underlying database. It’s definitely not OOP but it might come in handy in many cases.

The main message is probably intended for the average orphan Delphi programmer: “your paradigm works in java as well, and on the web too!”.

Everybody happy?

So, looks like the Java web developer is now given two tools when constructing a simple web application. Anyway my feeling is that data-aware components are just a bad idea for a developer with a J2EE background.

1) data-aware component are popular in not-so-OOP languages (ok, languages jave OO capabilities, but I’ve never seen a VB programmer define a domain model), in such a scenario your application is just a collection of CRUDs (create-read-update-delete) and this is not exactly a great idea.

2) You have to define a place to put your business logic anyway, and since JSF allows you to use POJOs …why not use the POJOs? If you prefer to put all of your domain logic in the presentation layer you’re free to do it, but I have to warn… you’re probably going to hurt yourself.

3) Data-aware components fits well in closed client-server architectures. Here the architecture is not so close, we’re already on the web, so the chances for exposing a service on another channel (be it a web service, or a palm interface) are far higher than before.

4) Tools like Hibernate, or Spring really make data-aware component less interesting. Off-the-shelf ORM tools weren’t that popular in the client-server days, but now they really are part of the scenario. It was different were EJBs were hype, cause “domain modelling” really sounded like “business layer”, and this sounded like “EJB” (or worse: “entity beans”) meaning finally “heavyweight mess”.

So, even if some debate is still going on, I really think that data-aware component aren’t that interesting for somebody with a java background. They might come in handy for newcomers to the java platform that can postpone learning some heavy topic in the J2EE landscape for a while, but it really sounds like a short-term choice.

Tags: JSF, OOD, RAD