assumption of advancement

During a Lunch event organized by the .NET Usergroup Bern at the 7 December 2011 in Bern I will speak about the following question:

Is Software design overrated?

Yes, I know, it’s provocative. And obviously wrong. Really? I’m not so sure. After 10 years as software engineer and some years as software architect I saw too often no design, just a transformation from requirements directly in code. And what is the problem with that?

Interested? So come to my talk, here is some more information. The twitter hashtag will be #dnugbesd.

I’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.

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

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.

Conclusion

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.

When 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.

That 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.