I have the privilege, in my current line of work, to be able to attend quite a number of conferences and other technical events throughout the year. At every event, I meet people for whom this is their first experience at a technical gathering; sometimes they make contact through the pre-conference channels and have many questions about what to expect. For these people, everything is novel; the talks, speakers, and content are all new and often make a big impression on these new attendees. I always advise people not to think that the event finishes when the schedule says it does, and often they will take the opportunity to hang out with the community and make discoveries there as well.
When I chat with these new — or relatively new — additions to our community, I ask them how they enjoyed the event. Almost without exception, they tell me how much they learned, and how much they learned they have to learn! This is the experience I have at every event I attend, and it’s a feeling that fills me with enthusiasm for knowledge and improvement. I have noticed, however, that others take this quite differently.
They tell me that, yesterday, they thought their applications were pretty good, they met their deadlines, their applications worked, and their clients paid their bills. For me, this is a pretty good definition of success, but they will earnestly tell me that they now know this is not the case. After all they see at the conference, they realize there is so much to learn, and their reaction is to be utterly overwhelmed and feel as if “best practice” is something unattainable by mere mortals. (I’m generalizing, in case that isn’t obvious.)
Earlier this year, I was involved in organising the PHPNW conference — the conference of my local user group — where I gave my talk entitled Passing the Joel Test in the PHP World. The Joel Test is a series of 12 criteria that, according to software guru Joel Spolsky, all good software teams should meet. In reality, there are some changes to make to the test, and the original points plus the suggested changes are the features of this talk. I found that after the talk, people came to me and told me that their organizations were only scoring 2 or 3 points out of 12, and many felt that their teams were out of reach of the standards set by the highest-scoring organizations.
This perspective strikes me as being slightly defeatist. The mountain is too high to climb, so the attempt is to be avoided, and the mountain’s existence denied? Nobody who speaks at a conference does so to put people in their place or discourage anyone. Another approach is to take a look at all these new ideas and decide where to begin. Many of the concepts presented at conferences aren’t applicable to every scenario. Some things that you see will rely upon development processes that aren’t currently in use within your team, or may not fit in well. Other things are too advanced to pick up immediately and should instead stay in your mind as ideas to keep reading about, look out for tutorials on, and implement… eventually. “Rome wasn’t built in a day.” This is true of best practices, too.
Improvement is an incremental process, and the next step might be starting to use source control or unit testing or continuous integration or any of a huge raft of other things which would improve our development process or make our lives easier. Making a change like this in an existing development team, which already has deadlines to meet, can be difficult for a number of reasons. One hurdle is that new tools and processes need multiple iterations to select, set up, and implement, and it can be hard to quantify at the outset how much time that will be. New infrastructure may also be needed, which is another barrier. But, perhaps the most frustrating of all is how difficult it can be to implement changes with an existing team. Although we all know that source control (or whatever improvement is under discussion) will make our lives easier in the long run, getting everyone to buy in to the short-term disruption can be truly difficult. Taken altogether, these difficulties can make improvements and better practice seem unattainable.
I’m a firm believer that you can do a lot with only a little. Implementing a new tool is a long and arduous process, or can be, but how do you think those experts got to where they are today? What do you really need to get started with the new improvements? You could install it on your development machine, see how easy (or not) it is to get set up. You could trial it for your own development, or invite a couple of people to try it out for an internal project. Make sure you know where to go for help, to people already using the tool, or an IRC channel or mailing list that might be able to assist if you run into problems.
Having been through setting up the tool once, you’ll know what the pitfalls are and be able to make recommendations about the platform requirements for a tool to be used by the whole team. Once you’ve used the tool, you’ll be able to document how it should be used by others and demonstrate it or train your team. Rolling tools out to a small team — or for one project — can be a good way to evaluate whether these tools are suitable and how the existing process might need to adapt to accommodate them. Internal process improvements can be hard to justify on paper, but as the famous saying goes, “it is easier to obtain forgiveness than permission.” (I use this one a lot.) Make a list of what needs to be done to make it happen, and whenever a few minutes present themselves, chip away at the next bit. The list means you don’t always need to have your eye on the bigger picture in the middle of a busy day, but it also means you will achieve your goal by taking lots of little steps towards it.
As we approach the close of the year, we naturally turn to evaluate our progress and make new plans; my own revolve mostly around the many trips I know I’ll be taking next year for various events. Reflect upon this year, which events were attended, and which should go into the calendar for next year. Consider new ideas to read about and follow up, and give yourself one New Year’s resolution item which you can make happen with a bit of time and effort — to get 2010 off to a flying start. It might seem like a insurmountable challenge to get everything operating as it would in an ideal world, but in fact it can be done… one step at a time!