Software Engineering is a special type of Engineering

During too much time Software Engineering has been molded as a traditional Engineering, with the same terms and ideas that came from this disciplines. But they failed.

Firstly, Software Engineering has an immaterial final product. It is not a bridge, a road, or a mine for example. Thus, software engineers works with ideas more than anything else.

Thus, traditional engineers are limited by Physics laws while software engineers are only limited by the computational model they use and by the power of the machines their software run. Nowadays, for non-complex tasks (traditional business logic), these machines are more than enough.

Therefore, this field should be an easy field where most projects can be easily estimated, developed and delivered without any problem. This could be true if needs software satisfies did not change. Requirements change and software also can be changed, so why shouldn’t we update client’s software?

Even if we could accept all the changes client requires, it could be worst. What about a client that doesn’t know what he wants? And what about a client that what he/she wants is not what he/she needs?

What happened because of this copycat mistake? Many software projects were failed, abandoned. The situation in many projects was fine until there was an increasing feeling of dissatisfaction between client because his/her new issues could not be resolved. The end came when there were no trust between client an developing team (client felt he/she was being lied).

What is agile?

The term Agile was coined in a meeting of some important figures of the industry. Their idea was to make a common ground to several practices each one of them were using. So at the end, they came with a “creed” called Software Manifesto:

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.

A fast summary is that Agile is a framework of developing software projects that focus on delivering working software and collaboration with client.

Agile assumes we know nothing about what the client needs, so it tries to reduce error making small deliveries that must be validated each time by the client. Small changes mean small errors. Above all, this tool gives us the opportunity to get some new needs that arise with each new delivery.

This framework values the team above all. Software is so complex that it is needed many “brains” to develop it. The best solution is reached when all the members participate.

Agile doesn’t erase Analysis, Software Design and many heuristic practices that should be used by all software engineers. But we can’t forget that we have to deliver working software and not a ton of documents. Our client needs us and needs his/her software.

To sum up, it gives simple tools and a discipline to avoid making the project software fail.

Is this Engineering?

On one hand, managing client needs looks like Engineering to me. I’m sure an architect asks what kind of building his/her client wants.

On the other hand, no, you’re right: it is not traditional Engineering. Software is applied logic and is free of all laws other Engineering branches have.

Agile gives the most cautious solution to a problem nobody can solve: how to make evolving software.

# How to start with agile?

I just read the book The Agile Samurai by Jonathan Rasmunsson and is a great introduction to agile mindset.

What from now?

There is some criticism about the abuse of the term “agile” but I really think it doesn’t matter. What matters is this agile manifesto and using what tools you need to make the client one of your team when developing his/her changing software project.

You have to use what suits you.