My First Anniversary at Thoughtworks

Riverfire on the Storybridge HotelFor the usual readers, you might have noticed I tend to avoid mentioning employers because my blog entries are solely of my own opinions, and any associations or agreements are purely coincidental. Today is a little bit different (in that I will mention my employer) because this is my first anniversary with my current employer, Thoughtworks.

A little bit about my background. 2005 is my fourth year of being a professional software developer, working my way up from apprentice to journeyman, on towards being a master craftsman. I spent my first two years working for Oracle where my fantastic manager gave me the freedom and challenges to grow out of the all important attitude-shaping years of being a graduate. After working with some agile processes there, I continually stumbled across references to Thoughtworks (all in good contexts) and ended up applying for a job. A few (six) months later, the recruitment process ended and here I am today, one year on as a Consultant working out of their Brisbane office.

I realise that my experiences in consulting have been shaped by the nature of Thoughtworks’ Brisbane office and the commercial landscape of Brisbane itself. Despite initial expectations of projects that last between 3-6 months and involve potentially lots of travel (which I don’t really mind in this stage of my life), it so happens that I have been on the same project since first joining and what travel I did do last year was mainly around my own holidays. I’ve been lucky enough to work on a project involving a larger number of Thoughtworkers, though not as many as I imagine I could have, had I been working out of the Sydney or Melbourne office (something I, as well as many other TWers would like to do).

The project itself has been pretty good, both from a technical perspective and an agile process perspective. It has become ever better this year, with the team having more self-empowerment and ability to manage itself. Last year the project had been heavily based on a single person’s interpretation of “agile” and unfortunately almost all input team members gave from both technical and process standpoints were always overridden (an anti-pattern I highly recommend any budding benevolent dictator avoid implementing if you want to build successful self-empowered teams). Agile is great, but I would love other opportunities to experience other projects to see other people’s interpretation and application of it.

I have been here for three internal conferences, where everyone in TW Oz gets together and I find these amazingly refreshing. Besides meeting everyone else in TW Australia (something we rarely get to do), hearing everyone’s passions for different things has helped me challenge myself and grow professionally this last year. I’ve learned so much about lightweight processes, technologies and strategies from the conversations and exchanges I’ve had with other TWers. I even presented (with the great help of Andy) at our last internal conference and despite being accepted into the Agile India conference, had to pull out due to some poor internal timing issues.

I was bit worried by my age when I first joined, calculating that I would have been the youngest member of our Australia office by at least a few years (not now that we have grads though!). Thankfully everyone is treated is the same regardless of age, and everyone can converse with anyone with the same level of passion or argue with the same level of heat. I do wish that there was a bit more of a structure in place, especially for younger people, to provide a little more guidance/advice, because although I can see where other people are in their careers after years in the industry, it takes me a while to work out how they got there, and work out what else I can do to expedite my journey to being a master craftsman. I find that it is sometimes good to have challenges set by other people as well to build upon your own goals and provide opportunities to outreach what grasp you think you may have.

Consulting (especially on-site consulting) is different from traditional software development. The hours are certainly not as flexible as traditional product development, and on top of the hours you do on site being billable, there are many more that eat into your own personal time, doing the things that have to be done. Besides administrative time and definitely worthwhile time catching up with other TWers, the slack time that many other development shops probably have too much of, ends up being absorbed by consultants in their own time (but we’re lucky we’re so passionate about the things we do).

Being onsite all the time, especially for such a long time certainly affects your own working attitude. I know a lot of the things that came out of my review last year was the end result of maintaining the balance between being passionate about your beliefs, arguing over and defending differences in opinions, delivering business value, growing good working relationships with the team, all while trying to maintain the “professional demeanour” expected of consultants. It’s hard to know how you’re doing with such little feedback and advice, and ever harder to do it better without this continuous loop. Asking for help and advice is the one thing I am trying to do more of, so that I can become better at what I do.

So the good: meeting and working with brilliant people, being continuously challenged, growing significantly from a professional perspective. The could be (and maybe even soon to be) improved: being a single-project consultant, lack of travel opportunities, and more feedback.

The Importance of Grammar in Software Development

Last year, I was reading a number of booking about language structure and grammar, in an attempt to address, what I consider, a deficiency in the Queensland Education system and a further pursuit of my own interest in linguistics. I highly recommend avoiding these types of books unless you are really (really!) interested in the area because most of them tend to be quite boring.

The reward of finishing these, rather dull, books is the discovery of a few interesting facts about languages. The most interesting (ok, ok, bear with me) and relevant one I found is the topological classification of the English language according to sentence composition. In this category of languages (English, German, Chinese), a majority of sentences are composed using the Subject-Verb-Object (SVO) predicate (e.g. John walked the dog). In contrast, the Japanese language uses SOV (As for John, The Dog He Walked), and Yoda used OSV (The dog, John walked).

I suppose my interest in this area is its relevance to my ability of writing clearer code that communicates better intent. One of the touted benefits of Object Oriented Programming (OOP) is its easy mapping to the natural description and interactions between real world things, and our ability to express code our ideas closer to the language we use everyday (for me, English). I’m convinced that if I learn how to write better (learn how to structure proper sentences, apply proper terms, etc) even in basic articles or entries on this blog, then I should have also improved my ability at working out code that communicates more.

Take these two simplistic (and not necessarily ideal) blocks of code:

// Block A<br />public void triggerSpecialNotification(ExecutionResult resultOfExecution) {<br />&nbsp;&nbsp;&nbsp;&nbsp;if (ALERT_CODE.equals(resultOfExecution.getCode())) {<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;dispatchAlarmNotification(resultOfExecution);<br />&nbsp;&nbsp;&nbsp;&nbsp;}<br />}<br />// Block B<br />public void triggerSpecialNotification(ExecutionResult resultOfExecution) {<br />&nbsp;&nbsp;&nbsp;&nbsp;if (resultOfExecution.getCode().equals(ALERT_CODE)) {<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;dispatchAlarmNotification(resultOfExecution);<br />&nbsp;&nbsp;&nbsp;&nbsp;} <br />}

Based on the proper SVO paradigm, although Block B is more susceptible to NullPointerExceptions (and probably why Block A is typically written), Block B is consistently more readable because the resultOfExecution is maintained as the subject for the entire method.

Maybe here is a better example (I’m still floundering to find a good one):

// BLOCK A<br />public void doSomeWorkAndTriggerNotifications() {<br />&nbsp;&nbsp;&nbsp;&nbsp;...<br />&nbsp;&nbsp;&nbsp;&nbsp;ExecutionResult resultOfExecution = runCommand(someCommandObject);<br />&nbsp;&nbsp;&nbsp;&nbsp;someMessagingService.triggerSpecialNotifications(resultOfExecution);<br />&nbsp;&nbsp;&nbsp;&nbsp;...<br />}&nbsp;&nbsp;&nbsp;&nbsp;<br />// BLOCK B<br />public void doSomeWorkAndTriggerNotifications () {<br />&nbsp;&nbsp;&nbsp;&nbsp;...<br />&nbsp;&nbsp;&nbsp;&nbsp;ExecutionResult resultOfExecution = someCommandObject.run();<br />&nbsp;&nbsp;&nbsp;&nbsp;resultOfExecution.triggerSpecialNotificationsVia(someMessagingService);<br />&nbsp;&nbsp;&nbsp;&nbsp;...<br />}

Although the end result is something that could be achieved via a number of other xDD (x Driven Design/Development) approaches, I think this focus on grammatically correctness may help some improve the readability and design of their own code. In fact, it’s almost as if there is an opportunity to build a design tool reviewing code based on standard grammar correctness based on an a given vocabulary (domain specific nouns, verbs and adjectives perhaps described through annotations?). My ideas are still pretty raw, but maybe it has potential…

Making Privates Public

Disclaimer: This code is not for the faint-hearted and should not be used without very good reason (in our case, an external library not giving us access to a fair property of a certain class). Tested only on Java 5.

public static Object getPrivateFieldValue(Object anObject, String fieldName)<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;throws NoSuchFieldException, IllegalAccessException {<br />&nbsp;&nbsp;&nbsp;&nbsp;Class theObjectClass = anObject.getClass();<br />&nbsp;&nbsp;&nbsp;&nbsp;Field field = theObjectClass.getDeclaredField(fieldName);<br />&nbsp;&nbsp;&nbsp;&nbsp;field.setAccessible(true); // make it available outside of class or package<br />&nbsp;&nbsp;&nbsp;&nbsp;return field.get(anObject);<br />}

Sometimes it’s scary how it can be just that easy…

Test For The User

I enjoy Test Driven Development (TDD) for the value it brings out in both my professional attitude (affirmation that tests are important) and my code (driving out design ideas and forcing the code to be easier and faster to unit test). There are times where I get frustrated at not being able to write code as fast I as want (and believe me, typing speed is not the issue – perhaps it’s Java’s verboseness?), and you get lost in all the syntactic aspects of the programming language, thinking about proper class responsibility, maintaining consistency throughout the entire application, and trying to improve upon what is there.

I have witnessed it far too frequently (and also sometimes succumb to) the comfort provided when all tests pass, with a natural conclusion being that all things in our application are perfect. Sometimes I make the mistake of assuming that other parts of the system are just as well tested, and have not changed beneath my feet.

Though there are many (yes, unfortunately not all) of us who believe that the tests we write and automate are important, let us never forget the ultimate acceptance tests for the system we write that our end users may (or may not) give us… their happiness.

Not So Agile Operations

The last two weeks have been rather chaotic with the introduction of a whole set of new environments (one for User Acceptance testing, one for Performance testing, and one for our new Oracle database). We’ve had a number of issues moving to each of these environments, highlighted by both our own set of test suites and by our testing team.

Although all the new environments were supposed to be replicas of production, there were still many not-so-subtle and definitely unintentional and unnecessary differences (such as basic Oracle configuration of the NLS_DATE_FORMAT and NLS_TIMESTAMP_FORMAT values). Working with my, it-doesn’t-work-until-it’s-proven (with a test) attitude, has now lead to a whole new suite of “Environment Acceptance” tests that we can now run against each of these environments to further narrow our scope of debugging to just our code.

It is of great relief to have feedback should these things go awry again, but I’m now concerned that a whole other part of IT (operations management including people like systems and database administrators) may be lacking the discipline (or is it the awareness and importance?) of continuous integration and testing.

Reviewing the weeks just gone

The last two weeks have just flown by with so much happening that I really haven’t had a chance to update the blog. Last week we were fortunate enough to have Martin Fowler (known best for his collection of books such as Refactoring, UML Distilled, and Patterns of Enterprise Application Architecture) down under participating in a number of conference/seminar events. Since I work for the same company he works in, we were even more fortunate when he found space in his busy schedule to spend time with us at a client site on one of our projects. I definitely took advantage of the numerous opportunities to dine and chat with the man, enjoying the time we spent discussing a wide variety of topics.

I also returned to Aikido for the first time since my accident, training with caution so that I avoided aggravating my leg. Upon entering the dojo, I was reminded of its great community spirit when everyone showed their concern by asking where I’d been for the last month. Last week also marked the last day of employment for another mate, Aaron (AKA DJ Anarchy) at my old workplace, which, of course, demanded some sort of celebration late into Thursday night/Friday morning.

Last Friday then saw to the start of my employer’s first “Team Hug” events for 2005. My company creates these conference-like events so that everyone in the country can share their experiences and knowledge with each other. For us working in Brisbane, it is also one of the rare occasions where we actually get to meet all of our fellow employees down south in person. Saturday is reserved for the internal conference (which I’m told tends to be much better in content and format than most other conferences) whilst Sunday is seen as the chance to relax, and get to know everyone else in a much more social atmosphere. This Team Hug was held at the Australia Noosa Lakes Resort and was a perfect location to do work related stuff without feeling like it was work related stuff. It was also my first time to present at one of these events, and despite the nerves, felt like it was well-received. Thanks to Andy for pairing with me on the entire presentation.

This week I was invited (thanks Michael and Sarah) to a pre-release screening of the movie, Ong Bak. Although it’s not going to win any academy awards, as far as action and martial arts films go, this is definitely one to go and see. I never released some of the things that you could pull off with Muay Thai kickboxing and the star of this movie manages to demonstrate them all. Although the storyline is not going to make you think very hard, the fairly decent length (for an action movie)is filled with enough humour, drama and lots and lots of action to keep you entertained throughout.

Make Sure It’s The Master

I recently bought an external hard drive case so that I could back up all of my files. I’ve been running XP (yeah, yeah, I could be using Linux but the software for my Mini-Disc Player and Tablet Pen only works on windows), and thought it would be simple as plug-and-play. I had an old hard drive lying around, so I put it in the case and plugged it in. Sure enough, Windows was nice enough to alert me a “USB Mass Storage Device” was detected, but after hearing that nice little bell that indicates Windows found some new hardware, I was puzzled that no drive icon appeared in Explorer.

Initially thinking that it was my installation of Windows, I tried it on my laptop but to no avail. A quick google didn’t give me any better information, so I went back to basics and tried playing with the jumper settings. Sure enough, it appeared that cable-select mode was not enough and the pins had to be specifically set for Master mode. Now, to script the backup process…

Pair Pong (No, It’s Not About The Smell!)

Pair PongI’ve been a little bit quiet on the blogging front, both personal and work related (or at least it feels that way). The last few weeks have been busy, as I’ve been getting back into my normal routine (riding heaps!) coupled with the preparation of two major presentations. The first of these, intended for an audience internal to my company for this weekend, has had most of my attention for the better part of last month. The second, which had been the focus of this month, was for the Agile India conference that I had been accepted into. This presentation (more like a workshop), titled, “Priming the Pair Programming Practice For Production” (I couldn’t resist the alliteration), was aimed at providing an environment for people to experience pair programming first hand, with the benefits of coaching that would usually be lacking in the workplace.

I had been designing the session to expose people to both the benefits and challenges associated with this practice that is best learned with hands-on experience. Unfortunately for me, due to a whole series of recent events and bad timing, I have had to withdraw from the conference.

Now that I will not have the chance to actually run my workshop, I may as well describe what had been planned. In addition to going over the thinking behind pair programming, all of my exercises had been designed to give as much practice as possible, coupled with constant feedback, to pair programming and other agile practices. The first two exercises were intended to be fairly trivial, a programming problem to be tackled in pairs, the second, a pair programming refactoring session. I was probably most looking forward to the third exercise (especially from the participant’s reactions) which I had named “Pair Pong”, after the game “Ping Pong”, combining pair programming with the agile practice of Test Driven Development (TDD). Much like the real game, a token (in this case, a keyboard) would be constantly passed around between the pairs. One partner would write a test case to represent a requirement out of a given list, while the other would write enough code to get it working. The roles would swap and the game would continue until all the requirements were complete, with the aim of the pairs to only ultimately communicate via the code they passed between each other.

Although the “Pair Pong” concept is not new, I think associating it with something that everyone can relate to can make it easier to actually implement. I’m sure I’ll have an opportunity to run with this workshop one day; I just know it won’t be next week.