cross-post from bbv blog

When software projects grow both in age and size the developers often struggle with the structure of the code. It gets more and more difficult to find the class you have to change for a new requirement. In this post, I’ll show you how we organize our code and how we derive our structure directly from the requirements.

.NET, Agile, Architecture, Clean Code, Methodology, Test Driven Development Agile, Architecture, Clean Code, TDD

Over the last couple of years, I’ve done a lot of pair programming. Pair programming inside my team, at customer sites, in coding dojos and in my open source projects.

Pair programming is really a great and effective experience when performed by an pair of developers knowing how to pair program.

Unfortunately, you cannot just put two developers in front of a single computer and expect them to perform perfectly from the start. Pair programming has to be learned. Both developers need to learn the difference between being the driver (the one holding the keyboard) and the navigator. See here for details.

During my pair programming sessions I encountered some recurrent stereotypes, which I list in this post.

Agile, Methodology Pair Programming

Pair programming – two developers working together at a single computer – can result in better software written faster, but only if you know what you do.

Pair programming is not just sitting together and code as you would when being alone. Unfortunately, this is what most developers practice – resulting in a painful and ineffective experience.

To get most out of pair programming, you first have to know your setup.

Agile, Methodology, Test Driven Development Pair Programming, TDD

Some time ago, Patrick Smacchia (NDepend lead developer) offered me a NDepend Pro license to play around. NDepend is a tool providing a lot of features. The feature that impressed me from the very start is visualizing dependencies. Not just dependencies from classes to classes, or assemblies to assemblies; no from everything to everything. Like for example all assemblies that use somewhere the method Foo of class Bar. It works for assemblies, namespaces, types, methods and fields.

But, what’s all this fuss about?

Keeping a code base and its design as simple as possible over a long period of time is very difficult. It happens just too quickly that we loose the overview of how things are sticked together. And this is the moment when NDepend with its quick and easy dependency visualization comes to the rescue.

.NET, Clean Code, Software, Why I like ... Clean Code, NDepend

cross-post from www.bbv.ch/blog

In the last two years I gave over a dozen courses and presentations about test driven development (TDD). One question, I get asked almost every time, is how to refactor code while keeping up the TDD rules:

• write only production code if there is a failing test requesting it
• have no more that one failing test at once

Test Driven Development Refactoring, Test Driven Development

Lately, I wrote quite a lot of acceptance tests. I simulate that the application is started-up and perform all features requested by our customer to make sure that they work as expected. In order to make these tests fast so that they can be run on every commit to the version control system, I simulate all interaction with the environment of the application: views, database, file system, registry, share point and so on.

To get the most out of these acceptance tests, I want to fake as little as possible. And here comes the Rebind feature of Ninject into play. I can bootstrap the application as in production and then replace all components interacting with the environment by simple calls to Rebind.

.NET, Why I like ... Acceptance Tests, ATDD, Ninject

This is the start of a series of posts about Clean Code. I’m going to pick some topics from my cheat sheets about Clean Code and Clean Test Driven Development and explain them in more details.

Today’s topic is

Nested code should be more specific or handle less probable scenarios than unnested code.

Clean Code Clean Code

In my projects, we use a lot of open source libraries like Ninject, xUnit, Machine.Specifications, FluentAssertions, StyleCop, Moq, statLight, AgUnit and of course the project I lead myself: bbv.Common.

These projects are really cool. But sometimes of course, we need something that they do not (yet) provide. Like adding Machine.Specification support in FluentAssertions or a faster runner for xUnit unit tests under silverlight with AgUnit and statLight.

Therfore, we download the source code and try to contribute the features we need. And we try to follow the coding style of the existing code so that the project owners are willing to merge our changes into their code base. But this is almost impossible!

.NET, Clean Code, Sourceanalysis Coding Guidelines, Open source, tools

These are the slides along with some comments from a presentation I gave lately in the bbv .Net System boot camp – the yearly education week of my division in my company.

Once upon a time, Agile Software development came to our software development country.

Like a monster, Agile software methodologies scared the hell out of us. Suddenly, we had to find ways how to build software so that we could keep up with the high rate of change, just-in-time requirements and a sacrificial offering – a product increment – every two weeks (our Sprint length).

The way we were used to build software was not up to this task. We were used to dig a big hole of new functionality and to build something great over months. The structure of our source code and our engineering practices were no good to match the Agile monster.

So we had to come up with some new “weapons” to stand a chance:

Agile, Architecture, Methodology Agile, Architecture, ATDD, Design, DI, DRY, SOLID, TDD

cross-post from bbv Blog

This is a list of actions that Scrum Masters at bbv Software Services AG have applied successfully in their teams to improve performance (= how much gets done in an amount of time). Please note that these actions were created to respond to specific problems found in real world projects. They may not be applicable in general in any situation.

I’d be happy to read your experiences and feedback in the comments section.

Agile, Methodology Agile, scrum, ScrumMaster, team