We can do better than this... Reloaded

In the last Italian Agile Day I delivered an open presentation called "Possiamo fare di meglio" (this post's title is just the translation), where I raised some questions about the way we develop software. I then tried to summarize some of the things that emerged in the discussion here, but there are still many things that are bouncing in my head...

One thing that really disappoints me is the low quality of many software applications I have to deal with in my everyday life. Some days I really feel like I am surrounded by crap. Just to make it clear what I am talking about: here is an excerpt of what a home banking service is asking me every single operation I do.

Choose the desired account:

My Company Account (all the accounts)

And every time I think: "It's one account, it's just one account, it's always been just one account, so why on Earth you keep asking me this question every time! Couldn't you just take me straight to the account...".

Some days I just feel like surrender, some other I see how some application are doing a fantastic job, on platforms like iPhone or on the web, and I feel like there's still some hope for us.

There is still a lot to do

Despite all of our efforts, to introduce TDD and continuous integration, velocity based estimations and the like. There's a lot to do in other fields as well. Let me say it in another way: many companies are looking towards agile methodologies as a way to improve their development processes, in order to deliver software on time and on budget.

Doesn't sound that bad isn't it?

It does. It doesn't mention the quality of the product. ...Oh, yes, we forgot, we need also tests to reduce our defect ratio. Tests are good, software quality is good, but still doesn't address the whole point. We should deliver better products. Emphasis on the process itself would satisfy the managers' ancient need for schedules and predictable outcome, allowing teams to produce crap more efficiently, but would not produce better products unless some key points are specifically addressed.

The most neglected areas at the moment - at least from my point of observation - are:

1. user's involvment,
2. understanding the domain complexity,
3. lack of an overall perspective,
4. inefficient learning during the product development lifecycle.

The items are not completely separated, in fact they're slightly overlapping, but I think these are the areas where as software developers we can (and must) improve a lot.

In the next posts I'll dig deeper in these topics.

Why CRUD use cases are intrinsically evil

When performing analysis for a new system, many people find useful to shrink several use cases in a single one, and tagging it with the CRUD stereotype. This choice has a clear advantage in terms of readability of the use case diagram, while the stereotype (often associated with a different color) just triggers a multiplication factor when defining estimates for development time.

Readability and estimates are just a small part of the game when it comes to actually design the overall system. A Use Case is intended not only to be a measurement of the overall complexity of the system, but also a useful tool to capture the real goal (for a good exploration on the matter, please read Alistair Cockburn’s Writing Effective Use Cases) of the different parties involved in the use case. Just a simple order-invoice combination cannot be well represented by two CRUDs due to the many interactions possible between the two data types.

A system made up by a pile of CRUD usually ends up in a data-centric application, where part of the complexity of the interaction between different data types becomes a burden on the user, instead of a system’s responsibility. A user-focused use case (or an XP-like user story) should instead capture the flow of the interactions between different data types. If you’re not modeling what lies beneath a CRUD and another one, you’ll simply have to face it later on in terms of cluttered implementation or a not-so-usable application.

Separating use cases concerns
In nontrivial systems I found useful to separate the different concerns by defining two layers of use cases:

• Business Level use cases focus on the user interaction with the system, they provide a detailed description of the user’s goal as well as other party’s, and span across multiple data types;


• Implementation Level use cases focus instead on the artifacts needed to realize the use case, such as web pages, persistence methods, complex data manipulation and so on, generally tied to one or few data types.

The first layer depends on the second one for the implementation, and in trivial cases there is no need to separate them.

Testing the resulting system
A not-so-small difference in the two styles is that we can choose which use case layer is best suited to provide the specifications for building our test suite: at the business case level we can probably test more with less effort, and catch some awkward combination of data that tests based on the implementation level couldn’t catch. Of course the better combination is to define (unit) tests for the implementation level to be used as bricks for the business level tests.

If acceptance test are to be run by a real user, they’ll probably follow some path defined in business level use cases, instead of merely trying to add or modify some data and see what happens.

Enter the domain model
Such a modeling style, prepares the background for a domain model type of system (as opposed to the data-centric one). If we are to model something which lies in the correlation between two or more different data types, the best place to define it is in the domain model, be it in the component behavior or in the use case controller class. The default choice for data centric systems I’ve seen so far, has always been presentation layer… :-(

A significant exception
Apart from very simple systems, data centric applications (and thus CRUD-like use case modeling) are the best choice when the overall business processes aren’t completely defined, so instead of having a complex, but incomplete, system driving the user (possibly to a dead end) it’s probably better to have the expert users in control, and let them the possibility to tweak the system as they need (a possibility greatly appreciated in call centers, for example). However, this situation it’s not a great symptom of the whole organization’s health (but might be the driving force in a startup, for example), more often it is a sign of a poorly done analysis.


Tags: OOA, OOD, Usability

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: J2EE, Usability, JSF, Ajax