Let computers be dumb so that you can be smart and smart, so that you won't be dumb

I recently found that this could be a kind of unofficial motto for our software product. But it might as well be the same for many other software products.

Here's the story:

you're a software tester, writing a test case, either a good old word table, or a java script or a Test Director script.
How many times did you think:

1. This test case is so dumb that even a computer could write it!
OR
2. This test case is so smart that only a computer could write it!

These are 2 of the true powers of the computers:

1. being so dumb and dull to calculate endless combinations of values without pausing at it (how many coffee breaks do you really need as a software tester every day?)
AND
2. at the same time being so smart to find meaningful combinations for special cases where you would have abandonned finding that- case-that-anyway-may-never-occur or most certainly where you would have not assumed its mere existence.

Yes, I know, in the end, computers are not-so-smart items. They are only smart because we feed them the right algorithms (thank god, we may still have a job forever!). But being able to exploit that dumbness to write down necessary but really uninteresting test cases or to let algorithms backtrack to death until they find the solution is really a bliss.

The only curse is that you have to feed them right:

-what are the rules they are supposed to work on (the model in model-based testing)
-how you want them to be smart, because this has a meaning only for you

So their true power is only realized if it's not too much work to set-up the data and if you can find algorithms that won't need too much customization to solve your specific problem. I think that most of the time, this is achievable. The trouble is that you may need to be really smart to do that!

I had to use Google's software somehow,...

And here I am again finding that old blog that I created 2 years ago,... Blogger has evolved a lot so I decided to give it a start again with the messages I published since last september.

Object modeling to code: associations as first-class citizens

I had this feeling for a long, long, long time. I always found that object modeling in UML helped giving birth to what Eric Evans calls the "ubiquitous" domain language (in his book "Domain-Driven design"). As a consequence, I thought that object programming languages were really missing an "association" type of attribute that would convey the kind of meaning you have in your class diagram.

This was just the kind of idea that could be somehow implemented someday in java10 after extensive academic research (that was certainly going on the subject - isn't it the classical way of promoting new programming languages?).

Anyway, all this was just day-dreaming and practically speaking I was more or less mentally mapping the object business model to my java classes. Alternatively, I used Together's java annotations to describe the collections.

But we are now facing a though challenge that many people must have dealt with in many places (the question is: who and where - please email me,...) : how can you evolve an existing graph of objects from an XML file that is supposed to represent its next state. This is not so easy because:

• if an object is not present in the XML anymore, it has to be removed from the object graph everywhereit is used, and due exceptions must be sent if it shouldn't be allowed. Failing to do that properly would cause nasty errors in our object database
  
• changing the state of objects can have various impacts on other objects in the graph and those impacts can trigger a "chain-reaction" from the bottom of the object graph to the top

My first idea was to have a metamodel of my application describing all the relationships between the objects: who is referencing/composedof who through a collection (well, our first idea was to use an Observer design pattern throughout the code).

Then I would use this metamodel for several things:

• generically produce the XML equivalent of the business objects
• computing differences between the "state before" and the "state after"
• sending the differences to our internal "EventBus"
  
• generically having the business objects subscribing for the changes that are applicable to them
  
• let the business objects do their job and send other events for the possible impacts
  

Getting down to the details, this design seemed to fail for a fundamental reason: you have to declare some knowledge twice in the application:

1. when you create your classes, they have relationships through pointers even if all the semantic of the association is not declared
2. when you create your metamodel, you add more information to the existing one

And this week-end, I had "the" idea: why not add the missing information to the code itself?

So I decided to create Association classes that would satisfy all our requirements for minimum redundancy, maximum robustness and distributed behavior among classes:

• ZeroManyAssociationList/Map (implementing List/Map)
• ZeroManyCompositionList/Map
• OneAssociation
• ZeroOneAssociation
• ...

And those association containers would be observers to the objects they contain.

• when a business object is removed, all the containers are notified and can cleanly remove their reference to that object
• a OneManyAssociation can check that the lower multiplicity is respected
• a Composition association can now be used generically to know what to do in case of the removal of the owning object
• an association can be constructed with its owner and warn him that its content has changed
  
• ...

There would be more things to say about this design and how to implement it properly but I just want to end with 2 drawbacks:

1. The type of a ZeroOne or a One Association is not the type of the referred object. It could be interesting to use a dynamic proxy here, however I don't think that it would work with JDO (the database API we use)
2. Business objects diagrams with Together will be unnecessarily cluttered by those container classes.

Yet, as for any design where you have to decide between conflicting constraints, I think that if this solves elegantly our need for a more robust object model, this is really worth the price.

Recruitement best practises

There's so much "soft" in software.

I have again the opportunity to recruit somebody for our development team and I think I should improve our practises in that field as in any other. I could say that recruitment is a crucial activity for a startup company such as ours.

But for what company is it not critical?

So, what are the best practises for software development recruiting? I found recently some litterature about it :

• an article in JoelOnSoftware book ("Joel on Software: And on Diverse and Occasionally Related Matters ThatWill Prove of Interest to Software Developers, Designers, and Managers,and to Those Who, Whether by Good Fortune or Ill Luck, Work with Themin Some Capacity" - maybe the longest book title in history,...)
  
• and a book by Joanna Rothman ("Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People") which I did not read yet.

From Joel Spolsky book, I will add a few things to my interviews:

1. a very simple set of criteria: I am looking for 2 qualities "smart" and "getting things done"
2. the "impossible question" as a mean to challenge those qualities
3. a new "let's write some code" exercise.

The later one I did for myself : "reverse a linked list" in java. With 3 levels of difficulty:

• get a new List object when calling the operation,
• reverse in place
• by iterating on the list,
• by using recursivity

In itself, it is really not difficult (it shouldn't be). However it really reveals development abilities:

• use of names conventions
• use of test-driven development
• care for limit conditions : null input list, empty input list, list size = 1
• use of exceptions
• comments (not so easy to comment that code,...)
• incremental approach to development
• use of interfaces (should it work on List also?)
• this can lead to patterns questions: "what pattern would you use to add that functionality to a LinkedList?"

I don't know how many interviewers really make developers code during an interview, but how would you hire a personal cook? By tasting the food and making sure that the kitchen is clean and tidy, wouldn't you?

Protect your GUI thread

He (Heinz) was right about it. We were in serious trouble not tohave restricted access to our gui components from other threads than the Swing thread.

Fortunately, our design is not so bad. Last year, I had the goodidea to use an EventBus to communicate between the business layer and the gui layer (or even between the gui components themselves). As a result the correction was quite easy and came in the form of a pattern:

• the component does not register himself but registers a proxythat implements the same "EventReceiver" interface. When receiving abusiness event, the proxy forwards the call but by invoking aSwingUtilities.invokeAndWait().

This really solved the freezing bug that we had only observed once on one of our consultants computer.

However, the developper I was working with was dissatisfied with the solution. He would have preferred a "implement an interface" or"extend an abstract class" kind of pattern that would force thecomponent to be executed on the Swing Thread.

It made me think of 2 things:

• why Swing does not throw an exception when a gui component is not executed on the Swing thread, since it is so dangerous?
• could we use our components factory to insert another proxy that would check that any method call made on a GUI component is checked against this error?

I am going to investigate dynamic proxies for that matter (I hope not to have to resort to AOP,...) and will blog more about it (Santosh's blog http://www.jroller.com/page/santhosh seems to be an interesting start).

Just another thought came on top of my mind: using dynamic proxy involves the use of interfaces. Why don't we have our gui component simplement business interfaces exposing only the events they receive/send? Once a JTree is constructed, what other components need to see it as a JTree? Being a JTree after all is more a matter of implementation about how I want to see some kind of info.

That's all for today. The London exhibition was great and the testing market in UK seems interesting for us. I also felt very comfortable around English people, I don't really know why; maybe some kind of ever politeness floating around? I also met a fine magician, which is another subject I am also passionate about,...

Training that counts

We had today a java training with Dr. Heinz Kabutz.

There would be many thing to say about this, but let's just summarize a few.First of all, Heinz is a really, really fine person that made mediscover more about South Africa that I ever knew of. On top of that, my first impression that I was asking for one of the top javaprofessionals around the world was really confirmed.

Then the training in itself went largelly beyond my hopes:

• Heinz spotted a potential problem in our GUI code that, in fact just had been observed, and had bewildered us. We now think we now why and how thiskind of bug happens.
• I told about Heinz about how I wanted to set-up a cache for some objectsof our business model. He came, in ten minutes (all developers were totally amazed around the table!) with a really elegant and generic solution ( He would now say "general" solution, since Java5 has messed up his previous vocabulary)
• We had very nice tips and explanations about garbage collecting, exception handling, etc, etc,...
• No training is ever enough without hard work afterwards to experience it practically; however much hard work will be avoided and re-thought with this top-class training.

At last concrete objectives!

Today, I had the opportunity to do it the way I thought it should be done,...

Dealing with software is something, dealing with people creating the software is another. At our company, we set up an incentive policy aimed at motivating our troops. Thus, the classical "objectives" assigned to each one. I feel (and also read) that incentives must be used with care and that setting up motivating objectives is not an easy task.

So, regarding the individual objectives (there is also a reward program for company achievement) I took the following hypotheses:

• never set objectives that would make people compare to each other. Objectives are personal, you are only fighting against yourself to achieve your goals.
• a developer wants (needs) to improve itself
• if it is good for the developer professional practise, it will be good for the product
• the team member should select objectives that he likes
• no more than 4 to 5 objectives should be selected
• they should be concrete enough for me to make the evaluation at the end of the year
• the evaluation will always be a "give good marks to a nice face"exercise so the team members will need to show their best profile toget good marks

All in all, we had 3 individual sessions today, and the result were very interesting:

• people had the freedom to select from the 20 or so objectives that I proposed (+2 objectives that I imposed, see below)
• so I could learn more about their real interest (for instance I alwaysthought, and feared, that the main interest of one of them was network management. It is not at all!)
• the selected objectives will clearly benefit the developer
• the selected objectives will clearly benefit the product
• the 2 objectives I imposed were well accepted (better planning abilities and self-teaching through reading)
• I am confident that at the end of the year, we will be able to assess the achievement as objectively as possible
• because there are few objectives, it is possible to make huge progress in those
• my objective to give them 100% bonus because they performed ok will be achieved!

As a result, I also started creating a "good points" document where Iwill register every single achievement along the way. And I evenstarted collecting for one of them that had not been through an"objective setting" session yet.

And I feel good when I can give "good points"!

eXtremeProgramming applied

I had the occasion last friday to practise an eXtremeProgramming session, and found it really interesting.

We knew what the problem was.
We did a simple analysis by slicing the problem into 5 tasks aimed at the main classes we had to evolve
We started by coding the tests, thereby finding very interesting test cases
We implemented the code, doing pair programming, forced by the situation because we only had one computer !
We refactored the code were we could see some commonalities

The result was that we ended with very few compile errors (thanks to pair programming)
We had very few tests errors, the bar was almost always green.
One time we launched the whole application. It had an exception showing us that a limit test case was missing (initialization)

All in all, we coded in less than one day most of a feature that would have taken at least 2 days otherwise (that was the foreseeing).

I think this was easier because there was no significant architectural issue in the way.

The morale is : dont be trendy, over-enthusiast or negative but just give it a try !

MDA approach and Software complexity

"There is no software bullet"

This famous article from F.Brooks (1986) is always relevant today. We may think that there will be silver bullets in a near future but if they existed today, developing first-class information systems would be so easy !

Saving of my blogs on freeroller,...

Thursday July 03, 2003

Finishing the metrics component, considerations on checked exceptions

My objective today is to finish this component once and for all. Then I will document the use and deployment next week.


--------------------------------------------------------------------------------

I am still wondering about the checked exceptions debate. I feel I can hear arguments from both sides:

-pro-runtime exceptions : avoid catching exceptions without doing anything valuable
-pro-checked exceptions : formally declaring what could go wrong when using an interface.

I may incline for the runtime camp, but I think the exceptions that can be recovered from by interacting differently with the interface should be at least documented (and then may be checked exceptions).
In UML2.0, there is a notion of Protocol. It is not enough to declare as contract what are the operations/ parameters/ pre-postconditions that the interface has, sometimes, the order on operations calling and parameters values are also very important. A protocol state machine can then be linked to an interface (or any classifier) in order to declare more precisely what can be its behaviour.

The conclusion of this is that: if an exception thrown by the interface contains enough information for the caller to resume the protocol execution, then it could be a checked exception.Eventually, in my case, practise is what I need,... code with both runtime and checked exceptions and the rules will follow. ($entry.pubTime) # [Edit]

Tuesday May 20, 2003

Context switching


--------------------------------------------------------------------------------
I would like to note some of my ideas regarding "Context Switching".
What is it ? It is a common fact observed by any consultant or programmer : it is quite hard to work on something, being interrupted, then to resume on the work to do.
The questions that arise are :

How is it possible to resume faster ?
Is it possible not to be interrupted ?
On the other hand is it possible to completly switch context, so that private life is not parasitized by work ? And many more question that I dont have time to write right-on !
(2003-05-20 16:30:00.0) # [Edit]

Friday May 16, 2003
Streamlined Object Modeling



--------------------------------------------------------------------------------


Here is a message I wrote on the french XP mailing list about this great book :



--------------------------------------------------------------------------------


Bonjour à tous,


Puisque l'on aborde le sujet des livres, je souhaiterais vous faire partager ma dernière lecture :


Streamlined Object Modeling: Patterns, Rules, and Implementation
de Jill Nicola, Michael Abney et Mark Mayfield
Cela sort au départ un peu de la programmation puisqu'il s'agit plutôt de patterns d'analyse objet (objets métiers, régles métier).

En revanche, lorsqu'il s'agit d'implémentation, le livre aborde une question qui me paraît très intéressante :


Quand une régle métier porte sur 2 objets (la possibilité de les associer par exemple) qui porte la régle?

C'est à ma connaissance, le seul livre qui donne des régles explicites sur le sujet. Globalement, la réponse est connue de tout développeur objet (consciemment ou inconsciemment):

celui des deux qui possède le plus d'informations pour vérifier la régle.

La vraie force du livre est de poser la question pour chacun des 12 patterns de base qui sont présentés.
J'ai trouvé, à la lecture de ce livre (en particulier les premiers chapitres), que ce qu'est "penser objet" était assez bien expliqué et ça fait donc partie des choses que j'aurais sans doute aimé lire un peu plus tôt (en aurais-je compris tout l'intérêt ? -cf les Design Patterns).
D'autre part la connaissance des 12 patterns est un excellent framework conceptuel pour analyser les objets et régles métier à implémenter.

A bientôt pour des réflexions plus XP, quand j'en utiliserai autre chose que les tests unitaires,...




--------------------------------------------------------------------------------

Creation of my own blog today. I just gave in to the fashion,... but this may prove useful!