Freekshow

October 16, 2009

Transfer news

Filed under: Personal — Freek Leemhuis @ 12:42 pm

resume

Working for Logica as a consultant for the last three years has been quite a journey. For a number of reasons, (I won’t bore you with them here) I felt the need for a new challenge, and when the opportunity arose I decided to join IHomer. As of the 1st of November I will become the tenth participant of this group. Delighted as I am with this prospect, I am also sad to leave Logica. There’s some tremendously talented people there, and I have enjoyed my travels with you all.
I would like to express my gratitude to Logica, working with them has brought me many things and it´s been a great place to work.

 

One of the perks of working for IHomer is, obvious, working from home on a regular basis. I´m really looking forward to this, I´ve created a nice little home office and I´m sure I´ll see a lot more of my girls.

I have commited myself to deliver workshops for Logica later this year, so for my colleguaes: there´ll be opportunities to catch up.

October 15, 2009

On the nature of community driven events

Filed under: Community, Devnology, Events, Learning, Speaking — Freek Leemhuis @ 5:45 pm

 
 

lowscore Last week I was involved in organizing a Scala workshop, and from the feedback we received it was notable that some of the issues that were mentioned were more to do with the expectation of participants than with the actual content.The average rating from the evaluation for this event was 7.3 (on a scale from 1 to 10), and while that might seem decent it is dramatically lower then scores for our previous events.Some of the feedback that was provided was very fair. For example, it was mentioned that the tempo could have been higher, and it could have. The typical participants of Devnology meetings have way more smarts and passion about them than any other group I have participated in, so we need to become better at tailoring our meetings accordingly.

Another point of criticism we received was that the facilitators did not seem to know all the ins and outs of the subject matter. This in my opinion is a result of the position we take in organizing these types of events: there should not be one expert explaining to the rest everything there is to know, but rather a situation where there’s enough preparation done to go through the material, and in the process learn from each other.

Under these conditions, chances are a lot bigger that it will be an interactive event, with active participation.

This way, you get to know the attendees, learn what knowledge and experience they can contribute, possibly even beyond the event itself. The meetings will become more lively and interesting, and more in line with the ideas behind the Unconference.

Having an expert capable of explaining everything on a particular subject may not improve the experience, expecially if you lose a level of interaction. We will therefore continue to encourage members of the community to take on a subject and create a learning events that is geared toward learning together.

Obviously, this will only be a success if the more knowledgeable participants are aware of this and willing to share their skills and ideas. If you are aware of points being missed or if you have information or skills that can contribute, one way to react it to sit back and be bored. It might however be better to ask yourself this question: what have I done to improve the experience of this event for some (or all) of the other participants?

Let me paraphrase what this guy said:

Ask not what your community can do for you, ask what you can do for your community!

I don’t mean to sound obnoxious here and I certainly don’t want to put people off from attending. What I hope to achieve with this post is to make our viewpoints regarding these issues clear and hopefully prevent misunderstanding in the future.

 jfk

 

Please feel free to respond!

July 17, 2009

DDD Course… coming to a theatre near you very soon!

Filed under: Community, Domain Driven Design, Events — Freek Leemhuis @ 7:23 am

There’s a great opportunity to immerse yourself for 2 days in Domain Driven Design. On the 14th and 15th of September Gregory Young will speak about the essentials of applying DDD concepts in the design and implementation of your application. This is a very practical, hands-on event. Places are limited, so sign up now at http://www.jworks.nl/

You can see Greg in action in this recent presentation at QCon

May 26, 2009

Speak up!

Filed under: Learning, Personal — Freek Leemhuis @ 1:46 pm

Lately I’ve been involved in a lot of workshops and meetings and one thing I noticed is that when a question is asked in a group of developers, it’s very often the younger attendants that reply first. Sometimes there’s a crop of bright young developers who really know their stuff, but other participants with years of experience just seem to be less vocal. In discussing this observation with a colleague last week it started to dawn on me: it’s not that the younger guys are brighter, they are less inhibited because they can still get away with an answering incorrectly.

If you have been a developer for 8 years or more, and someone asks an innocuous question (what is a function?), you probably know the answer. However, suppose you give the wrong answer, in front of a crowd of fellow programmers. Your reputation is on the line. Better keep quiet, and let the young guys go at it, right?

The best way to learn is to be wrong occasionally, even if it means being painfully wrong sometimes. As a programmer, there’s so many things that you ’should know’ that it’s near impossible to have all this knowledge readily available. There’s never a better learning moment then these. Being painfully wrong means being wrong once. Being silent can mean being wrong many times. So, mainly as a reminder to myself: it’s ok to be wrong. It’s not okay to stop learning. As the lady says, sometimes you just have to feel the fear and do it anyway.

April 10, 2009

More DDD

Filed under: Community, Domain Driven Design, Learning, Speaking — Freek Leemhuis @ 4:12 pm

The second part of the DDD workshop contained a modelling session (modelling out loud!), which I think helped a lot explaining some of the concepts.

picture-030

I’ve attached the slides for the second day below.

ddd-day2 slide deck

April 8, 2009

Spreading the word

Filed under: Community, Domain Driven Design, Speaking — Freek Leemhuis @ 7:33 am

Eindhoven, 7th of april 2009, Workshop Domain Driven Design.

ddd_eindhoven

 

Smiles all around yesterday as each participant received a copy of the DDD bible. I think a few heads were spinning toward the end of the evening trying to take it all in. It is hard to cram a lot of the ideas in just a few hours, especially if there’s good discussion.

The slide deck can be found here, and the assignment here.

Second part on thursday, see you all there!

April 2, 2009

Code Fest 01

Filed under: Community, Devnology — Freek Leemhuis @ 4:00 pm

Some night that was! I was well impressed with the people that showed up, discussion and banter flowed between them based on a shared passion for technology and interest in other people’s approaches.

codefest1

On this first Code Fest (all in Dutch, apologies) we had implementations of that old classic, James Conway’s Game of Life. On the night we had demonstrations of implementations in Flex, Erlang, Haskell, C++, Alloy, Java, CosMos and the Google App Engine. It certainly had my head spinning, and with what I thought was a cracking atmosphere we couldn’t have asked for more. We have invested a lot of time and energy in getting this thing of the ground, but yesterday evening alone was worth every bit of it.

Thanks all for a great evening.

On a sidenote, I was playing with this domain model to describe Devnology, and thought I’d share it here:

model

 

Geek as I am, it helps me focus and explain what I think we can achieve : Building a technology agnostic community by organising events that have high interaction between passionate developers. Enable interaction between academia and the software development industrie (software craftsmen, if you like).

With result like yesterday and the software testing event at TU Delft things are shaping up. Come and join us at our next meeting!

February 20, 2009

Devnology!

Filed under: Community, Devnology — Freek Leemhuis @ 9:24 am

The cat is out of the bag! It’s been a long time in the making, but finally…. coming to a theatre near you very soon… It’s…..devnology

Our first event is planned for the 1st of april (no joke, I promise) and is now open for registration. Do come!

February 14, 2009

Software estimation

Filed under: Estimation — Freek Leemhuis @ 9:44 pm

seatlemonorail

I have been trying to improve my estimating skills recently, I have always found it hard to do but I thought I’d share the things I have picked up that can make it somewhat easier to deal with.

Breaking up is hard to do

A question you get asked a lot from managerial types is: read these documents, then tell me how much will it cost to build this thing? It doesn’t have to be accurate, just give me a ball park figure. Are we talking three hundred, five or maybe eight hundred thousand euros?

Don’t do it. Even if you have an idea (it’s probably closer to twelve hundred), don’t say it. Don’t trust your ‘expert opinion’, because it is a very unreliable tool for performing a realistic estimate of this size. You can be way off. And if you are, it will come back and bite you in the a**.

The only way to get a reliable estimate is of course is to decompose the requirements into a work breakdown structure. The smaller the chunks, the better your estimate will be. It is so much easier to estimate a small size, and the process of breaking up large tasks into smaller ones will give you a much better idea of what needs to be done. I usually try to break down tasks into subtasks that are no larger then a day’s work.

What can possibly go wrong?

When preparing a quote we often need to align different estimates, and usually my estimates are higher then anyone else’s. Still, I’m usually convinced that mine are the more accurate :-)

One thing that I picked up from reading Steve McConnel’s excellent book on Software Estimation is the Program Evaluation and Review Technique (PERT). This technique has been developed to counteract the natural tendency to estimate according to best case scenarios.

It turns out that if you ask a developer for a single point estimate, and then ask him to give a best case and a worst case scenario estimate, the single point estimate is in most cases very close to or equal to the best case scenario.

The PERT technique will counter this effect by asking to provide best case and worse case estimates, and also the mostl likely case estimate. A formula is then used to compute an expected case like so:

Expected Case = [Best Case + (4 * Most Likely Case) + Worst Case] / 6

Still, people tend to be optimistic when creating ’most likely’ estimates, which is why Stutzke has presented an slightly altered variation :

Expected Case = [Best Case + (3 * Most Likely Case) + (2 * Worst Case)] / 6

If you are new to estimating, you will find that using this last formula will give you higher estimates. You will also find that they are much more accurate.

How long did you say this was gonna take you?

I didn’t, since I’m not the one that is actually going to build/test/document the system. Someone else is. So the estimate should be based on how long the task is going to take the person that is actually going to perform it.

I see a lot of estimates created by senior developers, and they can be a bit arrogant in their evaluation of the tasks. “Huh, I’ve build something similar on a number of occasions, it’s not so hard. This will take me only xx amount of time.”

Tough luck for the poor schmuck that is going to perform the task and has never done anything like it before. The estimate can not be wrong, can it, since it was done by someone with greater experience! So why is it taking so much time to implement this feature?

Keep it mean & lean, okay?

Finally, commercial considerations will often drive a sales manager, keen to make a sale, to give a few pointers as to what type of estimate he needs. “This client has money to burn, so don’t be shy”. Or, more likely, “We need to make this sale so keep it lean & mean, okay?”

Don’t let any of this influence your estimate in any way. Your job is to create an estimate of the size of the work that is involved. An estimator needs to provide estimate that is as accurate as possible, and the manager can decide, based on the accurate estimate, what to do about pricing or other considerations to make his pitch.

January 31, 2009

Learning

Filed under: Learning — Freek Leemhuis @ 9:06 pm

As a consultant, it’s sometimes difficult to find a new job that is a good match with your skills. We preferably want to learn on the job, but the person doing the hiring wants to find someone who already knows all the stuff that is required to do a good job.I think it was Noel Tichy who developed the model of concentric learning zones that can be used to illustrate the point.
zones1
If you want to learn, you need to get out of your comfort zone, but just enough to stay in the learning zone. If you cross over to the panic zone you’ll be thrashing rather than learning. So if I’m looking for a new assignment, I want to use skills that I do not yet fully master. Most people that are looking to hire a consultant however seem hell bent on finding someone that has demonstrated a mastery of the required skills, preferably for a number of years. They want to make sure the person they hire can do the job, and previous experience is what they perceive as the ultimate proof that the person is a good match. If the person can perform the skills required within their comfort zone, there’s no risk of them straying into the panic zone.

Requiring X number of years of experience for a language, platform of framework is not effective. Experience does not equate level of skill, and as David says, as long as applicants have 6 months to a year of experience, consider it a moot point for comparison.

There’s some strange job postings that I’ve browsed through the last month or so.

4 years of experience with c# 3.0? Who are they hoping to attract, Anders bloody Hejlsberg?

And how about this one: looking for unit testers. Wat are they? People who only write unit tests all day, and they are not allowed to actually write code?

Some of these job postings contain clues on how ignorant the company is on the matter. Someone really needs to tell them what they are looking for is a good software engineer, and rather then matching precise experience they would be better of looking at different attributes that point to good candidates. 

I like Jeff Atwood’s approach on finding the right candidate:

Have the candidate give a 20 minute presentation to your team on their area of expertise. I think this is a far better indicator of success than a traditional interview, because you’ll quickly ascertain..

  • Is this person passionate about what they are doing?
  • Can they communicate effectively to a small group?
  • Do they have a good handle on their area of expertise?
  • Would your team enjoy working with this person?

Please note that acquisition in response to this blog post might not be appreciated

Blog at WordPress.com.