I finally was able to process a number of sets of photos tonight.

I ordered and received a Strobist kit from MPEX. Here is an example or two from my first experiments with the kids:

I also took a few snapshots at Christmas. First one from an early Christmas with the kids at my parent’s house:

Then over at my grandmother’s house for Christmas Eve:

Christmas day, I was up at my parent’s house near the Guadalupe River, so we decided to goof around with the cameras outside:

The following day, David, Edward, Virginia, and I went downtown to get a few shots of the Christmas lights on the Riverwalk.

Click the photos to see the other photos in each set.

Over at Stevey’s Blog Rants is a cool article: Code’s Worst Enemy. Stevey describes being up against getting a 500,000 line web-based game working again after some time off-line. He sees a large code base being the worst problem you can face in software and he makes some good arguments to that point.

He also comes to the conclusion that Justin Gehtland (Name dropper! –Imaginary Ed.) talked about in Ruby on Rails training that I went to last week (I’m paraphrasing both here): The JVM is great - the Java language is the problem. He makes an interesting choice in the end (I’ll let you read the article for yourself).

I did it. I waited until now (though there were some personal extenuating circumstances) to finish my Christmas shopping. Given my mortal fear of shopping, I had intended on doing most of my shopping online. I was encouraged by Amazon’s banner indicating that not only wasn’t I too late to shop, but that I could indeed still use Super Saver Shipping and still receive my order by Christmas so long as I ordered by today.

I went through, selected items eligible for SSS and placed my order. Bummer. A few of my items won’t arrive until after Christmas. Make that all of my 14 items wouldn’t make it until the 26th or later. Hmm. Try standard shipping. No soap, all of them showing up post-Christmas. Hmm again. How about two day shipping? Nope. Ok, the problem must be just one or two, select multiple shipments (at additional cost). Ah, Amazon, my savior! For only $140 on a $215 order, I can receive two of my 14 items on time.

I’m late making my order - I can accept that, but what is the point of trumpeting that you can save the day for us late shoppers if you don’t mean it?

No thanks, Amazon. I’ll be braving the crowds before I send you any money this year.

UPDATE

Borders - the good, old, brick and mortar version - came through. One trip over lunch and I ended up with just about everything I wanted from Amazon (a bit more here, a bit less there) for about the same cash as Amazon.

The Pragmatic Programmers have suggested that you get a lot out of learning a new programming language a year. I’ve been doing programming for a long time, and though I’ve learned a number of languages over the years, but I think I’m still behind. This year I’ve been learning Ruby (which I’m loving). For next year, I’ll need to learn something else - and like many, I think I’ll choose Erlang. For kicks, here is what I’ve touched so far:

1. Forth
2. Basic (Commodore Vic 20, C64, Pet, Osborne, AmigaBasic probably other versions I’ve forgotten)
3. Logo
4. Pilot
5. Comal
6. 8502 Assembly
7. COBOL
8. C
9. Pascal
10. QuickBasic
11. Lisp
12. FORTRAN
13. CA Realizer
14. Ada
15. C++
16. REALbasic
17. Visual Basic
18. PHP
19. Java
20. Python
21. Javascript
22. Ruby

Which would be a pretty good list except I started back in ‘83 or so. I’ve definitely not done as well in recent years. My experience with Ruby has definitely re-energized my interest in languages.

Recently at work, there has been a push to not only standardize on a software diagramming tool, but to enforce its use for all projects. I’m naturally opposed to this “one size fits all” approach, but it also made me think about the ways teams use software documentation. It took a few weeks of background brain processing and refreshing my XP experience (with the team I’ve been working with recently) to get my thoughts together.

I have always observed a tension around documentation in my experience as a developer. On one hand, everyone accepted that documentation was obviously necessary to a healthy project. We clearly needed detailed requirements and design documents. On the other hand, most people would grudgingly acknowledge that documentation:

• Requires a lot of time to produce
• Is no fun to work on
• Gets stale quickly as the project progressed
• Misses a lot of vital information
• Is confusing and easy to misinterpret

The split of opinion in our meeting broke down more or less like this:

An architect and people on his team were convinced of the necessity of formal documentation. The more experienced dynamic language developers, were much less convinced.

We talked about what the documentation proponents expected to gain from the documentation and heard the following:

• Communication of the structure of the application
• Provide a means to evaluate the design in reviews
• The documents equate to a blueprint of the solution

I tend to favor simplicity, so my gut was telling me that any design that needed more than a few minutes at a white board was likely to be overkill (particularly for the kind of software we develop). After some thought, I came to the conclusion that the problem was that the fans of documentation are after a worthy goal, but the current state of software engineering lets them down.

Why?

Simple. A UML document isn’t anything close to the information repository that an actual blueprint is.

Blueprints (I’m speaking of architectural blueprints here) provide information that can be used to validate the structural integrity of the proposed building. UML diagrams do no such thing - the reason why is that building construction is composed of specific standard materials (components) which are assembled (composed) in standard known ways. The net result is that an engineer can look at a blueprint and bill of materials and perform the math necessary to determine if the designed structure will withstand the expected stresses. Software packages exist which can do this as well for many types of structures. Likewise, electrical engineers can design a circuit and run it through a circuit simulator to validate that it works.

In software, UML diagrams (or any other documentation) describe high level design patterns and standard frameworks that can be applied, but the devil, as they say, is in the details. There are no standard components which hook up the internals in predictable or validatable ways. No one can look at a UML diagram and make any valid predictions about the suitability of a design for any application.

Why?

Because software is a more widely applicable than construction and is an extremely immature engineering discipline. We’re still putting together our buildings using hammers whose heads fall off and land on your foot when you swing them at a nail. To write a circuit simulator for a software application requires that you write the code for the software. The code for the software is ultimately the only design that matters. The best validation that we can currently achieve is to write tests against running code.

Therefore, the inability to prove the suitability of a software design document is one of the reasons why software architects who don’t write code are a bad idea. A lot of software engineers either intuitively get this or have picked it up after dealing with an “architect” or two. XP guys get it - the lead software engineer still writes code.

A final analogy: a music composer can sit down with a sheet of paper and a pencil and write down a piece of music that can be played by a group of musicians with no further input from the composer. Software can’t be designed this way. Human beings aren’t capable of comprehending enough depth and lack the tools to communicate the design for a piece of software.

So where do we stand?

Software is hard to do right. There isn’t an easy answer and no silver bullets seem ready to present themselves. The best we can do at present is emphasize simplicity, maximize communication (face to face at a whiteboard beats any document I’ve seen), and use discipline and techniques like pairing, reviews, and testing (and many others) to protect us from ourselves. It’s the best we can do right now.

Anton sent me a link to Damien Katz’s “funny because it’s true” article about the symptoms of being a crappy programmer. I wish everyone at work would read and think about this.

The fact of the matter is that everyone is guilty of something on this list from time to time. It reminds me that I really need to refactor the copy/paste coding that I did on Thursday night when adding a new feature to Cruise Control Rb.

Keep your cat away from my bird feeders!

Favorite quote: “It was crouched, as usual, under one of our bird feeders & I fired from some distance with bird shot.”

A week and a half has passed since my last post. I’ve gathered up a few notes on new things that I’ve noticed:

• Periodically you run into a work issue where rather than coding, you are tracking down a configuration issue. For example, you might need to figure out why you can’t make a connection to a database. These problems are tedious at the best of times, but they are especially tedious for the half of the pair not at the keyboard. That being said, there still is some value gained by the second pair of eyes.
• What happens when a pair goes down the rabbit hole? Sometimes a pair begins work on a task which is useful for a refactoring or code sharing reason, but isn’t strictly a user story or spike. It becomes important to “time box” the activity if problems present themselves (”Ok, we’ll work on this until lunch and if we don’t have a solution by then, we’ll shelve this until later.”).
• Don’t be afraid to modify your framework. One refactoring that we did this week was a change to ActiveRecord::Base that permitted each of the models in our various apps to inherit our model activity logging module without adding Includes to each model class. Due to Ruby’s ability to augment existing classes, this was a bit easier than it might have been in other languages, but there still was a bit of debugging and testing necessary to make it work reliably with all of our projects. This could be the subject of a future posting.
• Build in repeatability. We currently have four applications that our team is in various states of building. Since we seem to add new projects so often, we spent some time over the last couple of weeks building a baseline application in subversion that contains all of our common application plugins and defaults. This makes starting a new project easier since we commonly use a number of different additions to Rails.
• Look for pain points and eliminate them. One of our applications had grown to a size that the build/test process had lengthened to twelve minutes. This was causing delays in our check-in process, so we scheduled a spike this iteration to improve the testing speed. Think about the places in your day-to-day work that waste some of your time - long running tests? Searching your project files? Next think about what can be done to eliminate those wasted seconds and minutes. You do things over and over and small improvements in time add up over the course of days, weeks, and months.
• A reason to have a customer close: sometimes the team ends up ahead of schedule and needs new stories to work on. Often in the iteration planning meeting, additional stories are determined for this potential, but if there aren’t additional stories prepped, having the customer available is essential.
• Another reason to have a customer close: the customer keeps thinking about the problem. For example, we had received a description of how the real-world objects we were modeling were related from our SME. We understood his description fairly well and made a stab at implementing the models as he described them. One morning, our SME thought further about the relationships of the models and arrived with an updated description which of course necessitated changes on our end. As a result, we had a little rework, but a much better data model emerged because of our daily interaction with the customer.
• Finally, seek an expert when necessary. We are beginning to use the Ext JS UI framework to build new user interfaces. We’ve chosen to use Ext 2.0 which is only in alpha, so the documentation and examples are still minimal. We requested that a sibling team’s expert in Ext and Javascript come spend some time with us to share some general usage principles and to discuss testing philosophies when creating richer web user interfaces.

For the last week, I’ve been embedded with a group of contractors at work who have been developing some new internal tools using Ruby on Rails. I intend to blog a bit about what my experiences have been as time goes by so that I can capture the ideas that I’ve been picking up from my time on the team.

The team practices Extreme Programming which is the software development methodology which I’ve been interested in for the last six or seven years. It was the reason that I sought out the job with Symantec a few years ago and nothing that I’ve done in the time since has compared in regard to my productivity and my enjoyment at work.

First of all, the quality of the team is immediately evident. They are a group of very committed and focussed individuals. They spend more time than most teams ensuring that the object models and code are as clean, simple, and organized as possible. When they find a way of improving some aspect of their work, they take the time to build a tool to make that task simpler, then make sure everyone on the team has access to the tool. For instance, in the past week, one of the development pairs (XP involves pair programming) began working on an Ubuntu Linux dev box instead of the standard Mac Mini stations. They had identified the JEdit editor as a suitable candidate to replace TextMate on the Linux platform. TextMate provides several features that JEdit doesn’t have out of the box and they (or other members of their organization) have developed several Bundles for TextMate that improve their efficiency in coding. The leader of the Linux effort took the time to identify identical plugins for JEdit and wrote one or more plugins to provide identical (or similar) functionality for the most used TextMate features. Too often, I’ve seen programmers either suffering silently with inadequate tools, or building small tools for themselves without sharing them with others. One other thing about editors - this team really knows its editing tools - I’m constantly asking what the key combo was that my partner used to do some cool operation in the text that otherwise I might have done manually. This was a thought from The Pragmatic Programmer that these guys have really taken to heart.

They are obsessed by testing. They test every conceivable aspect of the code (always with automated tests) and use Test Driven Design (TDD) exclusively. This provides many code quality benefits, but most developers don’t have the self-discipline to accomplish this. The pair programming that they practice is also helpful in this regard (more on this below). They go beyond the standard Ruby on Rails ways of doing automated testing in the following ways. They use the UnitRecord, Mocha, and Dust testing extension libraries.

UnitRecord is a tool which permits removing database access from your ActiveRecord based classes. This greatly reduces the time it takes for each test to run - which is a good thing when you have the number of tests that this team produces.

Dust is a tool which permits you to write test cases like this:

functional_tests do
  test "given no name, when validated, then error is in the objects error collection" do
    instance = Klass.new
    instance.valid?
    assert_equal "can't be empty", instance.errors.on(:name)
  end
end

instead of deriving a class from Test::Unit::TestCase and adding methods that start with “test_”

Mocha is my favorite of the new tools. It is a library which provides the ability to mock and stub out classes and methods in a manner similar to jMock (which it is inspired by), but it provides a cool feature that I don’t believe that jMock does: it “…allows you to mock and stub methods on real (non-mock) classes and instances. ” This is a big time saver and lets you isolation test classes without having to refactor the code to avoid dependencies.

For pair programming, the team pairs share a common mac mini which has two monitors, keyboards, and mice (the monitors are mirrored so each developer looks at his own screen and sees the same as his partner). To share time at the keyboard, they play a game which they refer to as ping-pong. The first developer writes a test which the second must write code to satisfy. The second developer then writes a test for the first developer to write code. In this manner, each developer gets practice writing code and tests.

The team has an obsession about simplicity. I value the simplest solutions, but often I have caught myself planning code for the future when I learn that my partner has a simpler way which involves less complexity. For example: don’t add a database table unless necessary - write a hard-coded class instead.

This insistence on simplicity extends to maintenance as well. When the stories for the iteration have been written, one of the pairs was tasked with cleaning up a class in one of our applications which had become a little cluttered over time. The team briefly discussed potential candidates for cleanup and once agreement was reached, the pair started on the refactoring activity.

It has been a good week at work and I’m looking forward to other ideas that I can steal from them in the future - like GotAPI a handy website reference of most common web programming and languages.

I miss The Show with Ze Frank, NewTeeVee has posted a few “up and comers” that vary from sites influenced by to outright mimicry of Ze.