Wednesday, March 28, 2007

About UnitTests

Here is an interesting article, that describes how to migrate an existing NHibernate-application to the new NHibernate release 1.2.

The migration is described in a nice how-to guide. The different steps are set up as small incremental refacorings. The end result of all the refactorings is the migrated application.

What I think is remarkable about the article is, that it is taken as a fact that there exist exhaustive unit-tests for the application: The author does not even state that the existence of unit-tests is an assumption or precondition for the article. He just takes the existence of unit-tests for any application as the most natural thing on the world!

I hope the article reflects a trend that using UnitTests is becoming a mainstream practice.

The article nicely demonstrates the advantages of (good) UnitTests:

  • UnitTests are your first safety-net. They provide immediate feedback: You always know if your changes have the desired effect and if they have undesired side-effects.
  • UnitTests are a development-tool that increases productivity: They enable fast-paced iterative. secure and focused development cycles and refactorings. The UnitTests show the state of the system at any time. They point you to the problems of the current iteration cycle, so that they can be solved before you start focusing on the next iteration cycle. This is very important for a conscious and structured process. It also encourages you to divide all the work into small manageable steps, which is always a desirable approach.
  • UnitTests allow you to minimize the time that your system is in an inconsistent state. First they indicate that the system is in fact in a inconsistent state, which is the premise for any improvement. Second they point you to the root of the problem and allow you to fix it as soon as it occurs, ideally before they have effects on the development process (like co-developers that are prevented from working or testers that are going crazy ...)
  • The more code you write the bigger gets the risk of drifting into Programming by Coincidence! UnitTests are one way to fight this risk, because they show you immediately and relentlessly the effects of new or changed code. If you are not using UnitTests you have to find another way to actively fight this risk (no, hoping and praying is not enough)!

And for all those who still not have seen the light (including my current employers) or are actively resisting to get enlightened: It seems you are more and more swimming against the stream... denial only works to some point, after that Darwin stops by to prove that 'survival of the fittest' still rules us all.

Monday, March 26, 2007

How to Change the World: The Art of the Start Video

[from Roy Osherove]

Really awsome speech by Guy Kawasaki:
How to Change the World: The Art of the Start Video.

You have to watch it!

Sunday, March 25, 2007

Architectural-Patterns vs. Design-Patterns

[from Software Engineering Radio]

Architectural Patterns are concerned with strategic aspects of a system. They have a global impact on the whole implementation of a system.

Design Patterns are concerned with technical aspects of an implementation. They have a local impact on specific parts of the implementation of a system.

Architectural Patterns are on a higher level of abstraction than Design Patterns.

Tuesday, March 20, 2007

About SOA

This is definitely a very funny page:

SOA Facts.

My favorites:

  • One person successfully described SOA completely, and immediately died.
  • SOA can write and compile itself.
  • On the eigth day, God created SOA, then SOA created Rock and Roll.
  • Dante has a special level in hell for consultants whose resumes do not say SOA.
  • Implementing SOA for the first time is the triumph of imagination over intelligence.
  • Implementing SOA for the second time is the triumph of hope over experience.

Jeremy D. Miller -- The Shade Tree Developer : MVP Summit Recapped:

This is a very interesting post:

Jeremy D. Miller -- The Shade Tree Developer : MVP Summit Recapped: Linq for Entities, MonoRail, and Shameless Name Dropping.

I wholeheartely agree with the following points:

  • No infrastructure code in my business logic classes: Get rid of the noise!
  • I don't want to codegen my domain model classes.
Monorail seems to get a lot of attention lately, I definitely have to take a closer look at the Castle Project.

Monday, March 19, 2007

About writing code

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

– Brian W. Kernighan

Monday, March 12, 2007

About Frameworks

Use it, but dont let it use you.

Rod Johnson about J2EE

Also Known as: Tell, dont ask!

OO-Principle, originally by Alec Sharp

Sunday, March 11, 2007

About Holes

Step Number 1 to get yourself out of a hole is: Stop digging!

Richard Campell, DotNetRocks #215
Related Posts Plugin for WordPress, Blogger...