Browsed by
Category: Good practices

Speaking at the .NET Usergroup Zentralschweiz

Speaking at the .NET Usergroup Zentralschweiz

dotnetzentralI’m holding at the .NET Usergroup Zentralschweiz a short talk about "Know your warm-up", see my last blog post. I’ll explain what I developed exactly and how I train new employees with this warm-up. I will also demonstrate the sample application which a new employee develops from scratch.

Come to see me speaking the 24. November, 18:00 at the following address: bbv Software Service AG, Blumenrain 10, Luzern, 1. Stock.

Thanks @danielmarbach and @ursenzler for having me.

There is a wrap-up on the site of the .NET Usergroup Zentralschweiz with some pictures. The slides are now available.

Know your warm-up

Know your warm-up

NHL in Berlin (LA Kings vs. Buffalo Sabres)

I was this month in Berlin at the NHL match between the LA Kings and the Buffalo Sables. Half an hour before the game you could watch both teams doing a warm up session (see photo). They practice the techniques, moves and collaboration which they will use during the game.

After the match I asked myself, how do we do a warm up? How were we introduced into the development environment of our current employer? After how many hours or days had we have to be productive? Fortunately I realized this gap already and I developed a training kit for a duration of a month for new employees for my current employer.

The warm-up

I recognized that the learning curve is quite steep for new employees and so it is a risk for the company to give them immediately productive tasks. Therefore I developed a training program for a duration of a month – the warm-up. During this training the new employees learn the following:

  • Infrastructure of the company
  • Frameworks and tools
  • Responsible persons for the framework and tools
  • Guidelines and good practices (not best practices)
  • Realize software with the frameworks and tools based on uniformed requirements

Before the main part of the training starts there a two days of school where I teach them in traditional manner the architecture, the framework and the workflow component.

The main part is the development of a little insurance application with the same tools, frameworks and libraries which the new employee has to use also in the production environment. For this little application I developed the requirements and also a guideline for the responsible person to teach the new employee. I also implemented the application as a reference solution.

The insurance application itself is designed that the first tasks are easier than the last ones. This way gives the new employee constantly success experiences and he will be motivated to go on and have fun with the whole development environment.

And yes, having fun is important to be motivated. Working doesn’t mean that it isn’t allowed to have fun.

Teaching and documentation aren’t enough

There are several slides for the two school days and there are two papers for the school-application as well. Even for the whole framework exist a lot of paper. But this stuff is more or less useless if the new employee hasn’t anybody who is there for him or her. As in agile practices, feedback is the most important thing. Only the contact person, who is responsible for the education, can give the exact feedback which the new employee need. This because the responsible person knows where the new employee currently stays and what the context is.


We had already several new employees which did the warm-up successfully. The feedback of the new employees was also very positive because they could learn the whole development environment in a protected manner and try out things without any risk.

Grooming your code base

Grooming your code base

Fotolia_32643902_SWhen you’re doing Test Driven Development (TDD), it’s in the process: Red-Green-Refactor. Refactoring doesn’t only mean to improve your new code, it is also important to make your existing code nicer.

If you are a .NET Developer, then you should have the Visual Studio Add-on ReSharper. With this tool you get a marker bar which you see right hand side of your editor. On top of this marker bar you have a little square which shows the worst found item (error or warning). In our company we introduced recently this tool and we also introduced a new rule: "Check-in only green code!"
This rule means that the square has to be green: no errors and no warnings are allowed in the current file.

Reality check

New tools and rules are nice, but we know all the pearl of wisdom "A fool with a tool still a fool". You aren’t immediately a better software developer when you do TDD or using ReSharper. You have to know how to use it.
All of us have in our code base a lot of legacy code, I mean really bad code and a remarkable collection of anti-patterns: god object, Swiss army knife, etc. and the ReSharper shows tons of warnings and errors. Now you can start to fix that code base, but be honest, that will be a project of its own. So, should we just resign or try to improve our code base?

Grooming your code base

When you know Scrum, then you know also the term grooming the product backlog. It is essential to make progress and to do the right things. The same goal we should have with our code base. We want to implement fast new features or change quickly with no risk breaking current behaviour.
The word risk here is critical: Don’t try to improve your code base at once, it’ll be a huge task (or even a project) and maybe you will fix things which will change in the near future. So, the right way is step by step or just following the boy scout rule: "Leave your code better than you found it".
If you doing TDD, then try during the refactor step to groom your code base. If not, then just clean up the code you touch and make it green (ReSharper marker bar). Don’t try to fix a whole class, just improve the needed methods.

Make the field a bit more green

In a classical brownfield project, there will be just bad legacy code. So it is important to plan some bigger refactoring tasks to make the code base better and decrease the technical debt. If the code coverage is very low then those tasks are a good start to increase the number of tests and the code coverage. But be aware of those tests: They could document wrong behaviour as correct.

Branch or not to branch

Branch or not to branch

Fotolia_25836922_SThat is a question? Yes, it is a question which you should ask yourself before to create a new branch or reuse an existing branch. There are other practices or possibilities to create new features in an existing software, which I will show in this blog post. Also there are some issues with branches and modern software engineering practices, which I will discuss here too.

First I show you two techniques how to avoid branches: Branch by abstraction (BBA) and Feature toggle.

Branch by abstraction

If you never heard of branch by abstraction it doesn’t mean implicitly that you have never done it before. It is a quite simple approach: First create an abstraction of the existing code which you want to change (or refactor). Then create a new implementation of the abstraction. After you created the new implementation, declare the old implementation as obsolete (or deprecated). After a while you can delete the old implementation and maybe you could even remove the abstraction. All this actions happen in the main branch (or trunk). There is no need to create a new branch for that.

It sounds quite easy and you don’t loose the features of the continuous integration. But there are some issues with this technique: It isn’t always possible to introduce an abstraction after a released version. And it isn’t very beautiful to deploy duplicate behaviour to your customers when they should know yet the new implementation.

Feature toggle

Another technique to avoid the creation of a branch are feature toggles. You create the new feature in your main branch (or trunk), but you disable the feature by a toggle in your configuration file until the feature is ready to use. Maybe you have even a database driven menu management system or a complex user right management system in your application. If so, then you maybe use already feature toggles.

Also this technique has the same issue as the branch by abstraction approach: During you develop the feature and you have to deploy new versions of your software, you will also deploy the current unfinished version of your new feature. Only the toggle prevents that the customer see your unfinished feature. So it is important, that the customer can’t manage those toggles.

Isolate as little as possible

Branch by abstraction and feature toggle are techniques which help you to avoid creating branches for little and fast changes or adding new little features. But if you aren’t sure if you’ll brake something or adding side-effects then a new feature branch would be the better solution.

The argument that you have to create a feature branch because you couldn’t be sure that you can do all the work until the release deadline, is not always a good reason to create a new branch. Ask yourself why there is a time problem. If you have the possibility to improve the process with the project  manager or with the product owner, then try to refine the features, optimize the task assignments in the team to deliver a feature until the deadline.

Do frameworks kill design skills?

Do frameworks kill design skills?

Software design is one of the most important skills a software engineer should have. But what is software design exactly? If you search for a definition you find something like this:

Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view. Source: Wikipedia

imageSo, a developer has to design based on a requirement the solution or in other words the source code. There are a lot of decisions to make, for example where to put which logic.

Who is interested in software design?

For the customer the design of the code isn’t important. For him the existence of a feature and its performance are much more important. In other words design isn’t part of a specification (functional or non-functional requirements).
Also the project manager or a team leader might not be interested in software design. For them the productivity and speed of the developers are much more important. And the customer satisfaction is even more important.
So, who is/should actually interested in software design? The developer and his boss. Software design is about having a plan and a structured solution. It is important to implement the right thing in the right way (effectiveness, efficiency). But it means also, that the source code becomes maintainable, readable and extendable. All this capabilities are important when you have to read or touch existing code. And it is about money too: If the existing code is maintainable, then a change could be done much faster and cheaper.

Full stack frameworks

A lot of companies try to simplify the software developing process by introducing a full stack framework. A full stack framework is a framework from an UI layer to a data access layer. The reason of doing this is to make some important decisions just once upfront of any new application. Some of those decisions are the number of layers, the testability or the location of the extension points.
When a developer uses a full stack framework, he has to live with the software architecture of this framework. The framework dictates him where he has to put which logic or where he has some liberties.

But such a framework does help not very experienced developers to produce big or complex applications. And there is another point: If you have to code very little, you do normally no big design upfront, you just code (with or without TDD). But if you know you have to build some bigger application, then you do for sure a design. And there is a problem with full stack frameworks: They do a lot for you and you have to code just a little for a big application: Now the developer might think "I have to do such little of code and the frameworks define where I have to place the code, so there is no need to design".

This rigidity of a full stack framework can lead to developers who stop asking themselves, how a good design might look like because they are "trained" to believe that the guidelines of the framework are correct and complete. In other words, they become code monkeys. So, after a while you can obverse that a lot of anti patterns appear:

Prevent the kill of the skills

So, are full stack frameworks an excuse when you lost your design skills? No. You can produce also bad code without any framework and you can produce very good code with a full stack framework. Just ask yourself those questions before you write code (the list isn’t complete):

  • What business problem do I have to solve?
  • Where do I place which responsibility?
  • How could I test the code?
  • What of the new functionality has to be reusable?
  • What should be extendable (YAGNI…)?


A matured full stack framework is very powerful because it increases the productivity and the speed of the developers.
But a full stack framework can be dangerous for young or not very experienced software developers: It is very easy and comfortable to create applications but it is also easy to place the code in the wrong class or forget to make a proper design.
A full stack frameworks can act like a catalyst to create bad code because it is much easier but is never the reason why the developers don’t design their code.

How can you prevent such non-designed code? Pair programming is one of the best ways how to do it: One experienced software engineer, who acts like a mentor, and another software developer.
Code reviews are useful, but they are not always a funny thing for both sides: The developer has already "done" his job and the reviewer has to criticize the result. So, there is a lot of potential of frustration on both sides.
Another way is to follow the boy scout rule: Always leave the code cleaner than you found it.

But the most important thing is, don’t stop designing when you will or have to use a full stack framework. A full stack framework doesn’t substitute any skills of developers, it makes them maybe more productive.