The case about changing requirements

I've received a deep-hearted comment to this article (in Italian) from a former collegue. The project estimation process pointed out that "changing requirements" were the most dangerous risk factor for a software project. Even if I proclaim myself an "agilist", which means I should "embrace change", the temptation to "fix the requirements" is still there. Two main reasons for that:

1. You've gotta start from somewhere
   
2. Most of the contracts are structured on a fixed price basis, which can be accommodated by change request, but the base price is crucial.
   

Agile philosophy states some principles. Fixed requirements are utopia: external situations evolve, and more than everything else, stakeholders learn something more about what they want as long as you show them some progress. It's not that change is more efficient than fixed requirements. In some cases, if your requirements are stable (which means you made a pretty good job in the gathering phase) a waterfall might even be more efficient, but if something changes – and 99% of the times it does – you're screwed.

Knowing him, and having been working in the same context he was, I knew that his temptation to fix the requirements was not a "waterfall revenge", but something else. In many projects, especially in the public sector, the initial requirements are not evolving during the life of the project. They're just wrong. They're written by the wrong people, with a wrong goal in mind. Still they're written, ant there's a contract based upon them.

It's easy to smell a situation like this: try asking for a real user (something really XP)… I've been answered: "You can't meet the user". Reasons may vary: "there are too many", "they don't agree with the management" (I bet so), "it's a waste of time", "they have different opinions" (this is interesting), but basically the case is that who is paying is not who needs the software. And who wrote the requirements is often none of the two.

It's interesting to note that an agile process helps dealing with this situation: every agile process eagerly seeks for real feedback. If you have a fake requirements writer, you have to start asking him questions about the application. I mean …a lot of questions. In this case there are probably two options: one is not answering, but the contract should say somewhere that some support might be given; the other one is finding somebody that can provide the answers. They might be surprising, but early surprises are better than last-minute ones.

Tags: Agile, Requirements

Is Domain Modeling a “liberal” activity?

This post might sound quite stupid, but I guess this is nothing new… There's been a long debate going on between two parties: those who prefer modeling a system starting from an Object Oriented domain model, and those who prefer starting from a Data Model. I am not talking about legacy systems where this choice is somehow context-driven, I am talking about the rosy scenario: just starting from scratch. My personal style is to never-ever start modeling from the data. I did it, when I was younger, and was developing a MSAccess VBA application. But that's it. In a OO system an Object is a richer entity than a Table: there's behavior that comes into play and I think that the table is sort of a projection of the domain model. To be completely honest, I have to admit that I am far more familiar with UML and Java than with ER diagrams or SQL, but that's not the main reason for me to do that.

I started to suspect that there is something more deeply rooted here. Ok, we can't really classify UML or ER modeling as a "primal instinct" – although some graffitis might be classified as "Cro-Magnon UML profile" – but peers tend to choose one way or another one "by heart" unless when constrained by the tools in use. Getting to a precise, DDD-like, domain model is a complex task, which involves a deep understanding of the real domain, that can be achieved through empathic discussions with domain experts and users. The goal is to understand a different culture, and the way is to respect it. Doesn't it sound a little bit like "make love not war"? From the data-driven guys point of view, this sounds a lot like "he had a difficult childhood" or "we've got to consider the environment he's been growing in" which results in a big loss of time. The domain is just another word for the data model, which is made up by data and constraints, all the rest is "OO-hippy stuff".

I assure you I was sober, when I thought this. I still think this is fairly stupid, but it fits a lot of my collegues… ;-)

Tags: OOD, DDD, Software architecture

The unexpected side of being a freelance.

Some time ago, I switched my job turning into a real freelancer. This means more unpredictability, more risk, more freedom, and a lot more things to learn.

Since I want to offer my consulting and training services on the European market, not only in Italy, I needed to define some branding, that could be suitable for english speaking countries. My obvious choice was to stick on something like "Alberto Brandolini IT Consulting". Which sounds a little presumptuous per se, but also has some extra drawbacks. Given that it's pretty long, an acronymous could fit better. But if the result is A.B.I.T.C., you could end up with advertising like "I was not satisfied with the overall performance of my IT department, then we called ABITC, the result was impressive, and we've learned a lot".

Gotta find something better...

Tags: freelance

Upcoming Events: Java Day 2007 in Rome

Java Day is approaching, the official site is up, and so is the program.
I'll be one of the speakers, talking about Grails

I've checked the official program of the day. And I'll be speaking around lunchtime. This is bad, because at that time I'll be incredibly hungry, and being hungry is the only thing that gets me angrier than bad code... At the last java conference in Milan I remember finishing late the morning session, and being the first afternoon session. So I had to skip lunch, really wanted my speech to and as soon as possible, just to have a pizza, a sandwich, or ... whatever. I'll be prepared this time.

Tags: events, Grails, Java

Agile day in Bologna

Tags: Agile, events

Photos from the saddest cubicle competition...

Wired published photos of the saddest cubicles sent by readers. And what you see is only a small part. of what you can actually get. What you, hear, feel and smell is what definitely makes your workplace special...

Tags: agile, Software Development

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