Friday, April 29, 2005

Empirical vs Deductive

When you are programming, there are two different mechanisms I've seen developers use on Agile projects. One is deductive and the other is empirical.

In deductive programming developers first examine the model, design the piece they need to build, and then program it.

In empirical programming developers dive into the code, build something and then refine it until it looks reasonable, eventually settling when the code is good enough for them.

I've seen both ridiculed - on as over design and the other as hacking.

Which is better? The best people I've seen have been able to combine these methods. Through a combination of empirical and deductive programming they arrive at the best answer. Discussion leads to better experiments, which leads to better understand which leads to better discussion...

Friday, April 22, 2005

Some simple techniques for modelling

Just a reminder about simple techniques for modelling - figuring out where your behaviour belongs.

Before you start:

UML diagrams. Not with all the detail. Really connected squares. Write down all the objects you're dealing with, connect them all, arrange them. Find two or three combinations that you think might contain the behaviour. Try a few that you think won't and see what you learn. Take no more than 30 minutes.

While you're working:

Blank CRC cards. (Courtesy Brian Marick). Use blank index cards to represent your objects (don't write anything on them.) Use the cards to talk about your objects and responsibilities. Not writing on them will force you to use spatial relationships and be clearer when talking.

Refactor at the end:

Sequence diagrams. Just the important methods. Look at the lines are they all flowing from one or a few objects? Are there objects that don't do anything? Look to move some the behaviour.

Reminder: Modelling is about helping you write code. Keep it in that role. If it overshadows coding, you're not doing anything useful.

Thursday, April 14, 2005

Your code is as good as your team

Remember, the upper bound to your code quality is the quality of your team. You cannot make your code better unless you make your team better.

Understanding double dispatch is great for you, but if your team doesn't understand it, it will soon disappear. In order to make your code better, you must interact with your peers.

Interacting with your peers requires two things: 1) You must show people stuff you have learned. 2) You must listen to what others have learned. These discussions will make you better.

Fun fun fun ...

Eric Evans has come out and visited us for a week. He's doing an assessment on how our domain model is impacting our development. He wasn't imposed on us by upper management, he was brought in by us. We're always looking to get better and he has some fresh ideas about old (objects) things.

For me, the most important thing about having Eric come on our project, is not the assessment (although valuable) but rather the way conversations change for a while. The entire team has had little conversations about him and his book. The discourse has been pushed up a notch, hopefully the team pick it up a notch.

Sunday, April 10, 2005

Heuristics for optimization

Where to look (in what order):
  1. Data transfer layers (Business Logic -> GUI), (Database->BusinessLogic). Often you're pulling too much or too little back.
  2. Unoptimized algorithms. Often you have O(n^3) algorithms based on naive implementations. These are easy to pull apart.
  3. Database retreival. Look for low hanging fruit like full table scans.
What to do (in what order):
  1. Play with the granularity of what you return. When you transfer large things you usually need less information per item. When you return a few things you usually need more information per item. Your code will need to handle this diversity.
  2. Play with how you've done calculations, and composed your data.
  3. Add indexes to your database, use a DB specialist to help with your queries.

What tools you need:

  1. A profiler gives you macro views of where your code is running. I have found no other way to get this information. They give you a place where hunches and hypotheses start. However they tend to stop being useful after that - you are still to distant from the code.
  2. Println. I use it heavily. Actually I wrap it in a Profiler class, but generally it tells me that between these two lines of code it took x milliseconds. Using binary search you can track down where the code is slow.

Friday, April 08, 2005

Testing Smells

Martin Fowler recently published a blog on a problem he was testing:

http://www.martinfowler.com/bliki/ErraticTestFailure.html

Gerard Meszaros (a Calgary resident who I consider an world expert on implementing test-driven development) has categaorized many of these smells in his upcoming book.

You can get a preview here:

http://tap.testautomationpatterns.com:8080/Test%20Smells.html

Something to remember...

If I ever join another in progress waterfall project (knowingly that is):

  • I must shift my critical perspective back to waterfall.
  • I must not evaluate how the waterfall process does against an agile perspective.
  • I must go back and relearn the waterfall process and all its principles.
  • I must learn how the team has adapted the waterfall process for success.
  • I must phrase my criticism in terms of the process we are working with.
  • I must find my improvements in terms of the process we are working with.
    I must understand it will take me time to learn (again) and understand regardless of the number of years of experience.

Process is a game. It forms the rules of how you play together and gives you a framework in which to discuss when, how and where you will do things. It does not guarantee success or failure. Dedication, reflection, people management and hard work determine success or failure.

However, some games are more fun for me. Other people, I know, like other games.

Saturday, April 02, 2005

Toplink In Memory

The first release of the in memory database for toplink is available on sourceforge. I've put all the files in CVS. Please bear with me while I figure out sourceforge.

The following caveats hold for the project:
  • There is no documentation
  • There are project files for eclipse
  • Only simple queries are supported (e.g. no parallel stuff yet, no outer joins, no anyOf)
  • I will add to it as our current project grows
  • No warranty provided
  • I appreciate and will attempt to include all donated functionality that includes tests

Anyway, It is now available through the cvs repositories at source forge. I'll try to make more available.

Main page:

https://sourceforge.net/projects/toplink-in-mem/

CVS here:

http://cvs.sourceforge.net/viewcvs.py/toplink-in-mem/

Concurrency Patterns

We're starting to think about concurrency in the system. This is my first link:

http://c2.com/cgi/wiki?CategoryConcurrencyPatterns