Code Quality through reviews and pseudo code

Code quality is one of our most concerns here at GNstudio, our willing is to avoid that the process of scaling up our organization negatively impact the quality of our code.
The aim of this short post is to discuss the building blocks of the process we use to keep high quality standards, this process essentially is based upon the following items

•    Architectural reviews
•    Pseudo code
•    Code reviews

All these items help us to keep all the stakeholders of a project on the same page also from a technical point of view.
When a new project starts we dedicate a while to the “iteration 0” in order to let us a chance to get all the requirements and to have the same vision of our customer about the project. At the same time we have a chance to start to discuss with our developers the building blocks of the architecture we will put in place for the project.
A software architecture is more than just a technical blueprint of a complex software-intensive system. In addition to its technical functions, a software architecture has important social, organizational, managerial, and business implications.
What we do during the “iteration 0” is to define just enough pieces of the architecture to start up the project, the layers involved in this phase are

•    The application domain
•    The subsystems (and their main interfaces)
•    The communication domain

The definition of the application domain is critical to us because we use this also in order to start to define a common terminology to refer to the entities involved in the application.
We strongly believe that the quality of the code can be also measured by its understandability, for this reason we made a review of the application domain explaining it with simple words to all the stakeholders involved in the project.
At the end of this phase our domain usually is changed both in terms and in relationships. We get this result because in order to explain a domain to not technical guy we have to drive them into some use cases that involve the product they own.
Use case exploration drive us to the validation of the domain because we make empiric tests about the entities and the relationship we have to put in place to keep our customer satisfied, moreover we believe that a good domain is understandable and the use case approach put into evidence immediately the terms or the relationship that are not easy to understand or (worst case scenario) that are totally wrong.
During “iteration 0” we identify the subsystems we have to deal with, the ones that we have to write down by ourselves and the ones that already exists and that we can use, and the communication domain.
When explaining these building blocks to the stakeholders the benefit is to get some past experiences or some different points of view, diversity and experience are the building blocks of any successful project.
We strongly believe that agile and architecture can coexist and that can live upon the same iterative principle, so the architecture we define during “iteration 0” should be seen not as immutable but as an asset to reevaluate at each iteration, in close collaboration between architects, developers and stakeholders.
The continuous review of the architecture of an application is very important because in this way nobody in the team can forget or misunderstand the “idea” that is behind the technical strategy adopted foe a specific project.

When development starts a good practice is to write down some informal “schema” of the code that the core components of the application have to implement.  This practice is called pseudo code, pseudo code is a compact and informal high-level description of a computer programming algorithm that uses the structural conventions of a programming language, but is intended for human reading rather than machine reading.
Usually the technical leader of a project defines also the core component of a system, through pseudo code he can share and discuss his vision with all the team. The greatest benefit we get from this practice is that also the internal layers of an application can be validated and improved through discussions, moreover following this practice we avoid that developers go in the wrong direction during the development or that some pieces went lost during long projects. To help us during the pseudo code phase we built our custom eclipse plugin named Intelligere Agile Modeler, for more details take a look here http://agile.gnstudio.com/iam.

The next steps is the implementation of the pseudo code models, so it’s in a later stage that we actually start to write down code, when the code is in place we start to make reviews of each single class involved in the system. Code reviews are very important to us and we already described here https://gnstudio.wordpress.com/2010/05/16/code-review-user-stories-and-sustainable-software/ the way we do it. Code reviews without architecture reviews and pseudo code are still useful but can help you only to remove bugs from the system, increase performance, etc. Using code reviews as the check point of the implementation of your architecture is the way to use them as a mean to keep an high quality code in place.

This entry was posted in Agile, Best Practices. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s