Browsed by
Category: Software engineering

NDC 2014

NDC 2014

ndclogo2014I attended this year’s NDC (Norwegian developer conference) in Oslo. It was a very interesting conference, but as a short summary, it saw something like a consolidation. JavaScript – as some people say in its fourth generation (Simple Scripts, AJAX, MVC-Framworks, SPA) – is finally accepted as a language like C# or Java. Also in the agile world there is no hype anymore about Scrum or Kanban. It was more how and when to use it.
One major topic, which I saw in several sessions was maintainable code. Code has to be readable, clear and simple. This is something, what I try to teach my team-members also since a few years (yes, I was also once a geek who tried more or less any new fancy framework).
The highlights were for me the sessions “Seven ineffective coding habits of many programmers” with Kevlin Henney, “Code that fits your brain” with Adam Tornhill and “Beautiful builds” with Roy Osherove.

Here the sessions I attended:




Beside the fun presentation of Scott Hanselman about JavaScript, there was another last funny presentation: “History of programming, Part 1”. You can watch all recorded sessions on vimeo.
After the conference I stayed for the weekend in Oslo. And yes, it is a really nice place to be and the people are really friendly.

Build your private git infrastructure

Build your private git infrastructure

gitlogoI’ve got for several years a virtual server to put my own projects under version control. I started with CVS, then migrated to SVN and now I’m start thinking to migrate all the old projects to git. This because I like git very much and I use it personally for several years now.
The first question but was: “Not invented here”-syndrom? Why not using github or codeplex or any other public platform which offers git support. Well, some of my own little projects are just not worth it to publish or some of them are not meant to be published. So still existing the question why not buy a private account at github or somewhere else. At this point I was much more interested to see how hard it is to build your own little github environment. So, the requirements are:

  • remote repository for git vcs
  • simple user management
  • website to browse the repositories

Fortunately the documentation for git is currently very good, specially this site helps a lot.

Setup a new repository on the server

First you need of course git installed on your server. The second important thing is to add a new user “git”. You can add the user by command line or through your preferred tool, like webmin. The user git is just a service account and it should not be allowed to log in with this account. So therefore just change the shell to “/usr/bin/git-shell”.

To push some changes to my git-server, I need to initialize the repository on the server. It is a convention that the directory name of a bare-repository has the suffix “.git”. So the command looks like this:

git init --bare Project.git

After that I updated the rights for the created directory:

chown -R git.users Project.git


I decided to use the simplest way to communicate with the remote repositories which is by ssh. To add a new user, you must have his public key (here a short documentation how to generate a new public key). When you received the public key of a new user, it is easy to add it to the allowed users:

cat >> home/git/.ssh/autorized_keys

Browse the git repositories

The next step was to fulfil the website requirement. I chose gitweb, which is just good enough to start and it fulfils my current needs. On my linux (debian) machine, it was an easy task:

apt-get install gitweb

Also the configuration of gitweb was really easy. First I defined a root directory, where I plan to store all my git repositories. This directory I had to specify in the configuration file /etc/gitweb.conf:

$projectroot = "/vcs/git";

The last step was to protect the gitweb site with basic authentication (I use an apache web server, so the following lines are in the configuration file of the gitweb site):

AuthType Basic
AuthName "gitweb"
AuthUserFile /www/
require valid-user

Finally I added the allowed users in the auth.db file.

Using the remote repository

The easiest case is to clone the remote repository:

git clone Project

Another way is to add the remote repository to an existing git repository:

git remote add origin

To get the latest changes from the remote repository you’ll use the command

git pull origin master

To save the local changes in the remote repository you’ll use the command

git push origin master

Quality isn’t a tool–You can’t install it!

Quality isn’t a tool–You can’t install it!

time, quality and money conceptDid you ask yourself why a team in an organization produces very good software quality and another team in the same organization just struggles to get things done and those things are in really bad quality? Interesting is also that for both teams exists the same rules (methologies, procedures, tools, frameworks, etc.). But why could and does this happen?

Some people – mostly managers or vendors – try to distill quality to a recipe. Vendors could sell it expensively (with consulting) and managers can buy it to prove their bosses that they didn’t make something wrong (they used the standard procedures and tools). This whole thing is ridiculous, also because it happens again and again (also with agile practices).

So, you can’t buy quality, neither you can install it in your team or organization. Also it isn’t a tool, which makes the quality (many managers think that frameworks guarantee quality, which is completely wrong). But why can one team be so much better than another one? So we are back to my question at the beginning of this blog post.

The only reason for this difference are the people. The people or some of them in the good team care about their profession. So they keep up-to-date (read blogs, articles, books, etc.) and leads other team members to become better. But the one of the most important things is unfortunately discipline. So you have to improve yourself constantly (keep you out of the comfort zone) and look always for improvements for you and your team. And yes, that isn’t easy.

Once you are one of those people, be aware of being dogmatic, just stay pragmatic but insist on the important principles as long your arguments are reasonable.

And the managers? If they are not able to change themselves (especially the middle management), then it’s up to you to change the organization – it’s your career and life.

Anti-Pattern ‘Validation by Execute ‘n’ Rollback’

Anti-Pattern ‘Validation by Execute ‘n’ Rollback’

Recently in some reviews I saw an anti-pattern. First you have to know, in the code, there was a validation of the data before it was stored in the database. So far so good. But when I looked at the validation code, I saw the following:

public void Validate()

And the persist logic (with some business logic) looked like this:

public void Process()

So, I asked myself, what the Boolean means. Well, here is the method signature:

public void DoProcess(bool bValidate)

Hmm, the code looks quite magic so far and the argument (and the method name) itself is more or less an anti-pattern already. But when I checked the DoProcess method, I saw something more or less like this:

public void DoProcess(bool bValidate)
	using (SqlConnection con = new SqlConnection(connectionString))
		SqlTransaction transaction = con.BeginTransaction();
		// Some business logic here...


Fotolia_20233238_SThe idea behind this code is, if it could be executed successfully, that means a successful validation. If there are any problems during the execution, those problems are the result of the validation. The execution itself wouldn’t be a problem after a successful validation (now I need a drink…).

Doing it better

It’s easy to find bad things, but it’s sometimes harder to do things right. But in this case, the better way is easy. First, you have to separate your business logic from the data access logic. This means following the separation of concern principle.

The next point is, that you’re able to validate your model. So put the logic where it should be. If you use a domain model, the logic to validate an entity has to be on that entity. Or if you have a table module approach, the logic to validate an entity has to be on the corresponding table module.

Side effects

There are also other problems with this anti-pattern. There are some side effects with the data.

As you know, transactions should be as short as possible to prevent lock problems with your data. But if you have combined the business logic and data access logic, your transactions are much longer than needed. To make it worse, this anti-pattern forces you to do it at least twice.

There are reasonable use cases for dirty reads: For example fast searches. In this case you accept dirty reads and you don’t want any locks on your data in the database. Normally, the chance to have a dirty read isn’t that high, but with this anti-pattern the chances to get a dirty read are significantly higher.

Who should make decisions about technologies?

Who should make decisions about technologies?

Stay on courseOne of the biggest problems of software engineering companies in Switzerland is currently to get new software developers. To get new employees there are several points as for example salary, environment, career possibilities and technologies. The last point looks easy but in reality it isn’t that easy. Why are essential technology decisions (like languages, frameworks, application servers or big libraries) not only made by developers? Why does the management mostly make those decisions?

In this blog post I try to see the technology aspect for creating software from different perspectives. Those views based on experiences and talks I had during the last ten years.


As expected the technology used for the software is for the customer irrelevant. But for him counts the working functionality and some non-functional requirements as usability or performance.

Product owner or product manager

The product owner neither is interested in the used technology directly. He’s mainly interested to get the functionality in time and in budget. But he’s also interested to get a good quality of the product, else he’ll receive complaints from the users (of the customer).

IT department

The IT department who has to operate the system is somehow interested in technology. They usually don’t like new technology. One reason is for sure "never change a running system". Another reason is the needed knowhow for every technology. They have to concern the cost of maintaining that knowhow.

Software Architect

The software architect (and I am currently one) is special. When he’s interested in technology, he should take responsibility in the project. If not, you have an architect who lives in the "ivory tower". Mainly the architect should concern more about structure, integration of components or other systems, maintainability and quality.

Human resource management

In most of the companies this part get lost. Today it is hard (specially in Switzerland) to get new developers. So, new and fancy technologies make a job or company more attractive. This means, that the human resource management is interested to use up-to-date technologies.


Well, most developers care about technology. Specially younger developers more because they had the possibility to try those at the university or in little projects with their colleagues. For those developers technology is essential for the daily job and to be motivated. If they have not the possibility to use new technology they will leave the company after one or two years. And that isn’t cheap for the company.


Today most companies use some self-made frameworks. One reason they spent money to create one is the fear of creative developers who want "to fulfil themself". This means for the management that those developers are out of control and create overcomplicated things with a lot of different technologies. I think this fear is unjustified today, but in the days when everybody could call himself a developer it was not only rightless.
But the management has the difficult task to concern all the roles I described before and make a reasonably decision.


It seams there is a fight between the developers and the management who should make decisions about technologies. It is important that the management has all the information it needs and can concern all the risks of an introduction of a new technology. But the management has to be open to all the facts and arguments and should not presume to make a decision based on old experiences, assumptions or prejudices.
If the decisions are too offensive, then you have at the end quite everything in the IT department (for example all java application server products). On the other hand, if the decisions are too defensive, then you will have a stagnation. This will be very expensive to solve because you have to spend a lot of many to get up-to-date again.