The three things that make us great: culture, culture and culture

My last post was in response to George Dinwiddie's "What would you like your software developers to learn" question. Here is a follow-up exchange that I wanted to share.

George wrote back to me asking:

Are your developers learning more how to take a long-term view? What steps are you currently taking to help them learn? What steps do you think you should take, but aren't yet, for some reason?

The rest of this post is my answer.

I think that one of the key roles that manager/architect types need to play is that of strategist. As one of my senior developers put it recently: "I know about tactics, what I need is strategy." An ability to predict the outcome of various actions is, in my experience, an indispensable quality in those who are responsible for guiding the overall direction of a development effort.

Some developers care about learning how to do this and some don't. Not everybody on the team needs to be a superstar, and there is usually no shortage of trash to be taken out by those who want to do that (or who lack the chops to do much else). On the other hand, those developers that do want to grow should be encouraged and given the appropriate tools.

On my team, I have a pretty heterogenous group where about 30% of them are interested in learning this stuff. They come from a variety of backgrounds and so some are starting from further back than others. I find that a good strategy for winnowing the grain from the chaff is to offer some of the basic tenets to everybody and see who picks up on it.

We have a 1.5 hour workshop once a week where we go over various parts of our codebase, learn about new techniques, have different developers do presentations on code they have written or had to maintain, etc. Generally I follow up on those workshops with additional attention to those whose eyes do not glaze over when we start talking about certain things.

We also have a very strong team culture that encourages developers to watch each others' backs and make sure that the "social contract" we have all agreed to is upheld. Most of the questions that I listed in my initial answer are things that my guys and gals check each other on all the time. It's a bit of a game: who can find the mistake in the other person's work. This, of course, is all done in a spirit of cooperation and mutual acceptance of constructive criticism (critical components in any team).

I am fortunate to have the leeway to do pretty much whatever I want to improve the current performance of my team. In that respect, I rarely find that there are things I want to do but cannot. This is not the same in every environment, of course, but I select the companies I work for specifically keeping in mind the fact that the most successful companies are the ones that pick the right people, put them in the right place, and get out of the way while they do their job.

At the end of the day I would say that the single most important factor in turning competent developers into excellent ones is culture. I try to lead by example and I expect my seniors to do the same. Every senior on my team had the role and responsibilities long before they had the title. Every junior on my team is capable of training up new juniors (and even some more intermediate-level developers) to be effective within two iterations (four weeks). The culture on our team is one of constant improvement and the juniors frequently teach the seniors lessons (which the seniors take in stride). With the right culture, everything else just seems logical. Without it, you are constantly swimming against the current.
Posted by Iain Lowe (noreply@blogger.com) @ 2008-04-03 16:30:00

From competence to excellence: what developers should know

One of the things that most developers have a lot of trouble with is a long-term view. I think it is critical that there be a very good understanding of the impact of current decisions and design choices on the future of the project and the company. A lot of developers (and in my experience this is only worse with contractors and consultants) have the impression that once the code is written, the job is done. They frequently omit details such as sustainability of the overall system and how easy it will be to make future changes.

One good indicator of a developer's current level of understanding of this concept is to look at the following:

Coding Practices

Does the developer write idiomatic code that would be easy for any other developer to understand given a basic comprehension of the development environment? Are the interfaces to their objects clean, minimal and easily understood? Are the techniques used to modularize their code sparingly and appropriately applied? Do they consistently strive for high coherence and low coupling in the codebase? Do they understand the value of a properly written test suite?

Source Management

Does the developer understand more than the basics of their source control tool? Do they know how to do branching and merging properly? Do they leave clear, concise comments for each commit? Common errors when using SCM tools include incorrect spelling for changeset names (which makes searching for a particular changeset difficult), bundling of unrelated changes into a single changeset (which makes reverting only one of the changes difficult/impossible), linking changesets to the incorrect development task (which makes it difficult to assert that a particular task has been completed successfully) and fumbling with branch and merge (which causes problems when a developer needs to work on some separate task - how do I fork the codebase? how do I re-integrate my changes? etc.)

Development Environment

Is the development environment properly documented and easy to re-build? Can each developer work on any other developer's machine or do they need their "own setup"? Does the development style employed by the developer depend on a specific tool that may not be supported in the future (i.e. web developers who do everything in DreamWeaver, Java developers who are lost without Eclipse's auto-complete and refactoring tools, etc.)? Is the project neatly organized such that it's physical layout (on the filesystem) is easy to understand/explain?

Developers who have a good grasp of the above concepts also usually have a more complete understanding of the lifecycle of a software product (as a product and not as a project). By looking ahead, and by applying certain principles now, we can often have a huge impact on the future maintainability of a system. Maybe I'm just lucky to work with guys and gals that have the basics down pat but I would say that the above is what separates the "software developers" from the "coders". Obviously, there are a number of more basic items that come first but a long-term view of the evolution of a codebase is something that lifts developers from competence to excellence.

Posted by Iain Lowe (noreply@blogger.com) @ 2008-04-03 12:30:00

Asterisk moved into EC2 cloud

I moved the Asterisk server into the EC2 cloud today. It was pretty quick.

Running it off my home box was no longer an option since we have people testing the service these days and I want to make sure there are no outages. I still need to setup a test server so we can test out new configurations before putting them live. I had previously hacked up a little configuration script that shuffles stuff around and performs a couple of emerges. I used the "eminent" AMI that is based on a simple Gentoo install. I plan on putting together my own clean base image at some point in the future but right now this one is good enough. I also plan on building a nice overlay that I can use with portage to update my boxen quickly and efficiently.

FWIW, I figured out how to get Asterisk working from behind a NAT. It was as simple as setting the externip variable in the sip.conf file.

Posted by Iain Lowe (noreply@blogger.com) @ 2008-03-10 20:35:00

Using encrypted SSL keys and certs in twill

Recent versions of mechanize support SSL connections and so, by extension, does twill. Recently I have been trying to open an HTTPS connection to a site that requires both a certificate and a client key. To try this at home, you will need a version of openssl.

The key and cert came to me packaged in a PKCS#12 format file. The first thing I needed to do was unpack the key and the cert like so:

openssl pkcs12 -clcerts -nokeys -in cert.p12 -out cert.pem
openssl pkcs12 -nocerts -in cert.p12 -out key.pem

After doing this, I plugged in the filenames of the cert and key in my twill code. Note that you need to access the underlying mechanize.Browser object when setting the client certificate:

import twill
from twill.commands import *

host = 'mysecurehost.com:443'
b = twill.get_browser()
b._browser.add_client_certificate(host, 'key.pem', 'cert.pem')

go('https://mysecurehost.com/secured_url.html')
show()

The problem you run into when doing this is that the SSL libraries prompt the user to enter the password for encrypted keys at runtime. This makes automating the interaction tricky at best. I tried fumbling with the PyOpenSSL library but it seems that setting a callback for the passphrase retrieval does not actually work. The set method call returns but the callback is never called during key decryption.

My (hackish) solution was to remove the encryption on the key before using it to connect. You can do this by re-exporting the key from the PKCS#12 file:

openssl pkcs12 -nodes -nocerts -in cert.p12 -out unencrypted_key.pem

Now if you use unencrypted_key.pem in the twill code above, you will be able to connect without providing a password for the key.

Posted by Iain Lowe (noreply@blogger.com) @ 2008-01-24 16:34:00

promote Allen Carr's Easyway to other 43ers who want to stop smoking

ilowe completed this goal
Posted by nobody@43things.com (ilowe) @ 2007-11-26 15:05:32

Centralized version control blues

I am in the process of migrating a SVN repository to Darcs. A couple of the changesets in the SVN repo make baby Jesus cry. They create conflicts such that checking them out in order fails spectacularly and you need to go hands with the working directory to clean everything up before moving on. All of this highlights a rather interesting (though totally predictable) issue that plagues centralized version control.

In Darcs, if a changeset is no good, you can just refuse to pull it. Doing so excludes that patch from your repo and no harm is done (unless, of course, a subsequent patch depends on it). In SVN, given that everybody checks into the same repo, by the time you realise that a patch is going to trip you up, it's already in the bloody database. Now, SVN provides no tools for deleting a specific revision (although I hacked together something that I'll try to toss out there someday) so you can't exclude the changesets that put the DB in an inconsistent state. All of this means that I have been wrestling for the past week and a half trying to get this stupid repository to ignore the "corrupted" changesets. Arrrrgh!
Posted by Iain Lowe (noreply@blogger.com) @ 2007-09-21 10:52:00

I don't know what's worse

ilowe added an entry about Read the entire Bible:

Bible-thumpers or those that hate them? You decide.

Posted by nobody@43things.com (ilowe) @ 2007-08-17 04:05:42

My second (almost) working reed

ilowe added an entry about Learn to make double reeds:

I finished my second reed today that actually plays in the chanter. Other than the bottom D and the low G, all the other notes seem to be reasonably in tune. Encouragingly my back D is nice and solid even at high pressure and my high E doesn’t warble like my other reeds.

Unfortunately, my bottom D is about 60 cents flat and my low G is also about 5-15 cents flat. After speaking with Reed Doctor Daryl I am going to attempt to bring the bridle back and lengthen the scrape a bit. I can see that the bottom of the scrape is very thick still and the transition to the middle looks like a bit of a hack job.

Still, not bad for a second reed. I also have managed to more or less get the hang of the wire bridle. I replaced the stupid twist-tie on my first reed with a proper wire and that perked it up immediately.

Both reeds are hard to play and require much more pressure than is comfortable. I’ll try to get the lips thinner next time and hopefully that will help.

Posted by nobody@43things.com (ilowe) @ 2007-08-17 03:55:02

Meet your maker's maker

ilowe added an entry about learn to make uilleann pipes:

Last weekend in Killington I got to meet Bruce Childress.

It was after one of the concerts and we ended up in one of the conference rooms for a couple of tunes. Bruce was there with a new guitar he had made for himself and I managed to spend a good 20 minutes begging for information on the setup he uses for pipemaking.

Mostly he gave me tips on reamer-making as well as a strong suggestion to prefer gundrills over d-bits. Be that as it may, I think that the d-bits will remain much more in my budget in the near future.

I asked if he was accepting apprentices and he told me that he wasn’t. He said the best thing to do was to keep going to events, talking to makers and leeching as much information as possible.

A great opportunity. Thanks, Bruce!

Posted by nobody@43things.com (ilowe) @ 2007-08-16 19:44:33

Pipers' Gathering

ilowe added an entry about learn to play the uilleann pipes:

Last weekend I had the opportunity to spend some time in beautiful Killington, Vermont with a huge number of alternative bagpipe aficionados. We had a number of classes, and there were presentations and talks given all weekend long for the faithful. I had the wonderful chance to take group lessons with Eamonn Dillon, Bill Ochs and Debbie Quigley and managed (after recovering from a slight clerical error) to have an hour of Bill’s time to myself.

I learned a great deal and it was just fantastic to spend some time with so many other pipers in one place. Everywhere I went there were pipes, little impromptu sessions and great people sharing their music with each other.

Both Saturday and Sunday night featured concerts with some fabulous pipers playing Uillean pipes, Northumbrian smallpipes, Scottish smallpipes and Borderpipes.

All in all the craic was fantastic and I’m so glad I was able to attend this year. Events like this are a must for anybody attempting to learn these instruments for which teachers are few and far between!

Posted by nobody@43things.com (ilowe) @ 2007-08-16 19:36:44

Del.icio.us Links

Iain C. R. Lowe

Many persons have a wrong idea of what constitutes true happiness. It is not attained through self-gratification but through fidelity to a worthy purpose.
- Helen Keller (1880 - 1968)

I am a software craftsman living in Montréal, Québec. I work as the Lead System Developer at a credit-card processing company called Pivotal Payments where I build business automation and reporting software. My resumé describes me in point form and my linkedin profile displays some of the endorsements I've received.

I have a bunch of "presence indicators" on the web. My Twitter Timeline shows what I'm up to right now. My Flickr Photostream shows photos I've taken recently.

I maintain a list of the things I'm doing which is a (near-complete) list of the projects on which I am "currently" working as well as a list of places I'd like to go.

The machine

The code I've written is kept in repositories using my favorite version control tool: darcs. I work on a lot of these projects but I'm not always comfortable releasing them for public consumption. Some of them are still in stealth-mode; others are just experiments that don't need to pollute a URL namespace. I do however have a Python XML parser/manipulation library, a write-once distributed filesystem and a couple of other little things tucked away in there.

Justin Francis and I own and operate a little server we like to call home. We are willing to host accounts for anybody who wants one. At the moment the service is free but we may levy a small tax (in the vicinity of a couple of dollars a month) sometime in the future. We offer web, mail and domain name hosting services. We will run pretty much any service you want and we already have PHP, Apache, SQLite, Python, Ruby, Sendmail, SSL and a whole lot more.

The money

In early 2006 I started to teach myself about the foreign currency markets. Some of my trading adventures are chronicled in my forex journal though it remains now more as a historical collection of notes than anything else. I have developed a framework in Python to perform back-testing on trading systems and I have been doing mostly system-testing for the last couple of months. I do have an open "demo" account where I run a coded system. The links to it are on my forex blog. I've also cobbled together a pivot-point webservice from when I was experimenting with fibonacci lines and pivots.

The music

I've been singing and playing musical instruments for as long as I can remember. As a child I played the recorder, took lessons for years, etc. I think I stopped because classical music held little appeal for me at the time. I'm not sure that another type of music would have had more effect on me but it is possible. When I was 8 I took guitar lessons for a week and gave up because I hated sitting in class and writing the dots on the paper. I had learned dots when I played recorder and the structure of the approach to learning was just too much for me. At 14 I picked up my mother's folk guitar and she taught me a couple of chords. Since then I have spent many hours at parties, alone, with friends and with family playign and singing. My brother and I found an old guitar at a bus-stop once. We played it to death. I finally bought my current guitar, an Applause (the Ovation's little sister) at the prompting of a friend of mine ("Lo que quieres, haz lo hoy!").

Cluster of pipes with keywork showing - ilowe@Flickr

Since Summer 2006, spurred by an interest in the crafting of woodwinds, I have been learning to play the tinwhistle. My profile at The Session lists the set of tunes I'm able to play. Many of these tunes evoke strong memories of my childhood, with my father prancing around while the pipes blared from our record-player.

I began the 21-year process of learning to play the Uilleann Pipes in March, 2007. I am the proud owner of a gorgeous cocobolo concert D half-set (the aforementioned uilleann pipes) by Neil O'Grady. I have spent many hours practicing to get back some measure of the mastery of the dots that I used to have. Although I cannot sight-read, I can figure out tunes I've never hear much faster if I have the dots. I am a member of the Quebec Irish Piper's Club, a group dedicated to spreading the gospel of the Union Pipes far and wide. I try to spend a little time every day practicing and so far my progress has been encouraging: it's always easier when the only way to go is up.

Family friend and long-time musical companion, Giulietta DiMambro and I play pipes and accordion together whenever we get the chance. We also have a large repertoire of songs that we sing together accompanied on the guitar that we have built up over the last ten years.

I also collaborate with local dub band Substance Ka. We do a couple of tunes together. The one shown in the video on the website is from a gig we did at a local pub. We've been doing places all over Montreal for the past couple of months. There should be a couple of fun evenings this summer too.