Thursday, June 23, 2011

Technology decision matrix (Using Ubuntu, Redhat & Suse as examples)

Technology decisions are difficult and it often seems that architects and developers resort to throwing darts to determin which solution they should use for many problems. A tool I like to use to help figure out the best solution is a simplified decision matrix. When used fairly, this simple tool enables us to quickly and visually determine which solution is best given our success measures.

As an example, lets pretend we're going to pick a server platform. In this, effort, we have some specific things we care about:
  • security updates - Does the solution have automatic and timely notification of security issues and an automated way to patch the server.
  • modern versions of applications supported - as a criteria, which version of ngnix does the package support
In the interest of simplicity, we're going to assume that other essential factors such as cost, compatibility with specific software and other issues have already been applied.

We then take this information, select a number of candidate solutions and put them into a table as column headers:


Then we take our criteria and add them as rows

Security Updates   
modern applications   

Next, we do the hard work of scoring each solution according to our criteria.

Security Updates331
modern applications (ngnix version) (custom install) 0(8.54) 2 (.8.54 AND 1.0.4) 3

As we can see, applying different score makes evaluating the "best" solution easy to comprehend. The risk is that we really should establish scoring criteria ahead of time or we'll end up fooling ourselves by scoring things according to a bias we may have toward a particular solution. Obviously this is an oversimplified set of criteria, but it should easy to see how to extend this to more complicated scenarios (just add more rows and let excel be our friend).

I'd be curious to hear other tools and techniques to do this and would welcome some comments with better/different solutions.

Wednesday, June 8, 2011

Hey GOF, It's not a good metaphor unless you can drop it on your foot

I read a recent article about the importance of writing physically. Fundamentally, the author says that "writing physically" means writing about things you can drop on your foot. This means a lot to me because when trying to write software, I'm constantly translating ideas into mental pictures of physical things.

To this end, I think the Gang of Four have done a disservice to the software industry by pushing design patterns that have no representation in the real world. Worse than this, pushing UML as a way to represent and communicate software design leads to situations where everybody THINKS they agree, but they in fact all are thinking about completely different things.

As a specific and very simple example, lets look at the Command pattern. Reading the explanation is very dense and rife with jargon that is specific to the particulars of Object Oriented programming languages. For folks who need to read the explanation, who typically are new to OO programming, these explanations just make things more complicated.

My simple explanation of the command pattern is: You a rich person who has an entire staff of servants who all speak different languages. Instead of trying to tell them what you want, you've instructed someone to build "command boxes" that have a button you can press and will then instruct your servants to do what you need them to do in their native language. This is the command pattern in a nutshell.

With my physical example, we can now have a good discussion about how to implement this in software. Using the UML and other rigmarole on the oodesign site, it's nearly impossible to even have a coherent discussion because there is nothing in the real world to talk about. When living in the world of ideas, it is very dangerous to assume everyone sees the same pictures in their heads as you.

Tuesday, June 7, 2011

Coaching a winning team

As the spring soccer season is winding down, I'm reminded of a saying that I heard the AYSO national director of coaching say. I was at a conference and a roomful of hopeful coaches were quizzing him on what they could do to be more effective coaches. A variety of people proposed things they did to win more soccer games and his response was: "If you want to win soccer games, go find the better players". This was meant to be a rebuke in this context, but I wholeheartedly agree with the assertion.

A coach or strategy CAN influence the game and when two teams are equally matched with talent, they can make the difference in the outcome. However, regardless of what the herd of ego-centric coaches might try to tell you, good coaching does nothing but unlock potential that already exists within the team members.

Effective coaches are not the ones are making things happen, they are the ones that make sure the right team is available to make things happen. They also make sure that the proper resources are available, that some sort of planning is being performed, and that any obstacles are removed or avoided.

Picking the best players is more important than picking the best coach.

Sunday, June 5, 2011

The Joystick Soccer Coach

I am a passionate soccer player and youth coach. One thing I find difficult to resist, but even more difficult to accept when I see other coaches doing it is the notion of being a joystick coach. In the beginning of my coaching career, it was hammered into my head that soccer is a "players game" and to develop players, a big part of coach's job is to give them freedom to make mistakes, present opportunities to learn from them, and challenge them to make good decisions on their own.

I get IMMENSELY frustrated when I'm coaching a U6 team and my opposition has TWO coaches on the field active giving instructions to the kids. While these teams are often much more effective at scoring goals, it really makes player development difficult because the other team has a pair of 30 something men explaining how to take advantage of the situation to score more goals.

Coaches, limit your instructions on the field, else you'll end up with robots who will likely be ambivalent to the game. Let kids play, follow up good things with positive encouragement if you must, but don't try to remote control your players. I often wonder if joystick coaches go out into the sandbox with their kids and tell them where to dig and how deep to dig and when to dig. Do they explain "No, that's not a proper sandcastle, a sandcastle is supposed to be like THIS"?

I doubt it.