Sunday, October 29, 2006

A 16 Months Iteration

I have finally been able to release a first alpha version of jinFORM, 16 months after the project started. The title is voluntarily provocative: it was not an iteration but a slow maturation!

Why did it take so long? As explained in jinFORM news, part of the time has been spent waiting for a presentation server able to render some much needed features of XForms 1.1. Initially, Chiba was targeted as the presentation server but testing and experiments have finally pushed the project to use Orbeon Presentation Server, which offers a more stable XHTML + JavaScript rendering, a better compliance to standards (XForms, XML Pipelines...) and the much needed XForms 1.1 features mentioned before.

So, what is jinFORM 0.1.0 worth? Not much for production: you can only fill simple forms with repeating sections, but without computation or logic. The only submission that is currently supported is for saving the XML instance built by the form behind the scene.

Then, was it worth the effort and why should anyone care about this project? Well, anyone with a slight interest in the intimates of Microsoft Infopath file format (aka XSN) should be interested to see how jinFORM transforms this proprietary form definition to XForms.

Because an XSN file is simply a CAB stuffed with XML, XSL and extra files, described with a documented manifest, groking its content is fairly easy. Doing anything with it is another thing. Take the XSL for view rendering (usually named view1.xsl) that is generated by Infopath. Because this XSL relies on implicit MSXML objects for supporting many extension function calls, jinFORM has to pre-chew it and implement similar functions in order for anything to work.

When designing this XSL, Microsoft, of course, had anything but elegance or portability in mind. It is cluttered with prescriptive commands like xsl:for-each, traps like testing for the existence of a function and using another one and oddities like using a function to retrieve the current document on which this XSL applies. Surprising approach from Microsoft? After they love functions and procedural programming: why would they embrace the template concept that is underlying XSL transformation?

There are still many things to add in jinFORM to make it really usable but it is a good first step. Foundations have been laid, now let's build on it!

Monday, October 16, 2006

Vive le ROI!

Please excuse my French but I could not resist the pun!

Agile proponents, including me, often use an improved return on investment (ROI) as an argument for avoiding traditional software development methodologies in favor of agility. The scope considered for this ROI usually concerns the financial investment made for the particular project and the result the stakeholders are expecting from it.

There is another ROI that I think is important to consider and that is also heavily impacted by the adoption of agile practices: the intellectual return on investment.

Indeed, developers involve a lot of themselves when working on a software project. The most obvious investment is the time spent at their desks but there is also a tremendous part of the job that is done after hours, outside of the office.

Ever zombie drove from work while mentally exploring the arcane of a new system's architecture? Ever had the light bulb that turns on while revisiting the latest written code under your shower? If yes, you probably see what I mean when I say that software development is pretty mind invasive.

Pecuniary compensation is often considered as the just compensation for this invasion: I pretend this is not enough. Money only buys time. The intellectual investment must be compensated by a specific ROI. What could be this specific ROI?

From my experience:
satisfaction in the quality of work
a sustainable elevated productivity and
an increased confidence in the system that is under construction
 
is a combination that forms a good intellectual ROI.
 
Knowing that this is the kind of conditions that agile methodologies can create, it can be used as an argument to sell them to programmers, who can sometimes get convinced of the benefits for their company (or the project stakeholders or their managers) but are not always convinced of the benefits for themselves.
 

Tuesday, October 03, 2006

The Roots of a Bias

A few weeks ago, Kubuntu released an upgrade that crashed the OS: this was a major goof and they promised they will never do it again. When my machine refused to boot after the upgrade, I frowned, grumbled, downgraded the faulty package and kept going until a new update restores the situation a few hours later.

Now, when I work on Microsoft Windows, I almost instantly go fuming and ballistic for the smallest glitch. Should the Explorer freeze for ages because I clicked on a network resource, I see red. Should I have to defragment the mess that has become my drive after a few months of work, there is smell of a burning martyr in the air.

Could I be somewhat biased against Windows? This would be a subject of shame because any prejudice is a reduction of reality that leads to unfair behavior. Yuck! Nothing to be proud of...

What could be the roots of such a bias? I do not particularly care about Windows supremacy on the desktop computers (except that such a global uniformity is a security problem), nor about the personal fortune of such Microsoft big hat. In fact, Windows XP Professional is probably the best Microsoft operating system I have ever used, so where is this wrath coming from?

Doing a little introspection and exploring the depths of my psyche, I think I have found out the event that triggered this anger: it was in the mid-90s so this is surely a case of unfinished business!

My first application that went into production was a modem hub for the Belgian branches of a pharmaceutical distributor. The application was written in C and, the most important factor, developed and executed on OS/2. Coming from Atari TOS, I really fell in love with OS/2!

Then I finished school and started to work in the professional world, dub it, the world of Windows for Workgroups 3.11. Coming from a world of sessions, processes and threads, WfW seemed to me like a castle of cards waiting for the faintest breath of wind to fall down in pieces. And it was. Rebooting was a big part of a developer's activity of this time.

When Windows 95 started to be announced, I was certain the industry will make the right decision based on the misery of WfW and move to OS/2 Warp. Yes, I was so naive to believe that technical soundness and robustness would help reverting the trend towards Windows to what I considered a better professional operating system.

History proved me deeply wrong and left me frustrated for the many years it took Microsoft to build an operating system as stable and usable as OS/2. I think this old frustration that has turned into bitterness is the root of my bias. I need to work on it and restore pacified relationships with Windows. And I will keep using Kubuntu as my main operating system, just in case... A relapse is always possible!