This is the slide deck of my LAS 2010 presentation: From user stories to architecture.

In this presentation, I’ll show you how we evolve the architecture of our software Sprint per Sprint (we develop software using Scrum).

You’ll see the architectural challenges you have to face when developing software in an agile way and how we cope with them to get an architecture that grows together with software.

Using Scrum, we build our software incremental and iterative:

Incremental means, building software feature by feature. Always a complete part at one.

Iterative means, building a first version of the software, get feedback on it and then improve the next version. Until the software is finalized.

When you combine both, software is built feature by feature (or user story by user story), get feedback on it and improve. It is important that a feature is always something complete. Something a real user can give feedback on.

This approach of building software leads to two problems regarding software architecture:

The first is incompleteness.

Incompleteness because the requirements are never complete and will change due to feedback provided by your customer on your progress.

The team will learn while developing. The team members will get better at using the technology used in the project and they will get a deeper understanding of the problem domain solved.

We always have an incomplete picture because we cannot anticipate every change that will happen during the project lifetime.

The second problem we have to face is change.

Change happens because requirements get clearer. During development, the team will ask questions to the customer to get a better understanding of the problem to solve. These discussions result in requirements that are more precise as the project goes forward.

Plans may change due to a changed business situation. If your customer’s competitor made a move then your customer may have to react and change the scope of your project.

In projects that take more than a year to develop, or during maintenance, technology will probably change. Take the .NET framework for example. There is a major update about every two years. Or the operating system changes (from 32bit Windows XP to 64bit Windows 7). Your architecture will have to take these steps, too.

Finally, people change. Either because they learn new things, simply change their minds, or they change teams. Your architecture has to take this into account, too. The architecture is no good if the team does not understand it or thinks it’s bad.

We have to design and evolve our architecture in a way so that these problems are under control.

We design our code – and therefore our architecture – in a way that it is open for new features.

However, it is important that we can extend our design without breaking existing abstractions. Otherwise, we will end with endless refactoring. We can add new features without changing the existing code base.

When requirements change, code has to change. If we want that our architecture remains stable, we have to ensure that we can make changes that are local.

Local means, a change influences as little code as possible. If possible, even without breaking any abstraction defined by our architecture.

Most important is simplicity. Simple things are easy to understand and therefore easy to extend or change. Simplicity means, the architecture fulfills all needs but in the least complex way possible.

There is no big design up front. Too much thinking ahead often leads to too complex architectures. Architectures, which are built to be flexible and extensible from the start, often break when the real problems arise.

There exist a lot of principles, practices and patterns helping to achieve a simple, extensible and flexible architecture and design:

One of the most prominent is S.O.L.I.D by Robert C. Martin.

Once you have an architecture in place, how do you keep it stable?

We write automated tests, which guarantee us that the tested properties of the architecture remain stable while we extend and change our software.

We use mainly two kinds of tests to achieve this:

The first kind of automated tests are unit tests.

Unit tests help us to build our software as a combination of individual units (classes, components). We can rearrange these units to achieve a change in the architecture while knowing that the building parts remain stable and will still work correctly.

The second kind of automated tests is acceptance tests.

Acceptance tests check a complete feature – end to end. Note: almost end to end: we replace for example the UI representation layer, data access layer and file system access with mock objects.

When we have to refactor parts of our software to enable the integration of a new feature, these acceptance tests guarantee that the existing functionality (functional and non-functional requirements) is not broken.

We use Scrum to develop software.

In Scrum, the project starts with a Kick-off meeting of some sort. Before the first Sprint (an iteration in Scrum), an initial product backlog is built to get a rough understanding of what is to be built.

Development happens in Sprints. Each Sprint starts with the Planning Meeting to plan the current Sprint (detailed discussion of what is to be built). The result is the Sprint Backlog.

Each day, the team stands together for the Daily Scrum Meeting to get a picture of the current status of the project.

To get feedback from any stakeholders, the newly built parts of the project are demonstrated in the Review.

Finally, each Sprint ends with the Retrospective, which the team uses to find improvements in the process as well as in the way they work (for example tools).

Now, let me add our activities regarding the lifecycle of the architecture:

Let’s have a detailed look at the different actions.

After the initial product backlog is created, it’s time to start thinking about the architecture:

The granularity of the initial architecture depends a lot on the type of the project. It has to be clear enough to get the development team running, but it should not be too specific either.

Firstly, because we want to start producing working code as fast as possible to get real feedback as soon as possible.

Secondly, architectural design decisions at this early stage may be difficult due to lack of know-how on the problem domain. If something does not yet have to be defined, then I’ll defer the decision to build up more knowledge first.

Therefore, the initial architecture is “only” a guideline for the team, describing the project in a very coarse way.

The architecture will gradually be refined during the project as you will see.

Every Sprint, my team holds an architecture workshop. Normally, on the first or second day of the Sprint.

The main topic is to build team-wide common knowledge needed to implement the User Stories (and other Backlog Items) of the current Sprint. Note that the team will come up with questions in the Sprint planning meeting while discussing the break-down of stories into tasks.

This meeting also helps to have equally distributed know-how of the architecture; resulting in better designs in each developer’s daily work.

Finally, the team may come up with architectural problems that were identified in previous Sprints. Either the team can solve them in this meeting or a team member takes responsibility for actions during the Sprint (normally the architect, but can be anyone on the team.).

While the developers are working on the code, they gather feedback about the architecture: Can the new feature easily be integrated? Are there new insights that lead to changes of the architecture?

It is important that the team keeps track of architectural issues. We write these on cards and hang them on our Scrum Board.

But how do you generate feedback on your current architecture in an early Sprint, when only parts of the system are built?

The key to this are simulators. Provide a simulation of the environment in which your architecture lives. Simulators can be mock objects used to isolate a dependency away from your system (e.g. the database, file system, user interface representation), or a real simulator for an instrument or other external device.

With these simulators you can check how your architecture will likely behave in the real world.

With every new feature in the software, the architecture is evolved further – always changing together with the code that it supports.

This leads to an architecture that really solves the problems at hand without far reaching assumptions that may never become valid.

Due to the fact that every developer drives the architecture, it becomes a team responsibility. Everyone can and should influence the architecture. That is important because the primary function of the architecture is to support the developers to solve the problem. Therefore, the responsibility lies with the ones who benefit.

Normally, evolving the architecture starts with a Spike. A limited amount of time to try something out. The important thing is that a spike is implemented end-to-end. Otherwise, it is probably not possible to predict how the architecture will influence the solution.

A spike is just a minimal path through the system.

An example: you have to build a search dialog, which allows a user to search for customers by specifying the search criteria (prename, name, address, age, …). The result is displayed afterwards in the user interface in a grid showing the complete data of all found customers.

The first step would be to implement the complete search functionality (UI, logic, query, display of results), but only with a single search criteria (e.g. name) and a very reduced results grid (show only name). This stripped down solution can be implemented very fast, because the individual layers are all simple (just for one criteria, show only name).

In upcoming Sprints, this Spike can be extended with further search criteria fields and a better results grid.

The benefit of using a Spike is that you can get feedback about the architectural impact with it, with just a fraction of the effort needed to build the complete search feature.

When everyone is changing the architecture just in the scope of their current problem, the design decisions taken may not be optimal from a broader point of view. These local decisions have to be transformed into global decisions.

For example, the same problem should be solved in the same way throughout the whole project; otherwise understandability of the code suffers.

Therefore, the team should review the current state of the architecture at the end of a Sprint to be ready for the future and refactor where necessary.

We use so called “commit-reviews” to reduce the amount of real reviews needed. In a commit-review the developer who coded a new feature shows all changes made to a fellow developer prior to commit the changes to the source code version system.

Reviews of the architecture are done on the code. And only working code is considered. We want to review the current state of what we really have not of …

… what we would like to have.

The purpose of documentation is to facilitate communication of the design and architecture. It helps new team members to get running fast, or to define interfaces between different teams.

However, documentation is a bad basis for architecture validation.

The software architect is responsible to drive the architecture: Provide input to the team when asked and take the lead in the review of the architecture.

As I said earlier, every developer makes design decisions every day. Therefore, the software architect has to coach the team to help them take the right decisions.

Finally, whenever the team is not able to decide for itself which way to go then its the responsibility of the software architect to decide. The reason for this is that it is still better to decide wrongly (and hopefully correct it later) than not taking a decision at all and probably stalling parts of the development.

We have seen that agile architecture is not a “do it once forever”. Architecture is a process starting after the initial product backlog is written and ending when the project ends.

There is only a valid architecture if there is working code to proof it. Code to get feedback whether the architecture holds or has to be changed.

Architecture is a team effort. Every team member is responsible that the architecture is evolved to support the currently needed features.

Requirements and plans change and so will the architecture. Inspect and adapt continuously to keep up with the changed environment.

Finally, if the architecture is continuously evolved, it will help you to keep up your development speed throughout the whole project lifecycle.

Since a few days I’m using a plugin in eclipse which allows vi like editing. It’s called vrapper and can be found under http://vrapper.sourceforge.net. It is a very good light weight alternative to commercial vi plugins. In my opinion there are not more disadvantages as in other vi plugins.
Sometimes it has hangers, this means it does not fall back to the main state instead it hangs in any command mode. In this rare cases normally helps to restart the plugin with the icon in eclipse.
The installation is very simple, only add the stable update site (http://vrapper.sourceforge.net/update-site/stable). Or if not possible to use the update site just download the file from http://sourceforge.net/projects/vrapper/files/, just copy the files into the plugins directory .

If you like to use vi commands look in and check it out.

For a Project I hade change the DNS Server settings on several client computers. All Clients hade fixed IP and DNS Settings on the clients and the customer want not to change to a DHCP. I can understand this approach because fixing the IP of computers can improve network security and awareness. My first approach was to look inside the GPO of Windows XP. And after 2 minutes searching look what I fond under: “Computer Configuration – Administrative Templates – Network – DNS Client – DNS Servers”

“ Defines the DNS servers to which a computer sends queries when it attempts to resolve names.

Warning: The list of the DNS servers defined in this setting supersedes DNS servers configured locally and those configured using DHCP. The list of DNS servers is applied to all network connections of multihomed computers to which this setting is applied.

To use this setting, click Enable, and then enter a space-delimited list of IP addresses (in dotted decimal format) in the available field. If you enable this setting, you must enter at least one IP address.

If this setting is not configured, it is not applied to any computers, and computers use their local or DHCP-configured parameters.”

After reading the description I Thanked this is it. So let me show you first the test environment. We got to server and a Client. The server running Windows 2003 and the client runs XP. The two servers (dc01.planetgeek.ch/ 172.16.111.120 and sql.platnetgeek.ch / 172.16.111.124) have installed DNS servers. The Client has only one DNS configured the dc001.

Setting up the new GPO and link it to the client pc.

Now we use the client to review the impact of this GPO setting. First we use the gpresut to look if the GPO was adapted.

After we are sure that the GPO was applied I do an “ipconfig /all” to check the DNS settings.

Okay it looks like the DNS setting is not applied. I checked the result several times, rebooted the PC, used netsh to look on the DNS settings and searched for event log entries. Then I tried nslookup on the console. Look on witch DNS server the request goes.

It looks like the network tools (ipconfig, netsh and the tcp/ip Settings gui) from windows XP did not recognize the GPO Setting. I guess if you use this in large company this will end up in a debugging nightmare. Normally I hate this Microsoft bashing, because the Company make good and stable products. But this time the guys from Redmond did a very lousy job.

Udi Dahan gives insight into nservicebus future and commercial options for nservicebus. Read post intro and comment 23 about pricing options:

http://nservicebus.grouply.com/message/8259

Since we use the new terminal client from microsoft we register sometimes obscure reactions. For example: program flipping while pressing the tab key solo, get the dialog which is shown normally pressing ‘Ctr-Alt-Del’ while pressing the delete key solo.

The problem is…

We discovered that it is very important in which order we release some key combinations like ‘Alt-Shift’. If we press them in the order ‘Alt’ and then ‘Shift’ and release them in the order ‘Alt’ and then ‘Shift’ the terminal client will not receive the ‘Alt’ key is released. So it is very important to release the keys in reverse order they were pressed. (And in our IDE we need this key combination a lot :S )

What is to do when…

If this happens just press the combination again and release the keys in reverse order. That’s the trick.

Since a few months I’m working in a new project where we have remote PC’s for developing. Since they updated the clients from Windows XP SP1 to SP3 we we have the new remote desktop client. Now it’s possible to show the terminal client on two monitors (or a monitor with a resolution over 1600×1200). We just had to do the following:

1. create a Shortcut to mstsc.exe
2. add as params
• /w:2560 (The screen witdth)
• /h:1024 (The screen height)
• /v:hostname

The link will look like this: mstsc.exe /w:2560 /h:1024 /v:hostname
Our expirience was it works not bad. The only thing we noticed was, the client needs more power.

Just a short notice. If you are using Resharper 5.1 under Windows7 and xunit.contrib and your unit tests are not executed anymore in VS2010 you need to check the following:

1. Close all running VS2010 instances
2. Upgrade to latest xunit.contrib for Resharper 5.1
3. If you have xunit.contrib under Program Files\Jetbrains\Resharper\..\Bin\Plugins then move them to
   [Root]:\Users\[YourUser]\AppData\Roaming\JetBrains\ReSharper\v5.1\vs10.0\Plugins\XunitContrib
4. Open VS2010 again and you should be able to run the unit tests in unit test runner of Resharper again.

Hope that helps

I had the problem calling a bash script I got the error:
“syntax error: unexpected end of file”
and
“: command not foundne 2: ”

I created a simple scritp for demonstration

#!/bin/bash

echo "hello"

In this sample we have following error after execution: “: command not foundne 2: ” As you can see, there is nothing on line 2.

The solution was as simple as the problem heavy.  Just execute the following command on the linux system.

dos2unix myScript.sh myScript.sh

And the script will work fine.

The easiest way to spot that the file format is wrong would be:

 head myScript.sh | od -c

 0000000   #   !   /   b   i   n   /   b   a   s   h  \r  \n  \r  \n   e
 0000020   c   h   o       “   h   e   l   l   o   ”
 0000033

So you can see the newlines are done with (\r\n). This can occur if you write the script under windows and moved it to a linux system. After executing dos2unix the head will look like this:

 0000000   #   !   /   b   i   n   /   b   a   s   h  \n  \n   e   c   h
 0000020   o       “   h   e   l   l   o   ”
 0000031

Every “linefeed carriage return” is replaced with a simple “linefeed”.

Did you had the problem your mock must act like a bean? And you could not create the object with the real implementation? And the interface was too large, so you would not create a innerclass for the test? I had this problem too. I solved it with the answer in mockito.

First of all we need an interface. On the interface we define a setter and a getter. Imagine we must be able to get back the value we set.  The sample interface will be quite easy but with a little imagination we know the interface would have a lot more methods. And we don’t want to implement the class in our test.

The interface would look like this:

public interface SetGet {
    void setString(String newString);
    String getString();
}

We create the mock as usual:

SetGetSample mock = Mockito.mock(SetGetSample.class);

Following code snipped shows how to record the value which is set on setString.

doAnswer(new Answer<Object>() {
    @Override
    public Object answer(InvocationOnMock invocation) throws Throwable {
        theString = (String) invocation.getArguments()[0];
        return null;
    }
}).when(mock).setString(anyString());

We need the Answer for recording the input and do not give something back. Because there is a void return value we have to do the answer with the command doAnswer since the when only can be used on methods which have a return value.

We know there is a string used as parameter so we can cast the first argument to String. In other cases we should check if it is an instance of this type. And we set our field to the given value. (Yep, you read correct we need a field in the test class to set the value.

Now the code to get the recorded value:

when(mock.getString()).thenAnswer(new Answer<String>() {
    @Override
    public String answer(InvocationOnMock invocation) throws Throwable {
        return theString;
    }
});

You see, know we use the standard when but we use the thenAnswer instead of the thenReturn the difference is: answer will everytime be executed. Return remembers the value we told them in the when. And the following test will become a green bar.

mock.setString("foo");
assertEquals("foo", mock.getString());

mock.setString("bar");
assertEquals("bar", mock.getString());

I think this is not the solution you should use for a large interface. But imho this is a practicable solution if there is just a set of one or two setter/getter.

Currently I’m in the refresher course of the swiss armed forces in Andermatt. So I get plenty of time to test my new Apple iPad. I have the 16 GB model without the 3G (UMTS) modem. I decide to buy the cheapest model because I think I don’t need much storage on my web tablet. The 3G option was for me secondary because I own a notebook with built in UMTS modem. As a side note you can use the freeware Connectify to switch any pc in to a wlan access point http://www.connectify.me/. Or create a wlan network proxy with an iPhone and the app NetShare (10$) from the Sydia store.

First I will make my coming out as an Apple fan boy. So this article reflects my personal meaning and may not be 100% objective. The physical dimensions of the device are 243mm x 190mm x 13mm. The weight of the iPad is 0,68 kg or 0.73 kg for the 3G model. By the way the 3g models have also an compass and a GPS module. The display is 9.7 inch and has a resolution of 1024×768 (132ppi). The battery live is beyond 10 hours witch is very, very, very impressive. There are only three points witch are semi optimal. The reflecting display is not my favorite option. And if you use the iPad in the Sun in became a little bit hot and shuts himself down. The iBook store of Switzerland only host’s only free book from the Gutenberg project. As you can imagine Nathan the wise from Lessing is note my favorite bed lecture.

My top 5 apps for the iPad are:

FunBox: It is an very simple app. There are 60 buttons each of the buttons play’s a funny sound.
fun box

GoodReader is for my case the best eBook reader for the iPad. I assume you don’t need it if you buy books in the Apple Store. At the moment I buy e-books on the Exlibris web store and print the Adobe DRM contaminated files to a pdf printer (Freepdf) and send it to GoodReader.
GoodReader

NewsRack (thx Dani for the hint) is very nice RSS reader. A very nice feature is the sync with the Google reader. The reader can cash posts and pictures.

PocketCAS is a very nice function plotter. Which is very usefully in my studies at the university of Lucerne
PocketCAS

Dropbox the best way to keep your files in sync.
dropbox

After all I like the iPad and give him 4.5 geeks from max 5 geeks