Basic Software Architecture and Deployment Choices (part 1)

This is the first of a serie of posts on how to face some basic challenges when starting a new software project. The choice now is more complex than in the past, and this happened mainly because many languages have evolved, many other are born, many more people use now computers, and especially because internet is now a very important reality.

Gentlemen, choose your language

To choose a language in which to develop a project is not trivial. If somebody asks me "Which is your favorite language?" I promptly answer Java, but in case I am given a new project, a structured decision approach is needed.

“A problem well-defined is half solved” — John Dewey

The main question is: what do you want to achieve? The question must then be better specified focusing on the user, performance, available technologies, quantity of data involved, time-to-market, competitors, state-of-the-art, and so on. Each architecture has pros and cons: Java is portable and object-oriented, but needs resources; C is fast, but neither object-oriented nor easily portable; Lisp is good for artificial intelligence, but is very hard to teach to procedure-oriented people; with PHP you can build fantastic web-based applications, but is not the best choice for stand-alone programs… there is also the possibility to mix up solution: in a past project I wrote PHP code that generates HTML and Javascript, which was executing dynamically generated SQL code; in that case some lines of code ended to host four different languages!

Aim to reduce complexity
The secret for a successful architectural choice is aiming to reduce the project’s complexity.
Facing the challenge to release the project in time, within the given budget, and with the highest possible quality (within the given time and budget), complexity is the most evil enemy.
A general rule to face complexity is to (Divide et impera: divide the problem in small, independent parts, and develop those parts separately.  How far this "divide and conquer" analysis will go it will be your choice. It is a matter of experience to identify how to reach your target in a clever way. Generally speaking, an object oriented language almost forces the division of the project in "objects", and this helps code maintainability and scalability.

Prototyping
Another enemy (funny to say!) to achieve a good final quality is the client: non-it oriented people tend to underestimate how bad it could be to change the requirements after that development has started. The requirements must be well defined, understood, and agreed at the beginning of the project. Writing down requirements and describing the agreed solution in detail to the client before starting development can seem a waste of time, but will save lots of efforts afterwards.
Most projects involve some GUI (Graphical User Interface), or at least a "presentation layer". A prototype should be presented as soon as possible in the development phase. Just think that the client will see and use software only from outside: algorithms and calculation engines will probably remain just black boxes for the client, while he will just focus on the usage and results.
The prototype should be built in the same way the final product will be executed (E.G.: if you have chosen Java, just present a dummy Java GUI). If this is not possible, just build a graph in Powerpoint (or the open source alternative OpenOffice Impress). If even this is not possible, just use pen and paper, and do not forget to finish with date and signatures from both parts.

In the next post of this serie, we are going to explore deeper technical and architectural topics… stay tuned!