On Re-* (Rearchitecting, Restructuring, Refactoring and Rewritting)

Sometimes, the eagerness for adopting new terms in technical conversations or blog entries like this, provokes misconceptions around not so new terms and ideas. Recently, I've read an article on InfoQ called Refactor or Rewrite? that has caught my attention. And now, I want to write about those terms: Refactor and Rewrite. But, let's add also two other Re-* terms to this mix: Rearchitect and Restructure.

On Rearchitecting (vs Restructuring) vs Refactoring
In his short bliki entry Refactoring Malapropism, Martin Fowler discusses about how sometimes the "refactoring" term is used when is not appropriate. In particular is discussed the confusion with the term "restructuring". As it is shown in his book Refactoring: Improving the Design of Existing Code, a refactoring task on a particular bunch of code implies appliying a specific tecnique/s for doing small behaviour-preserving transformations on that source code. The key point here are the words "specific technique/s" and "small", that qualify the transformations described in the core chapters of the book. To me, restructuring means something bigger and abstract. Something that does not only imply transform a particular piece of code, but to re-arrange the components that define the architecture of the system. Rearchitect/Restructure a system implies to apply coarse-grained transformations, as for example, the so-called architectural patterns (See the POSA books). That's why to me the term "restructuring" a system is equivalent to "rearchitecting" that system (and I prefer the term rearchitect).

On Refactoring vs Rewriting
And what about refactoring and rewriting? To me, rewritting has to do with code readability and clarity in two dimensions related to the (art) of implementing code: adequate selection and combination of control structures and proper selection of class names, attribute names, relationships and method names. With regard to the control structures, I consider rewriting only in the context of a single method internals to improve readablity (e.g. rewriting a loop). Out of this scope, I consider it refactoring. Three interesting books that deal with rewriting and best practices when implementing code are the classical McConnell's Code Complete, Kent Beck's Implementation Patterns and Robert Martin's Clean Code.

I tend to separate modifications in the structure of the system (rearchitecting/restructuring and refactoring) from the internals of a method (that imply rewriting). Some people can ague that you can refactor the structure of some piece of code and at the same time you rewrite the identifiers of attributes, operations and parameters if required. In fact, in IDEs such as Eclipse or IntelliJ, you can find in the refactoring actions a "rename" entry. However, even with the help of IDEs, rewriting can introduce the risk of introducing bugs. Refactoring is also error prone if you don't follow the rules. So, it is better not to have two sources of errors at the same time.

To Conclude With...
So, we can categorize these activities in three layers: rearchitecting/restructuring (the most conceptually abstract at the top), refactoring and rewritting. Whether it is better to start performing architectural modifications on a system top-down or botton-up in this layered categorization is a different question. Sometimes, before making a refactoring it is better to do a rewriting. Sometimes in order to perform a refactoring it is better to rearchitect the system first. And, sometimes, of course, the other way around is preferable ;-) Of course, in the end this should depend on the arrangements made to face off the modifications on the system, that depend on variables such as the experience of the team members, number of dependencies between modules, current quality of the source code...

Have I missed another important Re-* term? ;-) If you want to continue exploring the Re-* world, another interesting blog entry can be found at Refactoring @ Scale.

An interesting reflection about why not to rewrite projects from scratch and in favour of applying re-* techniques can be found in Joel on Software.

Cloudy Architectures

At this time, everyone has heard about cloud computing. In here, I pretend to offer my humble vision about them.

Cloud computing can be included in a new vision for software services delivered via networks called Internet of Services (IoS). In summary, IoS aims at providing a new set of ground-breaking services at Internet scale to the end users (both citizens and enterprises). In Europe, the IoS vision is embedded joint with the vision of the Internet of Things (IoT) in the actions of the so-called Future Internet Assembly (FIA).

So, cloud computing can be seen as the spine for building the IoS. I define a cloud computing platform as "a hybrid hardware/software elastic multi-tenant infrastructure that supports the implementation and deployment of applications and services at Internet scale". I call it infrastructure because it combines both hardware and software architectures. It is elastic because one of the main objectives of cloud computing is to offer/adapt the resources used by an application to its current needs at a given time. Finally, it is multi-tenant because a single cloud infrastructure can run multiple applications from different users, enterprises, departments etc. with heterogeneous requirements.

Another objective of cloud computing is to save money to the enterprises. Using a cloud infrastructure, the enterprises pay for the use of the IT resources. For example, in this way, enterprises do not have to worry about investing a lot of money in IT infrastructures in order to provide good QoS to potential users when dealing with unexpected increasing workloads that may last only short periods. They may simply rent additional resources from the cloud provider in order to satisfy such peaks. Therefore, this can avoid the economical effects of overprovisioning their infrastructures or underestimating the success of certain businesses. Payments can be done by means of the utility computing model, where the user pays for the resources consumed (e.g. like paying our electricity bills), or based on a suscription period (e.g. when we subscribe for a tech magazine for a one year period).

These kind of infrastructures have mainly three different layers of abstraction that encompass different architectures, both hardware and software. These layers include other buzzwords "à la mode" these days: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS).
At the top level of the infrastructure is the SaaS layer, that contains the enterprise/user applications running on the cloud. This layer uses the facilities provided by the PaaS layer in order to provide an elastic behaviour to applications with regard to their current needs (basically the current workload and desired QoS attributes, e.g. performance, availability etc.). Finally the IaaS layer provides a virtualized abstraction (software) of the physical resources (hardware) that conform the substrate of the cloud infrastructure.

One of the main concerns of cloud computing is its adaptation to different environments. However, clouds are comming in different flavours: public (accessible for general users, e.g. Facebook), private (devoted to enterprise environments, e.g. Salesforce.com) or hybrid (e.g. cloud applications deployed on Google App Engine, Microsoft Azure or Amazon’s EC2).

In here we are interested in the architectures that can be integrated in the PaaS layer, so we'll write an entry about it in the near future.

Other references about cloud computing are:

A Short Introduction to Cloud Platforms by David Chappel
Berkeley University vision of Cloud Computing
The Future of Cloud Computing article at Sys-Con Media
IBM Cloud Computing

Current providers of cloud computing solutions are:

Amazon Elastic Computing Cloud service (EC2) (IaaS/PaaS)
Google App. Engine (PaaS)
Microsoft's Azure platform (PaaS)
Salesforce.com and Force.com (SaaS/PaaS)
Heroku (PaaS)
SAP Business ByDesign (SaaS)
IBM's Cloud Services and Computing on Demand (SaaS/IaaS)
Rackspace (IaaS)

Other visions:

IBM vision of the cloud
Oracle in the cloud
The 451 Group vision

The Pomodoro Technique

The Pomodoro Technique is an interesting technique to avoid procrastination at work. A book related to this technique is going to be published in The Pragmatic Bookshelf: The Pomodoro Technique Illustrated.