Target audience: Everyone involved in UI development
Urs’ comment: A short book containing a lot of information about basic user interface usability that every user interface developer shoud know. A must read for everyone developing user interfaces.
ISBN: 978-0321344755
ISBN (german version): 978-3-8266-1595-5
This is the presentation I gave at the conference Basta! in September 2012.
Before we can talk about Agile quality assurance, we have to make a step back and take a look …
… at the goals of Agile software development. Our Agile quality assurance strategy should support these goals:
In my current project, we do a lot of refactoring to keep the source code as simple and understandable as possible. This involves a lot of renaming of classes and moving classes between namespaces to structure the code in a better understandable way (here is explained how we structure our code). Sometimes, this results in unit tests not renamed or moved along with the production classes they test.
Therefore, I wrote some NDepend queries that show us these misplaced or misnamed test classes.
This is the presentation I gave at the .Net System Event by bbv Software Services AG in Lucerne in June 2012:
These are the slides with comments of my conference talk at MedConf 2012 in Lucerne: Software development without using open source software (OSS) is unthinkable in today’s world. This holds also for medical technical projects. This presentation is split into three parts. First we take a look at some myths and facts about open source software. Then at how to integrate an OSS into your project so it can be validated against regulatory requirements. And finally, we’ll see what is important when...
Recently, I’ve given a short presentation about pair-programming and the stereotypes people show while pair-programming. As always when talking about pair-programming, there is a discussion how to sell it inside a team to peer developers or even worse to managers. Their killer argument is that two people in front of a single computer result in doubled effort needed to complete software.
Let my show you why this is wrong.
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.
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...
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.
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...