On Architecture

From "Planning a Computer System - Project Stretch" [PDF]

Fred Brooks coined the term computer architecture as early as in the 1950s and ever since it has been a favorite in the computing circles and much has been written about it. The building analogue has been prevalent ever since and misused and stretched so much that most of the laws of physics and humanity must have been broken on the way. So I'll stretch it some more.

Currently in software the term architecture most commonly means a power point illustration of boxes and arrows with names of applications, products or imagined layers of software construction inside them. And if architecture is mentioned in a discussion the very definition of Mr. Brooks for architecture - the determining the needs of the user - is not mentioned at all. Architecture is the comfort zone of the techies who have been promoted away from the programming tasks in the corporate ladder but in a stairway not leading to the penthouse where the business people do the world domination thing but in the other one leading to the dusty attic of IT management.

This is not the "where the rubber meets the road" architecture but architecture where someone not part of the problem (the biz) or the solution (the dev) tries to affect the result.This might be well meaning or malign but usually is done too far away from those who are actually accountable for their deeds (the biz and the dev).

A beautiful day in Itä-Pasila.

Architectural styles are subject to fashion and trends like the clothing industry. And just like with high street fashion the garment that is most fashionable today is just a heartbeat away from being so totally out of fashion. This can also happen in the real world architecture of buildings and cityscapes.

The bridge integrates two areas in the top layer of the architecture and isolates them from the lower layer.

In the 1970s the eastbound neighboring country of Finland was not Russia but the Soviet Union. And that's where the architectural ideas came to Finland in the 1970s. The Itä-Pasila region of Helsinki built then looks like stuff made behind the iron curtain.

Here the architecture allows four paths to the other side - all not very inviting. But at least you have a choice.

The trend then seemed to be a 2-tier architecture where the system is divided in two layers: the bottom or "back end" layer is for the heavy lifting: cars and lorries transporting stuff. The second tier, the "front end" is then for more slow paced and lightweight traffic of more lightweight units called persons. However, these two layers need heavy integration and this is implemented with lifts, ramps and staircases between the layers.

In a flat architecture it would not matter which way you should walk if you want to go around the building in the picture. In this multilayer architecture you must make your navigational decision at this point.

The whole thing is built to serve the person units and their needs. That usually means moving from a place to another one and enjoy the company of other person units meeting them in some designated areas in the front end tier. The two tier architecture was said to enable this as the person units can freely move on the top tier without the impedance mismatch of mixing their paths to the remarkably faster moving cars. Something that the architects did not take into account was that the person units had to visit the bottom tier quite often as they use the cars to move about from region to another. And that they are quite good at finding routes from A to B in a two dimensional surface but really suck in the task if they have to move in a three dimensional surface consisting of two levels where the navigational rules of the 2D environment do not apply.

Good naming conventions are a must. This indoor hallway with a concrete ceiling is named "Aurinkoraitti" which translates to "Sun Passage".

The architects seem to have this obsession with organizing stuff in layers and making barriers between them but it is more natural to people when things are not that well in order as long as they are simple and the scale of things is convenient. So perhaps also in computing making the small decisions right, keeping the needs of the user in mind all the time and having the right scale is more important than forcing everything to some artificial layers in a heavy foundation framework based on the latest sales pitches of large IT vendors.

The lift on the left comes from a parking hall underground straight to the top layer where there is nothing of interest but from where you can descend to lower levels with either a staircase or a ramp or take the bridge crossing the road below.

As A User I Want To...

User Stories, especially if used in a very formal way, are much criticized by my colleagues. One point is that the user (in any role) most probably does not want to use your system but just to get it over with. So, whenever someone says "As a (role) I want to" it has become somewhat of a meme to say:

As a user I want to drink piña colada in a swimming pool

I assumed that this was true but I wanted to be sure and made some empirical studies and it in fact is so.

Photo: Heikki Pora

My First ATDD Project?

I remember when around year 2000 or so we were looking for a better way to make software in our small dotcom bubble startup. Somehow the traditional project model did not work. I do not think we knew the word "waterfall" then. First we found Unified Software Process and its commercial friend RUP. The idea in RUP that design, development and testing are not sequential phases but tasks you do repeatedly in a cycle during a project was just super. Of course the bureaucracy of zillions of artifacts and roles and the model driven madness soon turned us away from it to look for something else. What we found was XP.

And did XP sound just like a great idea! In RUP the actual software development was considered a triviality that just happened between the pile of UML diagrams and test plans. In XP the programming was the centerpiece with all its great practices like unit test first, pair programming, refactoring, collective code ownership and so on. And we tried to follow them all quite strictly. Unit test first rewired my brain forever. So did pair programming and the thoughts about simplicity.

There were not much tools around. Refactoring came in some version of Eclipse and I stopped using emacs. Builds we made with make. Continuous integration was done manually committing a task to a branch in cvs and merging that to the trunk at the integration machine. Radiator was a printout of the number of the unit tests in the code base in a font so large that it did fill the whole sheet. But we did all those things. And we were good at it. At least a lot better than before that.

Thing we did not manage to do well was measuring velocity and the thing we did not manage to do at all was doing acceptance tests. It just did not happen.

Our bubble blew and I went on to a one decade larger company with its own waterfall method for software development. I was in the trenches and as the management could not see me I secretly did TDD and CI (manually) until I got bored of it and started my work in Reaktor that already at 2005 was full of very agile colleagues doing Scrum and all that TDD and whatever. Still none of the projects that I was in had really any process for doing acceptance tests. I guess other projects here possibly had but where I was in certainly did not.

There were some system integration projects where there was no GUI so the integration tests were more or less the acceptance tests. And in the GUI projects tools like Fit did not look so suitable as we did not have so much problem in testing rules but in testing GUI interaction. We might have had occasional ad hoc or even some more careful testing by customer at the end of each sprint but there was no process, automation or prevention of regression built into our way of working on this level. Surely there was a lot of unit tests but as you know they are not for acceptance or even for testing purposes but design tools.

During the five years in my current job the role of functional design has increased in our projects thanks to our world class specialists in that domain and the simulation based GUIDe method. With GUIDe we get better product backlogs and realistic usage scenarios to test the software, cases that have been used for simulation in the GUI design process.

The number of test specialists has also increased in Reaktor during my stay and they can support more projects if not by joining them all but at least doing a lot of valuable knowledge transfer. Their ATDD 3rd degree interrogation method combined to well designed GUIs and the realistic usage scenarios have for the first time given me confidence that we can really do acceptance tests and even more than that, we can do ATDD or acceptance tests in the test first way (secret: it is easier to do test first than add the tests later).

Also we found a tool set that we feel quite comfortable with. Selenium 2 lets us write the tests in a way that does not make the tests break if we change the implementation from javascript to java or to actually anything producing a web GUI. JDave lets us use BDD vocabulary in the tests. Hudson runs the tests nicely with the different browsers in our browser CI machine. The project is young and the implementation has changed drastically but the acceptance tests have required very little or no maintenance after such modifications. Au contraire, the tests have saved us a several times finding we broke something in the system while doing our heavy lifting.

So, now ten years after I find myself in my first ATDD project. And I am happy. And no way, I am not moving away.