In search of the lost simplicity
One confers two pretty interesting propositions to Albert Einstein:
· “Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction.”
· “Everything should be made as simple as possible, but not simpler.”
The message of these phrases is clear: you must try to do things in the simplest manner which solves the problem. On the other hand, making things complicated is very simple.
Einstein naturally made reference to theories in the Physics field, his specialty. However, the software field may benefit hugely from this vision, for it is up to developers, from programmers all the way to the architects, especially, to create the simplest possible solution, but that still serves the problem at hand.
In the project of a software system it is very easy to fall into traps which cause an enormous increase in the complexity of a project. Certain characteristics may seem desirable at first sight, for example:
· “Our application must support all existing databases;”
· “We will have a great deal of flexibility if we use an architecture of N layers” (choose an N between four and eight);
· “We must support all existing hardware and/or operational systems in our users, including the Windows 95 with a 32 Mb memory”;
· “We shall have Web and Windows versions of the same functionalities.”
· “The XPTO Pattern is the best invention in the world and we must use it always”. (XPTO is any cult object as for example MVC, DataReaders or OO-Relational mapping libraries).
All the characteristics above can at first be desirable, but they without a doubt complicate and burden the development. Complicating almost always means:
· To increase the cost;
· To extend the date of delivery;
· To demand more qualified and trained development team.
I am yet to meet a client that says things such as “The price does not matter”, “We have all the time in the world” or “my purpose is to constitute professionals so that they will later work for my competitors”. In spite of this, I find development teams that in a concealed manner conspire against the success of the projects, when prescribing things more complicated than they should.
For example, using a several layers architecture or “MVC (Model-View-Controller)” can be justified in a project with many people and with a long life cycle. But for the “kriskin” raffle or for the around the corner bakery stock control, using two layers with the great productivity provided by the Visual Studio 2005 is much better. To support various databases is very pretty, but if 95% of your clients worship the Oracle, I doubt that the additional complexity is worth anything (it is cheaper to present as a gift a copy of the Oracle to the 5% who do not have it).
We must attempt to reach a balance between the really necessary resources, yet maintaining the productivity in the development. This means doing things such as:
· To adapt ourselves to the available tools and components, instead of creating components exactly in our fashion;
· To seriously question the necessity to support the whole hardware and software range of the client;
· To suspect and question the dogmas, such as “The MVC is the only good way to work”.
Deep inside, we are talking about prescribing a solution that adapts itself well to the problem, without exorbitances. Sometimes some geniality is needed in order to do that.
Mauro Sant’Anna (firstname.lastname@example.org) is no Einstein and has complicated simple things sometimes. But he is learning.