FODA Methodology

This post is for brazilian readers only.

Tim brought my attention to the FODA methodology (Feature-Oriented Domain Analysis). I don't know about the methodology but the name sounds great :).

Agile criticism 2 - Scrum and the Team

One of the key concepts of the Scrum methodology is the Team (I'm not the one adding the capital T; this is how it is actually referred to in the Scrum literature). In Scrum, the Team is self organizing, which means that management is not supposed to tell the people what to do. Instead, management just makes sure the Team has everything it needs to get the work done, removing roadblocks and isolating the team from outside pressure.

I agree with that in principle and this is how I work with my own team. But I can only do this because I have a homogeneous team of talented people where everyone is a team player and works well together. The problem is that Scrum doesn't have tools for when politics, vanity and other human characteristics come in the way. And this is because the Scrum Master (stupid name) is constrained by this 'self organizing' principle in Scrum. Sometimes you just have to make a decision and exert your authority.

Team playing is important. But if you trace a parallel to sports, you usually don't see a successful team with if you don't have a talented and strong coach. I'm not claiming I'm such a person myself but I don't buy the argument that a team doesn't need a leader.

Agile criticism - 1

Before I get beaten to death by the Agile Evangelists, I want to say that I do believe in Agile. I am open minded, and I think Agile methodologies are a breath of fresh air in the software development community. But I'm as skeptical as I am open minded, which I think is a Good Thing. And being skeptical as I am, I think there are some fundamental problems in the way that Agile is 'sold' by some evangelists, and 'bought' by the general public. I will talk about those flaws during a series of posts.

Before I expose my first criticism I would like to quote here the Agile Manifesto. At the first time I read it, I was surprised by how short it was. I was probably waiting for something as long as the Communist Manifesto, but the Agile one is surprisingly shorter:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

That´s it. 10 lines. It almost feel like they wrote it in a napking over a cup of coffee, but it does the job. In a world of verbose meaninglessness, those guys are able to cut the crap and go straight to the point. They get grade A for conciseness.

I can't disagree with what it says. But what stands out to me is the following: while there is value in the items on the right, we value the items on the left more.

Great! They don't dismiss processes, tools, documentation, contract negotiation and following a plan. Hell, I like these guys! This Agile Manifesto thing seems off to a good start! But I feel that many people got it wrong, because what I often see is total dismissal of these items in favor of the agile principles. It is like everything that was ever tried in the 50 years history of software development was wrong.

This is my criticism: Agile is often seen as a 'one size fits all' solution. Also, it is seen as a replacement for everything that came before.

This is a movement that is seen very often in the software industry. Some new idea comes up, usually with a catchy name, and before you notice everybody is talking about it and using it. But most of the people don't get it right, so it is implemented 'by the book' or it is overused. At some point, people get disappointed when they find out the idea is not the holy grail of computing, then many get it wrong for a second time and start saying the idea that would solve all problems is completely useless.

The problem in the process above is that people don't understand the basic principles that drove the development of the new idea. If they did, they would most likely apply it only when it is supposed to be applied, and not everywhere as it often happens.

In the case of Agile methodologies, they came to replace traditional methodologies in the situations where they are misused. The good thing is that this describes the situation of most software projects that try to use some kind of methodology (the most common case is to have no methodology at all, in which case Agile also fits). But even then, if people don't understand the principles, they won't get Agile to work. The smart people will get it and turn Agile into a success case.

So I finish this with two advices. First, understand the principles behind Agile. Read the Manifesto. If you are using any Agile methodology, make sure you understand the reason of EVERY SINGLE PRACTICE the methodology proposes. Then see if it applies to your situation. If so, fine. If not, discard that one and use the rest.

This takes me to my second advice: be skeptical and try to understand the reasoning behind *any* new idea. Use your intelligence and feel free to question what seems to be common sense. It will make you a much better developer.

More information:

Tim High has a great post where he questions: Is Agile for everyone?

When the laws of software no longer apply

Newtonian physics specify a set of laws that describe very well the universe in the scale of space and time that we can perceive with our senses. In this scale, the universe is 'well behaved' within the limits of those laws, which means you can predict very well the interactions between bodies using newtonian physics.

In the scale of the very big or the very small, however, Newton's laws break down. At the domain of very small particles, you have to resort to quantum physics. At very large speeds or with very large masses, you have to use Einstein's physics to describe and predict the behavior of universe.

I like to think of software the same way. In well controlled conditions, software is well behaved under the traditional rules of software engineering. In this situation, you can follow the textbook recommendations when designing your architecture. You can design your database using the traditional normalization rules. You can use the popular frameworks, libraries, tools and methodologies (both the classical and the 'agile' and 'extreme' ones). Those rules, tools and methodologies exist and are broadly accepted and deployed for a reason.

This situation is where the VAST majority of the existing software is in. It is the condition you find when you are dealing with reasonable requirements for scalability, availability, responsiveness, data volume, or delivery time. And the definition of 'reasonable' is pushed forward more and more as the time goes by.

However, when the requirements for your software are pushed to the limit, and what I mean by limit is really an extreme case, you can no longer resort to the textbook rules. You have to think of alternative designs and solutions. In the software architecture, you will sacrifice the purity of your design. You will have to compromise it to extract the maximum performance. In the database side, you will have to denormalize and think of non traditional ways of storing and distributing your data. In the tools side, you will have to develop your own homegrown tools, libraries, and frameworks, or adapt existing ones for your own needs.

At first, those measures will look like heresy. You will think the people who developed the software are a bunch of morons who have no idea of what software development is about. You will feel like you work at a perfect place to feed The Daily WTF for years. But if you take a step back, you may realize that there isn't a ready solution for everything. Sometimes you will find you are on your own, and you still have to deliver your software when the deadline comes by. Don't hold on to a rule just because your professor told you so.

I am not advocating that we give up on everything we learned about software architecture. As I said, software architecture rules apply in the vast majority of cases. They exist and are broadly accepted for a reason. But we need to understand the reason behind those rules. Or we will be engaging on Cargo Cult Programming, maybe doing something out of some vague sense of duty to the ghosts of Boyce-Codd.

Because the laws of software development apply to the vast majority of cases, probably if you see someone breaking those laws it is because that person is really a hacker. But it might be because he or she is a clever designer who is solving a difficult issue the way no one has thought of before. But in general it is better to come up with a clean and simple design. As Ted Dziuba says, "Scalability is not your problem, getting people to give a shit is".

But if you are going to judge someone, or if some day you find yourself in the situation of designing software to handle ridiculous volumes of transaction or data, remember to keep an open mind.

More info:

The High Availability blog is a very useful source of information about the architecture of some of the highest volume websites in the world.

Martin Fowler on the Ultimate Heresy: transactionless environment at EBay. Plus, EBay's database doesn't have foreign keys!

Getters and setters are Evil

Getter and setter methods, also known as accessors, can be seen everywhere in Java classes. Developers usually create their classes with their attributes, and then use their IDE's code generation functionality to create simple getters and setters automatically for all attributes. Some frameworks, like Hibernate, promote the use of accessors everywhere.

At a first glance, getters and setters seem to promote encapsulation. After all, they seem to 'hide' the attributes of the class. In reality, accessor methods are just a more convoluted way to expose your attributes. That's why I think getters and setters are Evil: they give you the illusion of encapsulation, without actually providing it.

In an ideal object oriented system, you shouldn't have to get the data from an object and then perform some operation with that data. The right thing to do would be to ask the object who owns the data to perform the operation itself. This is object orientation at its finest. Then you would have real encapsulation: you have no idea, and you don't care, about the data contained in an object. All you know is that an object can provide you a service specified by a method.

In real life, things are trickier and you can't always do that. Sometimes it complicates the model unnecessarily. But whenever you find yourself calling myVariable = myObject.getSomeAttribute() in order to perform some operation with that variable think if it wouldn't be better if you place that operation inside myObject's class. Only expose the strictly necessary. You will find your model will be much cleaner and maintainable.

More information:

• "Why getters and setters are evil", by By Allen Holub, JavaWorld.com, 09/05/03.


• Google search for "Getters and setters are evil".