Posts

Showing posts from June, 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

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 programmin

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

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 ambivale