Posted by Serge Beaumont mid-afternoon: March 5th, 2008
Sequential steps thinking leads to systems that are relatively complex, frustrate users and are not robust in face of unforeseen circumstances. Adopt the goal-oriented, unordered checklist style, and save yourself and your users a world of hurt!
What went before…
Last year I found out how someone can get me angry using only Post-Its.
Posted by Serge Beaumont in the wee hours: October 18th, 2007
Nowadays the Task Board has become one of the basic agile tools, and it features lots of stickies. As I was looking from my Task Board to my desktop I had an idea: all I needed for an International Task Board was a desktop background and a desktop stickies app!
Posted by Serge Beaumont around lunchtime: May 16th, 2007
We’re not just off, we’re rolling on!!
Episode 1 was the first of a series on performance, Episode 2 is the first of a series on Scrum. Grab the episode directly here, or even better, subscribe to one of the feeds at http://podcast.xebia.com
Posted by Serge Beaumont in the early morning: May 9th, 2007
And we’re off! We’ve started a podcast geared towards Java, Agile and anything else we find interesting in our line of work. In that sense it has the same focus as this blog. If you like the blog, we hope you like the podcast too!
You can find everything on http://podcast.xebia.com/, including three RSS feeds with different quality files: Enhanced, High quality and Low quality.
The first edition is online, where colleague Vincent talks about the number 10 and 9 of his performance top ten.
Subscribe to get the casts as they come. We have already recorded some sessions that are currently in post-production state. One notable item is an interview with Scrum creator Jeff Sutherland. So subscribe, check out the podcast, and give us feedback on our podcast email!
Posted by Serge Beaumont in the early evening: April 25th, 2007
This blog entry is another insight that came out of talking with Jeff Sutherland when he was our guest at Xebia.
Pictures can say more than a thousand words, but they can also confuse things. One of the things I didn’t get is Type C Scrum, and the only thing I had to go on was a paper by Jeff, and a picture that is generally used to visualise types A, B and C. I now realize that the picture actually made it more difficult for me to understand Type C…
It’s supposed to be the most advanced and difficult form of Scrum, and Jeff explained how Type C works at PatientKeeper. Type C is actually a Scrum in a Scrum in a Scrum, or (as Jeff put it) a wheels within wheels thing.
Posted by Serge Beaumont mid-afternoon: April 11th, 2007
After a hard days’ work, it’s nice to have dinner with a thought leader to restore the batteries. Jeff Sutherland – father of Scrum – was with us for a few days to give a Scrum training and to be a speaker at our annual Gartner session. During a pleasant dinner the conversation ranged from Jeff’s life on the road and project experiences to politics, bad wine snobbery and – of course – Scrum. (BTW, talk about an inspiring speaker: after his keynote I could hardly contain a loud YEEHAAW-YES!-YES!-moonwalky thing… Highly recommended 
)
I was wondering about the buzz on a fourth Scrum role: I had heard that there’s a new “Manager” role to be added to Scrum, and asked him what it’s all about. Jeff explained that the incentive came from CMMi level 5 compliance: for this level the new role was needed, but I now understand that in general this role is important for Scrum adoption and implementation in an organisation.
Posted by Serge Beaumont in the wee hours: August 4th, 2006
We’ve put up a new article on the Articles page. Summary follows:
The article Factories are about abstraction, not creation told what factories are for, and when they should be used. This article will show different ways to implement factories. The complexity that is needed for a factory implementation depends on the required flexibility and how much effort is needed to construct a complete instance:
- when should it be possible to configure the factory repository: can it be coded and remain fixed for a release or should it be configurable at runtime?
- does the client of a factory need to influence the subclass choice in some way?
- how complex is the algorithm to determine the correct subclass?
- how difficult is it to construct a valid instance of the required class?
Posted by Serge Beaumont around lunchtime: July 19th, 2006
We’ve put up a new article. Summary follows:
Polymorphism is the main mechanism to create maintainable object-oriented code. Client code uses other code through an abstract interface, and as long as we don’t break the behavioral contract, we can change the implementation behind that interface at will.
You will only achieve real maintainability if client code has dependencies to other code through an abstract interface and nothing else.
Unfortunately creational logic will – by its very nature – break this rule. When you create an instance, at some point you will
need call the constructor on the actual implementing class. This creates a dependency that prevents you from changing the implementation transparently, effectively cancelling the advantages of polymorphism.
The solution to the creational problem is to protect the abstraction by hiding the creational logic from the client code. Dependency injection is the ideal solution, in this case the client does not use creational logic at all. But in its turn the injecting code needs to create real instances.
This article is the first of a series of three: this article will illustrate how the creational problem manifests itself, the second will deal with some advanced implementations of creational code, and the third will deal with dependency injection.
Posted by Serge Beaumont in the early morning: July 13th, 2006
Through the years, I’ve noticed a correlation between experience and the complexity of the software we produce.
There are three phases. In the beginning you don’t know much, so you create simple things: you simply don’t know how to do complex things. The second phase is when you learn techniques that allow you to tackle complex problems (patterns, patterns everywhere!). In the second phase you use every trick you know, because you can. The final phase is that you know when not to use advanced and complex techniques because the cure would be worse than the problem.