Think Before Coding

There's an interesting post by Greg Young about Specifications.

I'm currently refactoring some code to move constraints and validation in specification classes, and it really gives a better insight at what is constituting entities and what's not, especially when there are multiple level of constraints (persistence constraints, business constraints...)

Ok, I finished Domain Driven Design yesterday. I think I had no such Aha moment since I read Design Patterns eleven years ago...

I thought I was prepared for it, I had read many things to get maximum info...

I had :

• Read Domain Driven Design Quickly (you can download it)
• Followed threads on the DDD yahoo group
• Peeked at samples on domaindrivendesign.org
• Start to try on my own projects

I had practiced knowledge crunching on my own for long.

But the book go far beyond all that. It has a deep vision of programming on large scale projects, and give really good insight on difficulties that arise when working on complex systems with several teams. These are really precious pieces of advice.

The pattern presentation of the different chapters, even when those patterns are not implementation patterns but team organization patterns is really helpful and clear.

There is not much about implementation details, but it is not a problem. The principles are not tied to a specific technology or framework. Actually this is even a good point, it leaves the book clean from a specific implementation. Implementation books are aging faster.

You definitely should have this book on your shelf.

Ayende proposes solutions for the Select N+1 problem in NHibernate.

Some will say it is a sign that lazy load is the work of the devil. But I can remember the time when people were saying that garbage collectors are evil.

We all would like to have non intrusive data fetching strategy that work 99% of the time !

The problem is not about lazy load or not. It is that you must take care about your data fetching strategy whenever you make a data access.

There is currently no technology smart enough to infer the right fetching strategy.

If someone builds it, this won't be a problem anymore.

If you know about it, please tell the world !

I found through Alvin Ashcraft's Morning Dew a post about CSS tricks Six indispensable CSS tips and tricks I use on every project. Very interesting since it gives some ways to make cleaner CSS integration (I really like the Overclear one, don't need the clear both anymore !!).

But while reading this question came to my mind:

Why do we need to find crazy tricks like this for any single thing we want to do with HTML + CSS ?

This is the sign that HTML + CSS is a complete design failure !

When you want to make something as simple as putting several blocks on the same line... you must use float left, but it does not behave exactly has you expect it to do... When using Silvelight and WPF I had none of these problems. There are surely other problems with theses technologies but I have found an important difference :

• In CSS, the elements decide how the fit in their parent
• In Silverlight, parents decide the layout of their children

And it makes a huge difference. Because in CSS, the interactions between sibling children using very different placement models make it a n*n combination problem. For sure it's not manageable and no browser can handle every case gracefully.

In Silverlight, you obtain the layout you want by composition, and each rule remains simple. No need to use Jedi tricks to obtain what you want.

I want to be sure the title of the blog will not be misunderstood: when I say "Think before coding", I don't mean you should prepare everything before and the start coding like a robot. This is what is called waterfall model, and  and it has always been considered as as non-working model, even by its author.

Programming is not applying a technique. When confronted twice to a problem, the programmer should not use the same solution, but understand what make both problems so close and build something that solve this class of problems. It can be a simple helper function, a small library or a big framework. This is the DRY (Don't Repeat Yourself) principle.

We all learnt how to implement a Quicksort algorithm at school. When was the last time you had to implement it? Personally I use the Linq Sort() extension method and it does the trick for me.

If you have to implement it for a specific reason, it should be because you understood that your problem was not exactly the same as the one handled by existing implementations.

This is why programming is not about technique or algorithm, if you're smart enough, you can adapt almost anything to any language or technology.

There is still one thing that tools and technology can't do for you :  understanding.

Programming IS about understanding

• Understand the problems
• Understand the processes,
• Understand the people,
• Understand the other programmers,
• Understand yourself!

You should have a deep understanding of the problems and processes.

This is the base of modeling, wether it is domain models as in Domain Driven Design or infrastructure framework creation, through Separation of Concerns.

You should understand people.

Because they are the one that ultimately will use what you're building. People are usually hard to understand. This is all the matter about User Experience (UX), but even when programming a framework, you should understand how other programmer will use it and understand it, and how they'll build on it software for other people with their one expectations.

You should understand programmers.

You rarely write your code only for you, and you should write your code so that other programmer have the better understanding of what you intended to do, and what you understood about the problem you're solving by writing this code.

You should understand yourself.

Even when you write code only for yourself, you should understand what you wrote in the first place, as Andy Hunt and Dave Thomas say :

All Programming is Maintenance Programming

Bill Venners: You say in your book, The Pragmatic Programmer (Addison-Wesley, 1999), that "programmers are constantly in maintenance mode." Why?

Dave Thomas: All programming is maintenance programming, because you are rarely writing original code. If you look at the actual time you spend programming, you write a bit here and then you go back and make a change. Or you go back and fix a bug. Or you rip it out altogether and replace it with something else. But you are very quickly maintaining code even if it's a brand new project with a fresh source file. You spend most of your time in maintenance mode. So you may as well just bite the bullet and say, "I'm maintaining from day one." The disciplines that apply to maintenance should apply globally.

Andy Hunt: It's only the first 10 minutes that the code's original, when you type it in the first time. That's it.

But you should also understand how you do things, how you did things, how you changed, and how you will change in the future.  Things are moving so fast that you can not simply stay with your current knowledge and expect it to be sufficient in two years.

Pete Brown noted in this post that the save icon is still represented by a 3 1/2" floppy by most of the application.

But what does the Save button really mean ?

Back in the floppy days, there was no fast persistent storage. To work at acceptable speed, you had to manage everything in memory, the take a few seconds to save at some point. At that time, most of the storage mediums were removable.

Today, things are different. You can't find a computer without a hard disk or solid state drive.

When an application proposes a save action you should understand :

• My application stores my data in memory
• If I forget to save it, my data will be lost !

As Chase Saunders states  in his comment this is what he calls a 'Make It Work' button !

Is this a feature ? It's a curse !

How would work a program without Save button ?

• The document would be persisted continuously on disk.
• It would have a default name (the first sentence ?) in a default location.
• The program would display a list of available documents.
• You should be able to Copy (instead of Save As) your document to another place.
• You should be able to Delete it from its location.
• For complex documents the program would propose versioning or labeling to mark important documents steps.

The world would then be a better place !