Well, for starters, I could have had to drive from Monument to Boulder, got stuck in traffic, realized I didn't have the directions to get to the meeting, and barely made it on time for my presentation. That's what happened to the presenter that followed me, David, Geary, who went on to present an excellent talk on the Google Web Toolkit.
David has written an e-book on GWT Shortcuts, that was supposed to be available at Informit., but it is listed as coming soon. He also has a paper book in the works for later this year on GWT.
Anyway, back to my preso. I had signed up to present Hibernate With Annotations to the Boulder Java User's Group. Hibernate is an Object to Relational Mapping library that I am using for my pet/perpetual project to keep statistics for a hockey team. I am using a new feature in Hibernate, using Java 5 annotations to manage my Hibernate ORM. There isn't a lot of info on it currently, so I thought I would share.
So I realized that afternoon that I had forgotten my monitor adapter for my laptop (DVI to VGA). No way to hook up to the projector. D'Oh! So I left work early and picked up a cable at the Flat Irons Apple Store. Then I met some friends at a restaurant for a pre-meeting dinner. The waitress was very slow and we got out a little later that I had hoped, but we still had some time.
So I am driving into Boulder on 36, three friends in my car, just dropped over the top of the hill, and I see an HP in front of me. He is driving about 60 in a 65, so I pass him doing about 66. As soon as I pass him, he drops over and hits the lights. What the hell? Is he really gonna ticket me for 1 over? Turns out, no, my license plates have expired. So he is ticketing me for that and takes his sweet time. Now I am in trouble time-wise. When he finally gives me my ticket, I take off for the meeting. We get into the parking lot 5 minutes before I am on. I get my stuff and start into the building at a fast clip, leaving everyone else in the dust. On my way, I hit a patch of ice and fall. I barely miss a beat, jumping back up and heading in. My friends jokingly tell me to wait up. I found out later that my fall resembled my bowling style.
So I get into the meeting room and begin setting up my laptop. As I do, I look down to discover that my leg is covered in blood! Not knowing what to do, I continue setting up. My friend Demian arrives a minute later and asks if everything is going OK. I say not really and point to my leg. Demian immediately goes and grabs me a bunch of paper towels, wet and dry, which I use to start cleaning up. Fortunately, I am behind a podium, so I'm not freaking out everyone in the room. Anyway, by the time I finished setting up and futzing with getting the projector to work, my leg appears to have stopped bleeding and I am ready to start. Only five minutes late!
My friends told me that I did a great job on the presentation. They said it was not overly apparent that I had been a nervous wreck just before I started. I know that is what friends are for, but based on feedback I got from other folks in the room, I am gonna go out on a limb and say I did OK. Comparing my presentation to David's, it is obvious which one of us is a professional lecturer, but given that I am a newb, I am happy with how it went. I wanted to make sure that I didn't just "read the slides", and think I managed to avoid that particular sin of presentation. One good criticism I received is that I should have incorporated looking at my code into the presentation instead of waiting until the end to walk through it.
I agree that that would have been a better way to do it, particularly after seeing how David did this with great success. I will have to practice quickly getting in and out of PowerPoint if I want to do this successfully.
BTW, you can see my preso, and the code if you are interested, at my web site. My friend Demian, at my request, submitted the site to Digg, a community web site for sharing content. I was hoping that there would be some interest, but it flopped. I got 5 diggs, all from friends. you usually need at least a 100 to get noticed by the masses. The main reason I was hoping to get the exposure is to get more feedback on my solution. Ah well, guess I am on my own.
If you take away the fifteen minutes preceding my preso, I really enjoyed the experience. There is an old adage that the best way to learn something is to teach it. From my experience, this is definitely true!
Saturday, January 13, 2007
Friday, January 05, 2007
A Serendipitous Post
My daughter is having problems sending e-mail from Mail.app on her Mac while she is at school. I recently experienced the same problem at my sister-in-laws in Minneapolis. I was set to do some digging on this over the weekend when I found the following post from Scott Davis while reading some blogs...
Port 587
Problem solved. Thanks Scott!
Port 587
Problem solved. Thanks Scott!
Anyone for a Scrum?
In preparation for work on a new project, I have been investigating the Scrum software development process. I have read “Agile Software Development with Scrum” by Ken Schwaber and Mike Beadle and am currently reading the follow on book “Agile Project Management with Scrum” by Ken Schwaber. Next in the queue is “Agile Estimating and Planning” by Mike Cohn. From what I have found on the net, these are essential reading for anyone getting started in Agile. Based on what I have read so far, I tend to agree.
At its heart, Scrum (and really all agile processes) attempts to inject some much-needed realism into project planning and development. The pillars of Scrum are visibility, inspection, and adaptation. Schwaber spent time with industrial process gurus reviewing software development. The consensus is that software development is complex and can only be successfully managed using an empirical process. Scrum provides such a process. This is in contrast to a defined process such as the waterfall model that is embodied in many companies’ development processes (including the one used in my company).
Given that I am reading three books just to get familiar with Scrum, there is no way I can provide the detail in this e-mail needed to fully sell anyone on the idea. Here are a couple of good sites that cover Scrum. The first provides a very good high-level overview and the second gets into details.
CodeProject
Mountain Goat Software
At a high level, here are some reasons why Scrum should be considered for use.
Visibility into project status with Scrum is excellent. At any given time, it is easy to see what has been done and what still needs to be done via the burn down chart and product backlog. These are quantitative tools for examining cost/time/quality throughout the duration of the project. After a couple of Sprints, the burn rate or velocity of the team can be calculated and the end date accurately projected. Need more visibility? Reduce sprints to 2 weeks in duration.
Since Sprints are only 30 days long, if priorities change or problems are encountered, only 30 days are lost. Before each Sprint, the direction of the project can be refined or even drastically changed if needed. Scrum is all about agility and adaptability.
For larger projects, a set of interlocking Scrum teams can be used to develop sub-components. This is an area that will take a little more work to get right, but will be worth the effort. To quote Dr. Venkat Subramaniam (technical author, speaker, and amazing developer), “Any team with more than 10 developers is a setup for failure.”
At a recent JUG in Boulder, author Neal Ford asked the audience, “How many of you are developing using a waterfall process that is being called agile?” A lot of hands went up, including a co-worker’s and mine. Going forward, I have resolved not to be quiet whenever we use the term agile to describe a waterfall process. They are not agile. That’s OK, particularly if you buy into waterfall as a successful software development process, but it isn’t agile. Until we stop using the word to mean something it doesn’t, we won’t get any closer to truly finding out if agile can help us. If you don’t have enough first hand evidence already, Schwaber recommends “Wicked Problems, Righteous Solutions” for discussions about why waterfall doesn’t work.
Schwaber makes the observation that technology plateaus are gone and that new projects + new technology = unpredictability. Scrum provides a tool to manage these challenges.
What’s next? I recommend getting Certified Scrum-Master training for all management and senior developers and Scrum product owner training for the product marketing team. Then implement what you have learned in creating great products!
At its heart, Scrum (and really all agile processes) attempts to inject some much-needed realism into project planning and development. The pillars of Scrum are visibility, inspection, and adaptation. Schwaber spent time with industrial process gurus reviewing software development. The consensus is that software development is complex and can only be successfully managed using an empirical process. Scrum provides such a process. This is in contrast to a defined process such as the waterfall model that is embodied in many companies’ development processes (including the one used in my company).
Given that I am reading three books just to get familiar with Scrum, there is no way I can provide the detail in this e-mail needed to fully sell anyone on the idea. Here are a couple of good sites that cover Scrum. The first provides a very good high-level overview and the second gets into details.
CodeProject
Mountain Goat Software
At a high level, here are some reasons why Scrum should be considered for use.
Visibility into project status with Scrum is excellent. At any given time, it is easy to see what has been done and what still needs to be done via the burn down chart and product backlog. These are quantitative tools for examining cost/time/quality throughout the duration of the project. After a couple of Sprints, the burn rate or velocity of the team can be calculated and the end date accurately projected. Need more visibility? Reduce sprints to 2 weeks in duration.
Since Sprints are only 30 days long, if priorities change or problems are encountered, only 30 days are lost. Before each Sprint, the direction of the project can be refined or even drastically changed if needed. Scrum is all about agility and adaptability.
For larger projects, a set of interlocking Scrum teams can be used to develop sub-components. This is an area that will take a little more work to get right, but will be worth the effort. To quote Dr. Venkat Subramaniam (technical author, speaker, and amazing developer), “Any team with more than 10 developers is a setup for failure.”
At a recent JUG in Boulder, author Neal Ford asked the audience, “How many of you are developing using a waterfall process that is being called agile?” A lot of hands went up, including a co-worker’s and mine. Going forward, I have resolved not to be quiet whenever we use the term agile to describe a waterfall process. They are not agile. That’s OK, particularly if you buy into waterfall as a successful software development process, but it isn’t agile. Until we stop using the word to mean something it doesn’t, we won’t get any closer to truly finding out if agile can help us. If you don’t have enough first hand evidence already, Schwaber recommends “Wicked Problems, Righteous Solutions” for discussions about why waterfall doesn’t work.
Schwaber makes the observation that technology plateaus are gone and that new projects + new technology = unpredictability. Scrum provides a tool to manage these challenges.
What’s next? I recommend getting Certified Scrum-Master training for all management and senior developers and Scrum product owner training for the product marketing team. Then implement what you have learned in creating great products!
Tuesday, January 02, 2007
The Passionate Worst...
A follow up to my last blog on Chad Fowler’s book. I’m not going to summarize the entire book, which I highly recommend, but rather comment on a couple more points that really hit home. Fowler is discussing strategies a developer can use to protect their job. The “Be the worst programmer in the room” and “Love it or leave it” strategies are right on target.
In “Be the worst programmer”, Chad creates an analogy between being the worst musician in a band and being the “worst” programmer on a team. In both cases, he argues that people tend to perform at the level of those surrounding them. If those surrounding you surpass your abilities, it is often the case that you rise to the challenge and the quantity and quality of your work will surpass what you might normally have produced. He also argues that the opposite is true. If you find yourself on a team composed of lesser caliber people, your performance may take a hit because you are not challenged.
I have always enjoyed working with talented people. What I liked about this strategy is that it put into words what I think I have always instinctively been drawn too. While I have never felt like “the worst” (too much hubris?), I have always thrived on learning from those around me and have often felt like I had to step it up when surrounded by experienced developers. When I am the most experienced person in a team (which is where I find myself at the present time), I try to motivate the folks I am working with to stretch their talents as well. I hope I am successful, but if the truth were known, I think I prefer being “the worst”.
When I interview potential developers, I think the key trait I look for is passion (particularly for software development, but really passion in any area is a plus). This fits right into Fowler’s “Love it or leave it” strategy. A quote from the book, “What I found were a whole lot of people who were picking up a paycheck and a few incredibly passionate craftspeople,” summarizes my experience interviewing applicants. The blank stares I get when I ask “What technology or technological book in the past six months got you excited?” truly amazes me. One deer in the headlights applicant, in an attempt to hide the fact that she had nothing, answered that she had just read the user manuals for a commercial database she was using at her current job! As Chad says, “You can fake it for awhile, but a lack of passion will catch up with you and your work.”
I have been fortunate in the past two years to have been surrounded by developers who were both passionate and better than I am. I truly believe I am a better developer because of it.
In “Be the worst programmer”, Chad creates an analogy between being the worst musician in a band and being the “worst” programmer on a team. In both cases, he argues that people tend to perform at the level of those surrounding them. If those surrounding you surpass your abilities, it is often the case that you rise to the challenge and the quantity and quality of your work will surpass what you might normally have produced. He also argues that the opposite is true. If you find yourself on a team composed of lesser caliber people, your performance may take a hit because you are not challenged.
I have always enjoyed working with talented people. What I liked about this strategy is that it put into words what I think I have always instinctively been drawn too. While I have never felt like “the worst” (too much hubris?), I have always thrived on learning from those around me and have often felt like I had to step it up when surrounded by experienced developers. When I am the most experienced person in a team (which is where I find myself at the present time), I try to motivate the folks I am working with to stretch their talents as well. I hope I am successful, but if the truth were known, I think I prefer being “the worst”.
When I interview potential developers, I think the key trait I look for is passion (particularly for software development, but really passion in any area is a plus). This fits right into Fowler’s “Love it or leave it” strategy. A quote from the book, “What I found were a whole lot of people who were picking up a paycheck and a few incredibly passionate craftspeople,” summarizes my experience interviewing applicants. The blank stares I get when I ask “What technology or technological book in the past six months got you excited?” truly amazes me. One deer in the headlights applicant, in an attempt to hide the fact that she had nothing, answered that she had just read the user manuals for a commercial database she was using at her current job! As Chad says, “You can fake it for awhile, but a lack of passion will catch up with you and your work.”
I have been fortunate in the past two years to have been surrounded by developers who were both passionate and better than I am. I truly believe I am a better developer because of it.
Subscribe to:
Posts (Atom)
Posts
