Sunday, July 09, 2006

New challenges for the J2EE web developer


Recent technologies such as Java Server Faces and AJAX are causing a positive earthquake in the Java web technologies arena. As far as I can see, the first victim is the Struts framework: just an year ago it was the de-facto standard for a generic J2EE web application and was backed by a good support my many different IDEs, now it looks like nobody is starting a Struts project any more.

The leading factor for establishing a prevalence of JSF over Struts has been the pursuit of productivity, which was the weak point of many web application frameworks. Overall team efficiency paid a double fee to open source standards:
  • high development speed were achievable after a long training: the stack of competencies necessary to a generic web developer was definitely too high and fragmented (Servlets, Java Server Pages, tag libraries, HTTP, HTML, MVC and the framework in use).

  • Integration with IDEs has never been good: first it comes the framework and then comes some form of support from the IDE, but far from being sufficient. So the standard situation is to have the IDE perform some sort of trivial task for you and then start digging in runtime case mismatch error in some XML file (I guess you know what I mean)

JSF nowadays starts straight from the IDE offering a developer a way to efficiently design web application in a way that has been forgotten for a long time (most developers I know find still more productive to manually edit web pages or tags instead of delegating it to the IDE). After a couple of projects, our experience shows that JSF impacts positively on development speed, so …goodbye Struts.

Re-enter usability
In the meanwhile, components are evolving, exploiting possibilities allowed by the AJAX technology. A new level of interactivity is possible for the web platform where it has been neglected for years (with some niche exceptions like ActiveX, Flash etc.), particularly in the enterprise software field, where you don’t have to attract users to your software (“I pay my employees to w-o-r-k, not to have a satisfactory user experience”).

Now the situation is different: in this scenario a web software can be comparable to a fat client in term of interactivity and usability. The problem is that web developers have been working without these possibilities for years (forced to choose only between combos and radio buttons) forgetting what an easy-to-use user interface should be. The move to a new paradigm has been taken only on the technology side, but doing “the same old stuff” with a new framework is only half of the job: the other half is using the new tools to produce better software.

The following months will tell if this will be achieved by improving developer’s awareness of man-machine interaction mechanism or having software analysts provide a more detailed level of specifications in the early stages of the project.

Tags: , , ,

Tuesday, July 04, 2006

Java Conference Afterthoughts


It took me quite a few time to recover from the Italian Java Conference. I was involved in a 3 hour seminar and a 45 minutes speech. Seminar’s title was “migrating applications from Delphi to Java”, while the short speech one was “Migrating development teams from Delphi to SUN Java Studio Creator”. The night before I met with Filippo Bosi and Giuseppe Madaffari, my co-speakers and with Mokabyte’s egghead Giovanni Puliti, to finalize the presentations. As expected, I went to sleep not before 3.00am. And woke up angry and disappointed 4 hours later.

Not so many people attended the seminar, probably because
  • you had to pay SUN 200€ for that

  • James Gosling was speaking in another conference hall
We had some troubles configuring my laptop with the projector, this made us lose some time which I tried to recover at the end… so we finished late. But then I was the first speaker of the afternoon, guess what? No lunch (I hate that). The smaller speech was unpredictably stuffed up with people, probably waiting for the following speech about XP and TDD, I suppose. I regretted shaping the slides in a too serious way for this one, while I had more funnier slides in our “private” performance. As a result the speech sounded a bit more boring than I wanted, but I really was too hungry and tired to add an extra verve to the speech.

After the speech (and the long awaited lunch) we hanged around the Mokabyte stand, where I bumped into Filippo Diotalevi, that was a speaker on the following day. He has been doing a lot of cool things since I knew him in BPM… chapeau!

Tags: ,

Saturday, June 24, 2006

Italian Java Conference

I'll be one of the speakers at the italian Java Conference in Milan next tuesday. Both the events (a seminar and a speech) focus on how to move developers from Delphi to Java, from an organizational and architectural point of view.

By the way, this is mainly an excuse to experiment Microformats in my blog.


June 27, 2006 - 10:00
-

13:00

-
Java Conference Seminar
- at

Milano


Migrare Applicazioni da Delphi a Java




By the way, the result of the experiment was that, after installing the Greasemonkey Firefox plugin I could see an "Add to calendar" icon on the page. Clicking on it resulted in a .ics file ready to be imported by MS Outlook. Still Outlook failed to import it...

Massive Learning Patterns


A recent research on learning patterns on humans and primates lead to interesting results: findings were that while young primates basically emulate the parent’s behaviour, human babies tend instead to imitate parents behaviour uncritically. Put in another way, they simply do what they see a parent is doing. One example was that if the mother was switching the light off with the forehead, babies were basically doing the same things, while young primates were acting in a more conscious way.

It might look like primates are smarter, but the evolutionary answer was the opposite: imitation is the fastest way to learn a series of complex behaviours in a short time, especially if you’re still too young to understand the reasons. Incidentally, learning by imitation, without asking questions is the same learning pattern adopted by armies all over the world, and they share the same goal: a lot of coordinated behaviours to be learned in a short time.

From primates to developers
Recently, we shifted some developers from Struts to Java Server Faces in the presentation layer of a couple of projects. Newer RAD-oriented IDEs (such as Java Studio Creator and JDeveloper) should have had a positive impact on productivity, after the initial phase. Still some of the developers claimed to be stuck in the learning phase, while others who just skipped the “I-have-to-learn-the-framework” phase and went straight to the code, copying some code snippets and adapting them to the project needs, performed significantly better both in short and long term.

Mere imitation, or code pasting, isn’t the whole story: babies imitate parents who have god-like authority on them, so their behaviour is accepted by trust before it can be understood. Similarly developers look for trusted sources of information to extract some proven solution (and the ability to dig the net for it is becoming a distinguishing factor among developers). In a closed context the perfect solution should be a robust prototype, providing a vertical example of a functionality.

As I experienced while coordinating offshore teams, a good prototype or an architectural skeleton removes whole families of problems, simply by providing a source for cut & paste: “if it comes from the architect it can’t be wrong”. Well… it obviously can be. But even a wrong repeated pattern is better than 20 differently wrong patterns spread all through the application.

Tags: ,

Friday, June 16, 2006

Strive for progress observability


One of the key features of iterative development processes is the ability to make the work in progress observable. Clearly, different roles have different needs, and different level of observability are required: for a contractor milestones are important on the agreed deadline and day-by-day evolution shouldn’t matter, a team leader should instead look also for daily changes to better guess directions every developer is moving on.

During “pure development” phase, I normally ask my team to commit their job on the CVS or Subversion repository as soon as possible, at least on a daily basis, but I realized that this might sound odd to some of them. Personally, I can’t find any good reason (in this phase, at least) not to commit any code which is slightly better than the previous version. If the code won’t compile or breaks some test, then it’s a good choice not to share it, but that’s the only reason. By postponing a commit you’re just putting a slightly risky area (merging and integration) a bit closer to the deadline, giving a minor trouble a chance to become bigger.

Savage time
During early stages, I sometimes try to enforce “competitive access” to shared resources: if more than one developer is accessing the same file, then the first one to commit pays a smaller integration burden. This might sound pretty naïve (and I’d never use this style for the whole development process…) but it’s normally part of a “shock therapy” to rapidly establish team mechanics, if there are new team members or developers still stuck with MS SourceSafe bad habits. Once everybody is confident they can get along with the versioning policy, the team can switch to a less aggressive style.

Don’t forget that even if you switch to a more coordinated policy, you might still need the practice for emergency recovery, production bugs, night fix and all of those situation which can become nightmares if you add complexity on top of a mess. If you are skilled for troubled water, then you’re less likely to get panicked.

Tags: , ,

Sunday, June 11, 2006

Why Object Oriented Designers should rule the world


I was drowning into the abyss of the Italian bureaucracy in the last few days, going from an office to another one to fetch the papers needed to ask for another paper. A notary public asked me to get papers from the local registry office. The data was on paper, so the officer wrote an official document with a typing machine (a mechanical one). Of course there was something wrong in it, but since it was the referring to the notary’s county of the original document author and the notary was the same that asked me for the document (in other words, he asked me to get something he wrote) I hope this is a minor mistake…

The second paper (same papers I already had but I needed a fresher timestamp on it) forced me to go to another municipal office, where they told me
  • I had to go to the land registry office (is cadastre the right word?) asking for some maps

  • I had to pay €100,00 at a post office

  • I had to buy two special stamps worth €14,62 each
I searched in the internet yellow pages, for the land registry office address, but I got the wrong one. I phoned to a yellow pages service and I got almost the right one. Once I got in, the place looked like some kind of transit station on the way to hell: dozens of people camping in a large hall waiting their number. Luckily I had something simple to do and my queue was relatively fast. Of course I had to pay €35,00 for the maps I asked (just reading what was needed to complete the request for the other office (are you feeling lost? Me too).

Then I went to the post office to pay the €100,00 and buy the stamps. Obviously, there were no stamps of that size, so the lady started trying various combinations of different stamps (in a variant of the knapsack problem) to achieve the exact sum of €14,62. Welcome to the third millennium!

I then brought the maps back to the first office and they told me most of them were not needed for my type of request (grrr), so they just took one. I am now waiting the phone call of another officer telling me some papers are missing.

…So what?

Ok, I might be a sort of a strange guy but I can’t help it: every time I go to a public office I start thinking about it in terms of OO modelling. It just doesn’t make sense to me that all of a transaction complexity is put on the user shoulders. It’s exactly the same problem you can face with badly designed interfaces in server code.
A server class (as the name states) is supposed to serve multiple clients. A good design decision is to hide complexity behind the server class API, so that you can write simpler clients. Since clients are written in different context and times, you pay once on complexity on the server side and save every time somebody writes client software.
Bureaucracy is normally doing the opposite: to achieve thin processes on the server side (enabling eternal coffee breaks), officers are moving the burden of complexity on the users: forcing citizens to locate external services, pay (in the silliest possible ways).

The more I look at it the more it doesn’t look like a way to save time at all: if a frequent connection has to be established between two separate offices, then using the citizen (which is 90% of the times doing this thing for the first time) is the most inefficient way of all! Citizens have to be trained to go there and ask that and that, and this is a repeated waste, citizens are not experts so they could make more mistakes than trained officers on a standard procedure, so the process results more error prone.

Can anybody do something about it? Unfortunately this is pretty hard, because requires somebody with a pretty large scope, authority, and completeness of vision: a dictator? An emperor? An alien from a distant planet? Since crossing organizational borders or ruling the empty spaces is one of the most difficult management activities, I am pretty pessimistic about that.

Test Driven Bureaucracy

In the OO world, the best way to achieve a simple API is to develop in a test-first style. This way the developer thinks first from the client perspective (resulting in low complexity of the desired process interface, mostly a money for paper bargain), and then implements the service, keeping most of the complexity behind the server interface.
I just wonder how a similar approach might perform if applied to bureaucracy, I guess we’ll have a lot of surprises (in Italy whole institutions are totally useless) by crossing a test driven methodology with a strong OO-like role/responsibility analysis. As the picture shows, even if pessimistic, I haven’t lost all my hopes.



Tags: , ,