Geekfest is good for the soul!

So, this post was originally going to be all about Google Guice.  After writing for a few paragraphs, I realize that if I ever got to Guice this would be the longest blog post of all time.  So, tomorrow you get Guice and today you get Geekfest!  "What the heck is Geekfest?", you might ask, or maybe not, but you should.  Yes, I am sure there is some concert or conference or some such wonder by that name...but, we do not care for such things.  Geekfest in this conversation is a few hours that the team that I work on puts aside every other week to encourage, even require, developers to take the time to keep their skills up-to-date and share their experiences with the group.  Think of it as on-the-job training that even the veterans need.  I have been on so many teams that do not make learning a priority.  On most of those teams, training would be provided only if there was an impending need.  This is a disastrous way to do things.  First of all, we as developers absolutely must stay current if we want to stay employed.  Furthermore, we as organizations must keep the skills of our development staff current if we wish to be able to compete in the marketplace.  Now, we can simply expect developers to keep themselves current.  We can put in the job description that a developer must advance the knowledge of the team, or stay current with market trends or run a freaking marathon...but that does not make it happen.  Even for those developers who are self-motivated enough to do these things on their own, what percentage of them go around to the group and make sure everyone knows what they know?  Not very many, I can tell you.  We geeks tend to be made up of a high percentage of the less-than-social crowd.  A lot of people just do not feel comfortable doing this.  So, what happens to that knowledge?  Maybe it gets utilized, maybe that person puts it to work on a project or more likely it wastes away.

Managers and team leads: You have a responsibility to ensure the best performance of your teams.  You have a responsibility to facilitate the growth of those around you.  Do not forget this.  Yes, I know that you have to get the project done.  Yes, I know that it is already 3 weeks behind schedule (that is your fault too, but we will talk about that in another post).  None of that matters.  Admit it!  Two or three hours every other week will not be noticed as even a blip in your time line.  What do you get out of this?  You get a team that feels like their development is important enough to you and to the organization to make it a priority.  Have you ever felt that way?  Does your organization put you first?  Make it happen for your employees, it makes a world of difference.

Maybe all that touchy-feely mumbo jumbo is not enough to convince you.  So, let us take a look at the basic rules that will allow us to realize some actual benefit for the team:

1. Thou shalt not skip the 'fest, no matter how busy you are...only actual emergencies qualify as an excuse for absence.
   
2. Thou shalt not investigate anything directly related to project work during the 'fest.
3. Thou shalt share your experiences with the group before leaving the 'fest.
4. Thou shalt capture the results of your investigation at some level on the 'fest wiki.

Now, that isn't asking all that much is it?  Do you see where the increased benefit comes in here?  No, well let me wax poetic on that for a bit. :)

We have already addressed the fact that, if left to their own devices, only a fraction of of the group will actively expand their horizons and that only a fraction of those will share a fraction of what they learn with the group.  Wow...that is a lot of fractions and a lot of lost knowledge.  What makes Geekfest different?  Everyone learns what everyone was learning!  I scream, you scream we all scream for...oh, never mind.  Even the thickest headed of management will see the benefit of this.  If a team of six goes into a room and spends two hours investigating different topics then each one shares what they learned, what do you get?  Let us do a bit of arithmetic. 6 people do 2 hours of work and share that with the team of 6...hrrrm: 6 x 2 x 6 = 72 hours with of gathered knowledge.  You invested 12 man hours.  Need I say more?  Now of course our implementations of this will be less than perfect.  Still, this is a great deal for an organization  What will happen if we let developers do this on their own?  We have to start dividing instead of multiplying.  Oh, and those developers who were learning on their own...do you think they stop because of this new found study time?  Not from my experience.  If anything, they are spurred forward in their endeavours. This is a big fat win for everyone involved.

Now, you have read this.  It all makes perfect sense to you.  How could you not have seen this before?  So, what are you going to do about it?  If you are a manager or team lead, schedule the meeting now.  Do not wait.  You and I both know it will get swept under the table.  If you are a developer, suggest it to your boss.  If you do not feel comfortable being that forward then send them a link to this post.  Tell them your friend that works over at the major competitor said his team has been doing this for months and how much they are gaining from it.  The entire industry will be all the better for it.

technorati tags:Agile, Software, Development, Learning, Training, Guice, ROI

Domain Driven Design...revisiting good ol' fashion OO.

A few weeks ago I attended the Gateway Software Symposium put on by the guys from No Fluff Just Stuff. While I was there, I got the opportunity to listen to Venkat Subramaniam talk about domain driven design. I almost skipped out on it for something else, but Venkat's knack for speaking is always good for an enjoyable lecture at the very least...so I went for it. As expected, Venkat gave a great talk. While the content convinced me even further that DDD is essentially a repackaging of old ideas, it also made me realize that some of the things that have bothered me about some of the ways we utilize patterns, and how many of them are even enforced as standards. This is just evil. Some of this stuff is so ubiquitous that we just accept it as perfectly normal. How many of you have worked on a project that looks something like the one below (hopefully with a few more classes)?

I know that I have...and not just one. Now, mind you, this project is trying really hard to have good practices. It wants to reduce tight coupling...heck, it might use DI a la Spring or Google Guice. What it does more than anything is insult our intelligence. When I see a project like this, it makes me wonder why all this poor User has been scattered all over creation. I feel like this project is trying to be a self-describing code cookbook. It practically begs you to right a BO, a controller, a DAO, a model object and a factory for every class you create. Now, I know we all hear a lot of people telling us not to put business logic in with our model. I say, "Bullocks!"...put logic where it belongs, wherever that may be. Sometimes our objects want to know how to do things for themselves. Not only that, but why are we all so afraid of maintaining state in our applications? Yeah, it comes with some complications...but sometimes those complications are worth it and even appropriate.

I want us to start taking a hard look at what the users are saying about how they work. Listen to what they are doing...how they are working now. You probably had a professor use the old analogy of the bicycle and how all bicycles have a few attributes and actions that are common to them. That same professor probably talked about 10-speeds and how they have some extra attributes and actions that a plain old bicycle might not. I often wonder what this professor would think of seeing:

int gear = bicycleBO.getCurrentGear(tenSpeed);

bicycleBO.setGear(tenSpeed, gear+1);

I will tell you exactly what he would say:

tenSpeed.upShift();

I am not advocating that we go back to the days of gigantic all encompassing classes...where a bicycle knows how to do anything that one might possibly want to do with it. I mean, I might want to hang my bicycle from a tree, but that does not mean that my bicycle should know how to climb trees. I am merely saying that we need to stop worrying so much about applying patterns across the entire landscape of a project and start thinking about the design that fits best.

technorati tags:domain, driven, design, java, patterns, misuse