Tuesday, November 13, 2007

I want Java 6 on my Mac...

So, 13949712720901ForOSX

Fred describes what this is all about here Vote For Java 6.

Monday, November 12, 2007

No Fluff Just Stuff, Fall 2007

Jay and crew were back in town this weekend. My company, Avaya, sprung for the admission cost (props!) and I donated my weekend. My brains are leaking out of my ears a bit and I can’t wait to try out some of the new ideas I learned.

Before getting into the details, I need to brag about what I won! In Saturday’s lunchtime raffle, I won a license for the IntelliJ IDE ($500 retail). The vast majority of the NFJS speakers are hardcore advocates for IntelliJ and never pass up an opportunity to dis Eclipse. Now I will get to see what the hype is about. In particular, I have heard the support for Groovy is really good. It will be fun and who knows, maybe I will become an IntelliJ snob myself?

It seems like every time I attend NFJS, I end up spending most of my time focused on a specific theme. This time, it was web frameworks. I didn’t start out intending to do this. The first talk I attended was an intro to ReST. There is a lot of discussion and debate about SOAP versus ReST at Avaya (SOAP is currently winning) and I wanted to see what those wacky ReSTafarians were excited about.

Quick aside, quote from Brian Sam-Bodden at lunch, “Everytime I use SOAP, I feel dirty!".

Brian Sletten did a great job of describing why he thinks ReST is a better solution than SOAP for most web services. His argument really boils down to simplicity and flexibility. He dispels the myth that many folks (myself included) have that all ReST entails is exposing your web service via a URL. This is part of it, but he argues that a better way of thinking about it is as “Resource Oriented Computing" paradigm that easily enables separation of concerns in an application. Resources become the “nouns" in the system. They are operated on by the verbs, which in ReST are limited to GET, POST, PUT, and DELETE.. Operations on the nouns by the verbs result in unique views into the system.

As a defense about the simplicity of a ReST interface, Brian mentioned some anecdotal statistics that 85% of Amazon web services users use the ReST web service over the SOAP web service.

While ReST isn’t entirely about the URL, that is one of the most observable aspects of a ReST implementation. Brian spent some time discussing best practices for a ReSTful implementation of these URLs and also discussed the pros and cons of a non-opaque URL. Based both on what I heard and my use of ReSTful interfaces in the wild, I tend to agree with Brian that it is OK and even helpful to have non-opaque URLs for human use, but you should avoid exploiting this fact programmatically.

After hearing the ReST intro, I decided to sit in Brian’s next session, which covered a specific technology to implement ReST, called RESTlet. RESTlet is an open source API for developing a ReSTful system. I’m not going to go into a lot of detail here. Brian presented some great examples of how to use this and now I have yet another technology added to the “List of Things to Do"™.

Well, I had already attended two sessions on web technology, so why not keep it up.

The next three sessions I attended were all given by Scott Davis on Grails. Scott, who runs the Boulder JUG, has been pushing Groovy for quite a while. I am already a Groovy fan-boy and have been playing with it quite a bit. Scott and Venkat Subramaniam are working on a new book, Groovy Recipes, due out towards the end of the year. I have the honor of being a technical reviewer on the book. It is really looking good.

So Grails extends the use of Groovy to a web framework. Using Grails, typing four commands at the command line generates a completely functional web application including persistence! Seriously, this is a less than five minute exercise. So what took three sessions? Scott spent a lot of time showing how to customize the persistence and view behaviors within Grails. It is pretty easy to customize the environment in a global fashion such that after the customizations have been made, new projects can take advantage of these customizations quickly. Groovy rocks, and Grails is following in its footsteps.

Scott also presented the keynote, “No I Won’t Tell You What Web Framework to Use". Even if you don’t care about web frameworks, there were some great take always from this talk as well as some great humor. Scott’s main point is that since everyone has different needs and requirements, just asking someone what to use is not very helpful. He argues that you should really ask “What are you using?" and “Why?". And ask a lot of people. Then decide what the important decision points are for you (keep the number of criteria small). Use the feedback you have received to arrive at your decision. This summary doesn’t do justice to a talk that was well crafted and chock full of observations about how choice works in almost any aspect of life.

Well, that was it for the web frameworks. While this was my main focus, I did attend some other interesting sessions. I attended three sessions presented by Brian Goetz on concurrency and memory models in Java. In particular, he covered the changes in Java 5 surrounding concurrency, which are quite substantial. A key take away was that you almost never have to instantiate a thread directly in Java 5 and if you do, you better have a good reason. The concurrent library provides some great functionality for adding and controlling concurrency in a product. The timing of this information was helpful, as I am in the middle of a concurrent implementation and got some great ideas about how to approach it.

Attended two sessions by Ted Neward. Ted is the guy who has an opinion on everything, but also has the knowledge to back them up. His talks are some of the most information dense talks I have ever attended. The first was on debugging and monitoring in Java. It was interesting to see the tools he uses and the level of detail you can get to with them. Definitely good stuff. His second talk was on classloaders. I had seen this talk before, but needed to see it again to really absorb the info. It is starting to make sense and again, the information is timely, as I will be applying what I have learned immediately at work. According to Ted, now that we understand classloaders, we have a star on our shoulder that indicates we have attained Java Guru status. I wish!

The last session I attended, presented by Brian Sam-Bodden, was a basic overview of Eclipse Rich Client development. Not something I will be using immediately, but still was nice to see what is available. Eclipse 3.3 provides some nice wizards to bootstrap the process and Brian provided a nice overview on how to make use of them.

So I have tried to fit an entire weekend into a short blog. I barely scratched the surface. Didn’t really discuss the networking and technical discussion that occurs in between sessions. The great side discussions that occur with the speakers. The humor, the good food, … You really need to attend to get the whole picture!

Saturday, September 22, 2007

I am a Nerd King

Well, I rate lower than some friends, I suspect that fact that I am not a huge Star Wars fan affected my score (I am pretty sure I aced the Star Trek stuff). Also, Pokemon? WTF? I like MTG!!! Anyway, here are the results...


NerdTests.com says I'm a Nerd King.  What are you?  Click here!

Tuesday, June 19, 2007

June 2007 BJUG

I attended the BJUG last Thursday. I have been attending regularly for about a year and a half and even presented there last January. This meeting was perhaps the best yet. Jay Zimmerman and Scott Davis continue to run a top-notch Users Group!

The first talk was given by Howard Lewis Ship on Tapestry, which is a web development framework and is part of the apache project. While the topic fell a little out of the area where I am currently working, it was nonetheless interesting. I am planning to play with grails a bit and it is good to see how other frameworks work so I have something to compare against. Howard is a great speaker and author. We'll come back to Howard in a bit.

The only downer in the meeting was that the pizza was late. Fortunately, Howard took questions late, and our next speaker, Mike Cohn, agreed to break his talk into two pieces. Mike, who is a leading expert on agile development, presented Transitioning to Agile. I am a Scrum convert who has read both of Mike's agile books cover to cover. I was very interested to hear the talk, even though it comes a bit late as we have already transitioned. But it never hurts to review how you got there. Mike calls the technique we used "Don't Take No For an Answer". I liked the sound of that!

Mike made a point that is worth repeating. Dogmatically following "Best Practices" leads to stagnation. Only by understanding when it is appropriate to follow such practices and when deviation is a better path does a group learn to adapt. Mike argued that adaptation is a key tenet for a successful agile development.

The best part of the JUG, and arguably one of the best parts of JUGs in general, was when I got to speak to Mike one on one during the break to discuss a problem I was having with our Scrum development. Our team is tackling a large problem that we don't understand very well. The issue is so complex that a spike would not be sufficient to understand the problem. I explained this to Mike, who immediately replied, "Then Scrum is out the door!" He told me the team should focus on fixing the problem as quickly as possible, but that we should not try to fit the issue into a sprint structure. He did suggest that we keep the daily scrums running as a good starting point for communication and that as soon as possible, we restart our sprint planning and subsequent sprints. This is basically what we had done. This is one of the things I like so much about agile. It is pragmatic and usually, the most obvious path is the right one. Having said that, it was still good to hear from the expert that we are on the right track.

Another thing I like about the JUG is the ability to get together with some very smart folks and discuss software development. Geeky? You bet! Prior to the meeting, a friend, Chris, and I were discussing unit testing and the use of mocks. Chris was telling me that he had an epiphany and now understood when to use mocks in a way he hadn't before. I admitted that I still found the topic a bit of a mystery. In the fashion of all good teachers, rather than just give me the answer, Chris showed me how to have a similar epiphany. I will be blogging about this more later (and btw, I now "get it" as well), but for now, just wanted to highlight yet another reason I look forward to BJUG.

In the past, after the BJUG, I would go for beer with a couple of friends. Word about our get together spread and this month, about 12 of us went for beers. What a great time. Lots of shop talk intermixed with general conversation about other "stuff", including Howard introducing the team to a new game, Zertz. I totally suck at this game, but it is fun.

The plan is for this outing to become a regular ending to the meeting (we are going to look for a place that serves scotch for Demian). Should be a great time! If you live in the Denver/Boulder area, consider joining us.

Saturday, May 26, 2007

Is Your Framework Adding Value?

Trust me, this is going somewhere...

Pre-fab or Field-fit?

A friend of mine is a drilling engineer. He has traveled around the globe and has many interesting stories he has shared with me. One involved an experience he had while working in the former Soviet Union around 1993. He and some co-workers toured a factory where pre-fabricated apartments were being built. The idea was that the major components, such as walls, would be built in the factory and trucked to the site where they could be assembled, simplifying the construction process.

Sounds great in theory, but my friend noticed a flaw in the implementation. The walls were made by pouring concrete into large rectangular wooden forms. These forms had internal forms for windows. While the forms were precisely measured and designed to fit, the corners of the internal frames were not braced and as the concrete was poured, they shifted, and what should have been a rectangular shaped window in the middle of the wall wound up being a parallelogram with non-right angles for corners. What should have simplified construction in the field wound up creating more work than starting from scratch, as each section had to be "field fit".

When asked about the problem, the factory workers shrugged and indicated that since it wasn't their problem, they didn't feel any need to change what they were doing. Of course, it didn't matter, since the window glass never fit anyway. When they assembled the buildings, the panes of glass were often overlapped.

The Liquid Foundation

While watching the History Channel, I saw an interesting program about an earthquake in Kobe, Japan in 1995. It turns out that the Japanese have taken to creating artificial land to help ease the real-estate shortage that they are experiencing. This is done by dredging soil from the ocean floor and depositing in other water-filled areas until it forms artificial land ready-made for the construction of houses, businesses, and highways.

Unfortunately, when the earthquake hit, an unexpected state change, known as soil liquefaction, occurred in this artificial land. As the shocks occurred, the land acted, for all intents and purposes, like a liquid, flowing and oozing all over the place. Anything built on top of this now liquid foundation was destroyed.

Software as Architecture

It is fashionable to compare the creation of software with the creation of buildings. We go so far as to call many members of the software industry "architects". While I am not crazy about this metaphor, it does work at times.

Software organizations often attempt to go the prefab route by building frameworks composed of common utilities that can be "trucked" to different developments. The thought is that the framework provides a pre-fabricated foundation (to stick with the metaphor) on which to build the application.

Sounds great in theory. Hmmm, where have we heard that before? At issue is the quality of said framework. Were the architects of the framework familiar with good API design? Were there any architects or is the framework simply an amalgamation of code fragments gathered from other developments? Is the goal of the framework to provide the basics or does it represent a grand attempt to boil the ocean? And most importantly, does the framework simplify application development or does it complicate the application and leave it with "window frames" that are field-fit and "panes of glass" that overlap?

These are important questions for a development organization to ask when it assesses whether to go the prefabricated framework route. Not only is there a risk of wasting development effort (and slowing time to market) trying to fit an application into an awkward architecture, but after this occurs, the resulting product is now built on a shaky foundation that may liquefy at any time, but of course it will wait to do so until deployed at a large customer site.

I am not saying that frameworks in and of themselves are bad. At issue is how the framework was constructed and whether it truly provides the value its use implies. We can look to the open source communities for examples of frameworks that work. Spring, Hibernate, Commons Logging... solid and designed for easy integration.

I told you I was going somewhere.

Sunday, May 06, 2007

No Fluff Just Stuff, Spring 2007

NFJS, Spring 2007

This is the second year in a row I have attended the Denver leg of the No Fluff Just Stuff tour. Jay Zimmerman and crew have outdone themselves. The speakers were excellent, the topics were relevant, the venue was nice, and the food was good!

Due to budget issues, my company was not able to spring for the registration fee this year. So I paid for attendance out of my own pocket. It is that good! Kudos to Linda for supporting the financial decision.

I started out the seminar attending Venkat Subramaniam's Annotation Hammer talk. Annotations are near and dear to my heart, as they were the basis for my own talk on Hibernate with Annotations. It turns out Venkat doesn't feel that this is an appropriate use of annotations.

He made the distinction of intrinsic versus extrinsic metadata. According to Venkat, an intrinsic feature, which is one in which the semantics of the metadata are expressed in the code itself, is a good candidate for annotation use. Extrinsic features, in which the metadata expressed by the annotation is not expressed in the code itself, is not a good candidate for annotation use. Venkat believes that persistence semantics, such as in Hibernate, fall into the latter category. He also believes that using annotations with Spring and Hibernate results in vendor lock-in. I can buy into the extrinsic argument to some extent (but still like Hibernate annotations for small apps). I agree that Spring annotations result in vendor specific implementations. I disagree that annotations in Hibernate are vendor specific, since they are based on the JPA. If you don't like Hibernate, you can switch to another JPA provider (such as Ibatis). That's not lock-in where I come from.

Other interesting take aways from the talk include some info on Java 6, which will expand the use and support of annotations In Java 6, annotation processing is built in. For Java 5, the external Annotation Processing Tool is needed for pre-processing. A new annotation in J6, @WebService, provides all the scaffolding to support a web service without the need to write code.

Venkat showed some examples of junit 4.0 annotations. I really couldn't see any reason to use them over the standard junit API. No real value add.

Venkat concluded with a couple of observations: annotations "leak into" your code and can be hard to get rid of later. I don't like XML is not a good reason to favor annotations.

I'm guilty of the last one...

The next talk I attended was Neal Ford's 10 Ways to Improve Your Code. Neal used an interesting tool for his preso, MindManager, which is a mind mapping tool used for brainstorming and, it turns out, for making presentations.

Some key take-aways from this talk (some of them are "duhs", but still):

Version control and continuous integration are fundamental. An automated build machine should not have development tools on it.

Static code analysis should be favored over a compiler as the first step of testing. He mentioned FindBugs and a tool called PMD. PMD has a feature called "copy paste detector" that is useful for finding common code that can be refactored.

Singletons are glorified global variables. Overusing static classes is a sign of a procedural mindset

Persistent state is the enemy of unit testing. Keep your object state valid at all times. As an example, we discussed an Address class, with address, city, state, and zip fields. Neal argued that it made no sense to have setters for each field, since an address without a city makes no sense. Instead, he recommended using a constructor that takes all fields as arguments. I asked about a UI that might need to change the object. He suggested an update method. This is a great idea that I plan to use in my code.

Test driven development, avoiding feature creep, and analyzing dependencies (using a tool called JDepend) were discussed. He also presented an algorithm developed by an associate of his that used code coloring to identify code that provides the maximum business value. It was a bit complicated but looked like it could be useful if applied rigorously.

He touched on Domain Specific Languages (DSLs). This looks very interesting but we didn't get into much depth here, but the gist is that you should write APIs and name components using terminology that fit the domain.

Neal touched on a topic he calls Polyglot Programming, which was also the topic of his keynote talk. Summarizing, he argues that developers should use the most appropriate language for the task at hand and that it is acceptable to mix and match languages in a product. Given that there are 25 different languages that run on the JVM now, this is starting to make a lot of sense (see my discussion later on Java 6 for more on this).

The other critical argument Neal made in his keynote, and one that I whole-heartedly buy into, is that for software development to truly be considered an engineering discipline, the practitioner's of the discipline must embrace and commit to testing as the underpinning of everything the developer does. Neal is a test-driven development zealot. I am quickly becoming a convert. Of course it will take me some time to get good at it, but I have a goal.

The next talk I attended was OSGI: A Well Kept Secret, present by Venkat. OSGI is a component management platform that protects an application from "classpath hell". After hearing what this tool does, the first question the pops up is, "Why isn't this baked into the JVM". It turns out there are plans to do this, but there are two competing standards, JSR 277 and JSR291. And neither of thee standards appear to be learning from the OSGI team! So I'm not holding my breath. Like all Venkat talks, the demos were detailed and really showed the power of the product. I don't currently have need for this product, but it was good to get an introduction to it. Probably worth mentioning that OSGI is baked into apps like Eclipse.

Start of Day 2, first talk I attended was Build Teams, Not Products, presented by Jared Richardson. As a dev lead on a Scrum project, team building is a very important aspect of my job, and, in all honesty, not one of my strengths. So this was a relevant topic. I got some good ideas that I plan to try with my current team...

As the dev lead, it is important for me to share my own impediments so that other team members will be willing to do the same.

Focus on interactions, which will maximize human bandwidth.

Encourage informal code reviews as both a learning tool and a way to kick-start interactions. Verbalizing design decisions helps the whole team.

Randomize the order that the scrum reports in every day.

It was interesting to find that Jared worked at SAS, which rumor has it is the utopia of companies to work for if you are a software engineer. Jared dispelled this rumor a bit saying that, in regard to the work, there are good and bad areas within the company, just like any other company. Figures. He did say the bennies and culture were nice.

I followed this talk with another by Jared, Continuous Integration with Cruise Control. In keeping with my goal of getting better at TDD, I wanted to learn more about this tool so that I could use it more effectively. It was a good talk, with a great demo of the product. Nothing earth shattering but good review of what is available in the tool.

Neal's keynote got me to thinking and i decided it was time to look at Ruby again, so I attended his talk on JRuby. I'm still not sold on it. I really like Neal and respect a lot of his opinions, but he seems to be a bit hypocritical when it comes to Ruby. He spent a lot of time in the keynote discussing the warts in Java. During his Ruby talk, he glossed over similar issues in Ruby. One example is that arrays in Java being zero-based is bad, but when we run into this in a Ruby example, it is glossed over. Hmmm.

Neal stated that in Python, there is only one way to do something, while in Ruby, there are ten ways to do the same thing. He went on to argue this is a strength of Ruby. So put ten programmers in a room with Ruby and they will do the same task ten different ways. The maintenance team is gonna love that!

Neal argues for very clear concise class, method, and variable names, but the fact that the Ruby to string method is called to_s is not pointed out as a problem. Worse yet, there is Perl-like syntax that has crept into the language. How is this a clear, understandable piece of code:

list = ArrayList.new
%w(Red Green Blue).each { |color| list.add(color) }

%w? Give me a break. If I knew nothing else about the language, this would send me running... away!

Another Ruby annoyance is the suffixed if as opposed to the Java prefixed if.I am willing to concede that to some extent, this one is a learning curve, can't teach an old dog new tricks issue. Guilty as charged. But I'm still gonna use Groovy as my dynamic language of choice!

I should note that I really enjoy Neal's talks. He is intelligent, has a great sense of humor, is way smarter than I am, and does get me to look at things from a different angle. I just can't get excited about Ruby/JRuby.

I finished the day attending a talk, Making Architecture Work through Agility, presented by Mark Richards. Mark is an architect with IBM... and it shows. I am not very happy with the term architecture in software development. I really like Martin Fowler's essay Who needs an architect?. Mark's presentation reinforced this opinion. He showed a typical, "boil the ocean", eye-chart caliber architecture document and proceeded to discuss how an architect could get teams to implement the architecture in pieces. But this occurs "after" the architecture is delivered from on high. It is probably a bit better than what happens now, but I would argue that a better approach would be to use an agile process, and start implementing a product immediately, using refactoring to evolve the system over time as new features are identified and operation of the system is better understood. I attended this session hoping to change my mind abotu architecture, but instead, I find my opinion has been reaffirmed.

On the final day, I started by attending the Java 6 talk presented by Venkat. I knew that J6 was out there, but hadn't heard much about it. I hadn't heard anything about it that seemed like a must have or even a nice to have feature.

Java 6 is defined in JSR 270. It is currently available for Windows and Linux, but not for the Mac (a developer release is available). It turns out that both the developer Mac version and the Windows version running under Vista have problems. Linux users, you know who you are, this is your cue to start the heckling...

The most impressive new feature in J6 is its support for more than just Java. There are something like 25 languages that run on the JVM now and J6 provides a mechanism, called the ScriptEngineManager, that allows processing of these languages in Java code. This feature becomes very important with Neal's polyglot programming paradigm. J6 has a tool, jrunscript, that allows interactive testing for different scripting code.

J6 also provides built-in support for web services including a small webserver. Venkat feels that this feature is too little, too late. As a person who doesn't know web services very well, I might be able to take advantage of this feature.

J6 provides some tools to support monitoring and programmer support. JHAT provides some cool monitoring tools, JavaCompilerTool provides programmatic access to compiler, and there is built in annotation support, using -processor option on javac to specify annotation pre-processor.

J6 also provides localized UI support, splashscreen support (your splashscreen can be displayed BEFORE the JVM starts), console support, and integrated JDBC support. Venkat didn't go into these features in detail, but it is good to know they exist.

At lunch, there was a speakers panel. The speakers like to pick on Ted Neward, who seems to eat it up. They seem to have a lot of fun. Ted seems to enjoy taking the opposing side to the rest of the group. In particular, he made a comment that with careful programming, unit testing was not necessary. I was surprised that the rest of the group didn't hang him from the nearest tree. I later heard him mention that compilation WAS a weak from of unit testing. I think he likes the controversy. I hope so, because he seems like an intelligent guy in other respects.

The rest of the afternoon was spent in, here is the funny part, talks by Ted! He had a series on some quasi-basic stuff that I have never gotten around to looking into much. I took this opportunity to fix this.

The first one was on monitoring and debugging. Ted argues, effectively, that monitoring is more important because it proactively prevents errors, alleviating
the need to debug.

He presented some tools that come with Java that allow monitoring to occur. To demonstrate, he used a demo program available from sun called swingset2, which demonstrates many features of swing and is worth a look just for grins.

He started by looking at garbage collection, using the gc command line option, -verbose:gc, followed by a demo of jconsole to see the same information in a graphical format. He also demonstrated JMX hooks into the JDK logging libraries. which are cool. Unfortunately, they are not supported in log4j, which we use at work. The only criticism I had for this session is that towards the end, it got a little windoze-centric.

The last two sessions dealt with Reflection and Class Loaders. Lots of good technical information was imparted. Very information dense. My head hurt afterward. I'm not sure any of it is directly applicable to me right now, but it will be nice to have this background if I ever do run into uses of them.

The last thing I should mention is that I intentionally avoided talks by Scott Davis, but not because he is a bad speaker, which couldn't be further from the truth. Because he runs the Boulder JUG, which I attend regularly, I get to hear him talk on a regular basis. Were this not the case, I would probably attend everyone of his talks. Yup, he is that good! Wanted to put a plug in for him in case you haven't heard Scott talk and have the opportunity! Attend if you can... you won't regret it!

This blog is a short summary of a long weekend, but hopefully gives you a flavor of what the weekend was like. If you ever get the chance, I highly recommend attending a NFJS event.

Saturday, February 17, 2007

A Geek's Groovy Valentine's Day Gift

I have wondered at times, does my wife listen to my ramblings about what I am working on, or has she just gone off to her happy place and is on auto-pilot?

Well, on Valentine's Day, I found out that she is listening at least some of the time. I am pretty excited about Groovy and while I haven't done much with it yet, I am hoping to do so soon. Anway, Linda must have heard something about Groovy, as demonstrated by the following pictures.

Saturday, January 13, 2007

Presenting at the BJUG, What Else Could Have Gone Wrong...

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!

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!

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!

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.