Compiling? - No thanks!

Compiling is a waste of time! Jeff Atwood from Coding Horror formulates it like this:

'Death by a thousand 10 second delays.' (DNR 232)

Jet Brains seems to have the same opinion. Their newest pre-relaese of Resharper 3.0 (EAP) has a new feature called 'Solution Wide Error Analysis'. With this feature you basically do not have to compile any more to check for compilation errors! Just forget about Ctrl-Shift-B!
This allows an even clearer separation between developing and building a solution:

• Develop with VisualStudio/ReSharper
• Build with your favorite automated build tools (NAnt, MSBuild, MyGeneration, CodeSmith etc...)

By the way, in the Java World eclipse provides the same comfort with background compiling.

Check your Spellchecker!

The german dictionary in Thunderbird has quite an interesting preference:

Jack for President!

Damit:

And here some facts about Jack:

• If Jack Bauer was gay, his name would be Chuck Norris.
• Jack Bauer has been to Mars. That's why there's no life on Mars.
• Every mathematical inequality officially ends with "< Jack Bauer".
• Jack Bauer was conceived by torturing the other sperm until they gave up the location of the egg.
• Superman wears Jack Bauer pajamas.

 

Cathedrals and Software

We build software like cathedrals: First build, then pray!

-Gerhard Chroust

Getting old

I was just reading my self-prescripted daily dose of blog-posts, when the truth caught up with me and destroyed my carefully-crafted self-image!

It all started when I stumbled across this post.

The post is quite interesting, since it breaks with the current Rails-hype (is this a sign, that Rails has reached the top of the hype cycle? I hope not, I just ordered my first Rails-book from Amazon…)

The background of the above post is Twitter… and now I get to the point of my post: I don't get it! What is this Twitter all about?

I desperately try to be hip and trendy! I am eagerly using delicious, gmail and google-reader but obviously this is all in vain. I have to face the hard truth: I am not of the Web-2.0–Generation!

About Signal-To-Noise

In the context of Domain Driven Design and Domain Specific Languages the Signal-To-Noise-Ratio of a Language/Programming-Environment is getting more and more attention lately.

I like the following statement on Object Mentor:

Clarity of code is a signal-to-noise ratio. We need our code to be as concisely meaningful as possible (not as cramped and crowded as possible, and not unnecessarily spread out over many pages). Whatever size provides the most accurate and quickest reading for trouble-shooting and enhancement is the best size.

In my opinion in the perfect programming environment every single statement a application developer is writing would have direct business meaning. All infrastructural concerns should be handled by the environment, and the developer should not have to care about it.

At the same time, the code the developer actually does write should be very expressive, and therefore might well be elaborate. It is the goal to minimize ‘non-business-code’ but it is not the goal to write as less code as possible.

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.