From crossover comes breakthrough

One of the biggest sins in software development industry is "knowledge hubris". Software engineers are "natural born specialists" (not all of them, but I guess that a vast majority could fit under this definition), people who have a deep knowledge of some technical aspects and have a tendency to "drill down" for a deeper knowledge of a specific topic. Experience helps in defining what's the better balance for the situation, enabling you to make decision based on a superficial knowledge (and maybe some expert's advice) instead of studying the whole stuff before taking any decision step. Given that software engineering is a profession that needs continuous refreshment of the acquired knowledge, and that the field is constantly enlarging, reading more books in a shorter time is probably the only viable option.

Many of us think this is enough.

I had a couple of loads delivered by Amazon in the last two weeks. So I have fresher books about Software Architecture, Project Management, Software Development Process, Software Security, Grails, Groovy, Ruby, SAP and so on. I looked at the pile and felt somewhat disappointed: "looks like I am merely changing the perspective on the same stuff", or maybe I become too much influenced by Amazon's recommendations. While browsing some books bibliography (in a childish attempt to score more than 50% books read) I realized that probably the more interesting perspective could come from the books I've never heard of. Agile movement brought a lot of external influences into the software development field: SCRUM introduced elements from process engineering (that were quite obvious for process engineers, if only anybody thought about asking…), Cockburn and DeMarco and Lister analyzed deeply the human factor which is predominant in software development, both in terms of self organization and team dynamics, bringing anthropology, communication science and psychology into play. After all, in software development the rough material is people, but most of us focus primarily on technology forgetting that, unlike technologies, there is no obsolescence in people.

Tags: Agile, Software Development

Videogames for the Development Team - Updated

This is just a slightly different version of an old post...

I’ve got this stuff bouncing in my head, right after reading this Joel Spolsky’s post trilogy about project management. You’ll realize that my head is pretty foggy lately…

The average developers attitude is best expressed by 1st person shooters, such as Quake. A developer has a dirty job to complete, and has not to be afraid to dig into a bloodbath to finish it. Collaborative teamwork is encouraged for better result, but in the end it’s you against the enemy.

Team leader’s attitude is best trained by strategy games such as Warcraft, or similar. You organize the teams, assign task, and make characters’ experience evolve, so they can perform more complex task. Controlling parallel activities is just the nature of the game.

A project manager perspective is almost the same that a game like SimCity can give. You don’t control characters anymore, but create conditions for them to do stuff, such as provide houses, roads, and so on. And watch interesting happen: if your city is a nice place to be, then people will be glad to join your city, otherwise they will leave.

You might be tempted to choose a different approach, Sims-like, but as Joel’s article explains pretty well, it’s just pretty fine grained to work effectively (to be honest, I always have flies over the garbage can...).

The perfect game for the DBA is Dungeon Keeper, well... you might guess that I am not a DBA, but the whole game is defined in an access provider perspective.

Ok, somebody might be curious about my favourite game… well, I’ve always been a Civilization’s fan, from version 1. But the one and only that really pleased my ego was Populous II, the moments I could send a tidal wave and watch poor innocent human beings drowning in a tidal wave… Does this mean something?

Tags: Software Development, Agile, Project Management

The eternal question

It's pretty hard to claim you're a professional, when the goal of the profession itself isn't clearly defined. I bumped into this interesting post on Ted Neward's blog, which tells a lot both about the Software Architect job and the pitfalls of the recruiting process.

Tags: Software architecture, recruiting

Enabling factors for Domain Driven Design

There was a nice follow up to an Eric Evans interview on InfoQ, which led to this interesting post by Chris Beams. I totally agree with Chris: when I first read about Domain Driven Design it sounded a lot like the good old OOP that I learned in the university (shall we call it GOOOP?), just a little bit more pragmatic and organized. However, J2EE forced developers to drop that pure OOP model (but I still suspect that pure OOP is not for the masses…) in favor of a heavy procedural model disguised as a J2EE architecture.

In the last years technologies such as Spring and Hibernate became mainstream, laying the ground for lighter architectures. More specifically Spring brought the POJO model to the services part of the architecture, while Hibernate enabled POJO representation for the Domain Model. Freed from many of the constraints of the J2EE platform, architects may now aim to the best possible representation of the model, which currently is represented by DDD.

Tags: DDD, Spring, Hibernate, Software Architecture

A nice puzzle for the ubiquitous language

Multi Lingual Domain

During the Domain Driven Design seminar I had the pleasure to attend in JAOO, a question arose from one of the participants, something like: "we have a domain model which is expressed in Spanish, but then the company bought an Italian one, and then the model had to be extended to the Italian scenario (which is obviously slightly different), and then to a British one…". The main problem is that a model should be expressed in a language. Countries like United States, Great Britain, Canada, India etc. are privileged because they seldom have to choose the language in which the model has to be expressed.

Our usual scenario instead is a mixture of English and Italian; getNome() and getCognome() are typical examples of this language mismatch. You can put some effort to rule out the situation, declaring an "all Italian" rule (which doesn't necessarily mean spaghetti-code) or an "all English", but don't expect a 100% compliance to it: you'll always end up with a mess. Technical terms (especially in banking and insurance industry) are scary enough in Italian so no developer would easily stick to an English definition of the term, but most of the analysts would agree with them (or use them as an excuse). Anyway, given that the domain model must be shared with the domain experts, most of the times you simply have no choice.

Defining the core domain

Given that language issue in non-English speaking countries is already an issue in a single nation scenario, how could the initial puzzle be solved? There is no real answer. Basically it depends a lot on the team special skills: if you have people with cross competencies, you probably could leverage this knowledge, to expand the core domain, including multi-lingual scenarios. If those people are not there to stay, you could be anyway putting the core domain at risk of being unmantainable.

Given that national domains will be subject to EU and national regulations we have also a two-level driver for change. EU regulations would push for a shared domain, while national one will call for separate ones. Assuming that you can't really predict where the change will happen (but EU regulations leave you more time to think than national ones) you are left with the basic question: "how much of the model is really shared?" the answer is going to be "a small portion" now but probably going to increase as long as a deeper knowledge of the system is shared. At the end of the day, the really tricky thing to do, is to evaluate the costs of sharing information versus the costs of maintaining duplicated code. One can invest on knowledge sharing (Wikis, mailing lists and so on) but I guess that if the developers don't "cross the boundaries" spontaneously to attack the duplicated component (or to translate it to English), forcing them to do so will be probably more expensive than keeping separate domains.

Language specific wrappers

If shared components are to be used, then language will be an issue again. With simple terms English would be fine. With more complex ones, then code readability might suffer. A possibility is to define language-dependent wrappers, whose only purpose is to embellish the original component, providing access to keywords in the language of the local domain. I personally prefer to use English terms and to write a multi-lingual javadoc (but alignment is risky) or wiki documentation. But in some circumstances this might help.

Tags: JAOO2007, DDD, Software development

The neglected diagram

During the last JAOO conference, a couple of speakers (Eric Evans and James R. Coplien) eventually dropped a quote about UML experts forgetting to use the UML Object Diagram. It might have been a coincidence, but since I sometimes teach UML classes (and I normally tend to get through the Object Diagram quite quickly) this triggered some reflection "Am I doing something wrong?"-style.

It turned out that my slides were right – they were saying something like "this diagram us useful for explanation purposes" – but during classes the pitch tended to switch towards a more documentation-oriented version of UML. Many of the audiences were programmers or designers, interested in reading UML or in using UML tools, so the approach made sense. Still the main message was missing.

UML is a powerful communication tool. By establishing a standard, the three amigos opened the way to standard CASE tools, and a common language between software professionals. But the real point is that UML is a communication tool, and was designed to be flexible, to be used in different contexts. Designing a system in a CASE, or provide a non-ambiguous documentation for the development team, or using UML to generate code from a diagram is just one side of the medal. To design a successful application, requirement gathering and analysis are more crucial. In this phase UML can come in handy, but only as long as the all stakeholders are able to actively participate in the discussion.

Downsizing UML

To be successful in this information crunching phase, it's often better to stick on the minimal amount of UML that can be understood by the participants. People involved in this phase need to be aware of what's happening, and – most of all – creatively contribute to the result. Surprisingly the Object Diagram is one of the easiest to be understood by non software people, while Class Diagram, even simplified, still looks sometimes suspect to some.

Domain Specific Notation

The main goal is sharing the information. Forcing people to learn a simplified version of our language is a type of white-man-between-natives attitude. UML is definitely not "the message" but just a tool. If there's already a language in place, it's probably better to learn this one instead of forcing all the business people to learn UML. If there is no language in place, but UML simply doesn't quite fit the job, we can also define our Domain Specific Notation, if this is more easily understood than UML, and use it for a defined purpose.

Defining to what extent this extra language should be used is heavily dependent on the project context: an offshore development team will probably still prefer UML, because is standard and could have a more formal meaning. An in-house team, meeting the business people on a regular basis could find more efficient to grasp the information from the source in the specific notation.

Tags: OOA, UML, JAOO2007

Brief summary from JAOO 2007

Last year was my first time at JAOO, and I ended up doing a short buzzword-based review of the overall conference. This year I had slightly different feelings about it, but I think that keeping the same format will still be valuable.

• TDD: Lots of attention on the topic. Robert C. Martin held the opening keynote and a dedicated tutorial. An interesting – and controversial – issue popped out during James R. Coplien speech about "frictions" between a sound architecture and a full TDD approach.
  
• Web 2.0: whatever it means, there was a lot of hype about it. AJAX, interactivity, Ruby, Grails, and in general the possibilities of development where the world is your stage are definitely interesting, and we're still far from seeing the final destination. Really hot topic.
  
• Ruby: one year after, what looked a promising language really hit the mainstream. Most of the attendants were still on Java, but many of those were having a Ruby project going on. And they all were happy. There are still a few naïve elements, but they don't change the overall picture of a really successful language.
  
• Erlang: the language has been designed for parallel processing, and has truly brilliant ideas in it. Google bases its computational power on MapReduce, but also a lot of Social Software (more than I imagined) is putting strong effort on parallel computation as well.
  
• SCRUM: SCRUM trainings were completely sold out. SCRUM methodology itself deserved a whole – crowded – track.
  
• Agility: while only a few speeches explicitly talked about agile, still it is an interesting issue. Developers listened to other's developers trying to measure how agile they were an how they could improve. It's definitely a path and not a label, so talking about it still matters.
  
• Domain Driven Design and Intentional Software: from different angles they both try to tackle the cultural mismatch between Domain Expert and Domain Modelers. Eric Evans by presenting techniques and a clean conceptualization of the steps needed to have the modelers successfully interact with the experts. Charles Simonyi's Intentional Software takes the other way round, by presenting tools that allows domain expert to express the software in their own Domain Specific Language, sort of MDA without all of those meta- words. Both approaches have strengths and weaknesses: I am a DDD fan, but I'll keep focused on both.
  
• SOA: this acronym looked dead and buried. There was a SOA track in 2006, and this year only a few mentioned it. I have the feelings that SOA was – and still is – a great idea, but completely messed up by big vendors (or big buyers). Sort of what happened to UML some time ago…
  
• Software Architecture: I followed part of the track. I ended up having a broader vision of the overall possibilities (I've really been stuck with JEE for too long).
  
• Ethics: a lot of speeches focused on ethical aspects of the software development process. "The Pragmatic Programmer" was the reference book of the whole conference, giving a somewhat introspective feeling. Maybe we didn't learn that much about the new cool stuff, as much as what we've learnt about who we are and what our job is.
  
• Semantic Web: unfortunately it wasn't even mentioned.
  

After all, I was a little less excited than the year before, maybe because I missed the surprise effect, and also because some speeches were resounding the ones of the year before. There were no astonishing news on the stage, but we were not looking for the new messiah, so I guess this is pretty good.

Tags: JAOO2007, Software Development