It’s the People, Stupid!

I’m a career technologist. Building software systems that people find useful (as possibly love) gives me a great thrill. I’ve spent more than 25 years learning many arcane bits of knowledge that makes it possible for me to contribute to the construction and maintenance of these software constructs.

Historically, I have mainly focused on technical skills and software development techniques. I tended to avoid practising “softer” skills such as communication, leadership and mentoring. In the last couple of years, I had an epiphany, and changed emphasis to include those things.

The first thing that made me reconsider was a private conversation with Jeff Fredrick (who should really tweet and blog more – he knows too much good stuff). I’ve forgotten the exact details of the conversation (it was a couple of years ago), but Jeff talked about his career development, and his deliberate choice to move into technical leadership (he’s now CTO of TIM Group), and the people skills he needed to make the transition. We contrasted that with my own career choices (mainly “keep my hands in the code”). I recall his main point was that learning the people skills made him much more effective as a technologist (in the land of the blind, the one-eyed man is king!). Essentially: it’s the people, stupid!

It didn’t change my behaviour straight away, but it made me think harder about the skills I had been neglecting, and seek out better ways of working with people. With a hat-tip to people like Bob Marshall, Ben Mitchell and Jeff Fredrick who pointed me towards the reference material, here’s the main things that I feel have contributed most to my development over the last couple of years:

I’m still working in the code, but as the above list shows, I’m working towards using empathy and humanity in my work. As always, it’s harder than it looks.

I am a Thought Follower

Some musings on professional software development…

I’m a software developer with 20 years of professional experience. I’ve make all the classic mistakes, and learned a few lessons on the way. I’ve sought out better ways of creating software that really delights users, creates value and solves problems. I’m continually making use of the experiences and reports from the field, watching for the tea leaf readings of various writers, bloggers and speakers: thought leaders. I am a thought follower.

The way we develop software has changed a huge amount in the last 20 years (at least, for some). I’m standing on the shoulders of giants, and I sometimes think to myself that I’d like to contribute something back. I’m coming to the conclusion: that’s the wrong direction, and the wrong question (at least for me). For most of us, we should be trying to apply what we have learned consistently and across the board. I’ve never worked yet in a place that did everything perfectly (and by the way, what is “perfect”?). Many places have a large number of technical, cultural and bureaucratic roadblocks to real improvement.  Recognising,  understanding and resolving those issues are the best way to achieve real improvement.

A dark and hideous thing re-emerges

Well. That was a bit longer than expected. I’ve finally retrieved the slime-covered remnants of my blog, attached bolts to its neck and re-animated it with lightning.

For something that I took down for “a few weeks” while I changed hosting providers, it ended up lying pretty much dead in a ditch for nearly 3 years. All it took was for me to take a week off work between jobs, and finally get around to dusting off the WordPress database backup, and working out how to ram it onto an EC2 instance, which then involved a lot of time with setting up an Amazon RDS database instance, and working out how to connect the bits (which was surprisingly fiddly).

Airline Story

This is my flight from hell story (long posting!): after being delayed 11 days by the volcanic disruption, I finally got on a flight from Sydney to London via Bangkok. The flight from Sydney to Bangkok flew OK, but movie system wasn’t working – not great with 2 kids (luckily they mostly slept). We stopped 2 hours in Bangkok and then taxied back to the runway. The pilot applied full thrust and we accelerated down the runway, but he then suddenly cut all thrust after about 5 seconds. It was actually a pretty scary experience – I knew we had plenty of runway left, but you’re left wondering what would have happened if we’d been further down the runway when that happened.

What happened next was not a shining recommendation of the airline. The pilot explained that there was a warning indication on one of the engines. We were kept on the plane another 2 hours while they worked out if they could make repairs. The air conditioning wasn’t working, and it was getting extremely hot on the plane. They finally decided the repairs could not be completed, and we were told that we’d have to stay the night in a hotel in Bangkok. Note that this is a city that is currently having violent clashes between anti-government protesters and the police. Tourism advice centres recommend to avoid this city, and now I’m being forced to stay here.

In the end we were sent back to the terminal (this was about 3am). We where herded through Immigration (they had to organise a special visa for us), and sent on a bus to one hotel, but we actually ended up at a completely different hotel (apparently the first hotel couldn’t fit us all in). They gave us food vouchers, and that was it. It was 5am, I was stuck in a strange city, with no idea of when I was going to be able to get home, and no way of contacting anyone in the airline to ask questions, and realising that I’d left my laptop on the plane. This was on top of the stress of being exiled from London for the previous 11 days, and desperate to get back home. It was one of the worse days in my life, and I’m afraid I didn’t react very well to the situation.

I pestered the hotel staff for information, but they weren’t really able to help at all. It was finally around 10am that I found a letter from BA sitting on the counter in the lobby, which said that the flight was rescheduled for 11pm later that day. It was a relief to finally have some concrete information, and I was finally able to relax slightly.

At 3pm the BA airport manager came to the hotel to talk to us all. He explained that the problem was due to the fuel injection monitoring system on engine 4, and a part need to be replaced, which was being flown in from Hong Kong. At this point I realised that I might not event get home that day, which made me more upset. When questioned, the manager said that there was a 30% chance that the repairs would not be complete. However, they would still have to assume everything would be ready, and get us through check in, emigration and security to ensure we could hit the take off window. It was a lively meeting: there were a lot of people in the same situation as me, and this was the first airline representative that anyone had actually met face-to-face through the entire SNAFU.

Suffice to say that the plane actually did take off, with much cheers from everyone on board (and my lost laptop was returned!). However, there was one more insult to injury: when we (finally!) landed in Heathrow, our baggage got stuck for about 90 minutes. No one had thought to organise baggage handlers and a carousel to return our luggage to us, on top of which there were two BA10 flights landed within minutes of each other (our delayed flight, and the next day’s flight), so there was a lot of confusion about where to go. Eventually, we had about 300 people crowding 10 deep about the smallest carousel in the airport, while next to us the biggest carousel was empty.

Anyway, I’m home now. I now have a fun letter to write to BA customer relations.

The End.

The Meaning of Guru

Today I met one of the managers of the development team I work with in India. I was chuffed to learn some people call me “The Guru” over there. The manager went on to mention the etymology the word:  ‘Guru’ is composed of the syllables ‘gu’ and ‘ru’, the former signifying ‘darkness’, and the latter signifying ‘the destroyer of that [darkness]’, or the ‘bringer of light’. My own manager quipped that the light in question was actually the reflections off my head (probably a fair call, but I actually think the light shines forth from another orifice).

Singletons are Evil 2: the Rant

I’ve wrote about this before, but singletons really are evil. It’s worth repeating, as I’m finding out that the message hasn’t really reached a lot of people yet.

I’ve been helping out with interviewing candidates for a senior developer/technical lead/technical architect role at my current client. To my dismay, there is a very consistent problem across all the canditates I’ve met: they all like the Singleton pattern. The converstation usually runs along these lines:

Me: Can you name any design patterns?

Candiate: Singleton
(they will usually name a few more patterns, but Singleton is almost always the first one named)

Me: Can you tell me about the pros and cons of Singleton?

Candidate: They’re really useful, I use them all the time! They ensure that you only have a single instance of an object at any one time. Also, you don’t need to pass references to them, because they can be accessed directly.

Me: OK, are there any problems with the use of singletons?

Candidate: Umm… you can sometimes get multiple instances if you use multiple JVMs.

I’m starting to use this as a weeder question in interviews now. I don’t care if your resume says you have 8 years of experience in enterprise Java. If you’ve got that much experience, I’m hoping you’ve heard (or discovered yourself) that Singleton make code brittle and harder to maintain. I don’t mind if you use Singletons on rare occasions (I do it myself sometimes), but you really need to be fully aware of the problems that they cause.

You can view my previous post for a list of links with more details, but in summary, some of the problems are:

  • You lose control over memory management. It’s basically a resource leak.
  • It promotes tight coupling. Need an implementation? Go to the singleton over there! However, by hard coding the singleton class, it makes it harder to mock, stub out or otherwise change.
  • It hides dependencies. It is harder to spot from the public methods of a class that it makes use of a singleton service.
  • By mixing the responsiblities of providing a service, and managing the object lifetime (badly), a singleton violates the Single Responsibility Principle. If you only want a single instance of a class, create one at the start of the program and pass it objects that need it. If you use something like Spring, you can even declare in configuration that an object is a singleton. No need to hard code that policy in code!
  • A Singleton in a multithreaded environment can be tricky. Make sure that you handle all the edge cases!
  • As Stevie says, the Singleton “pattern” encourages you to forget everything you know about OO design, since OO is hard, and procedural is easy.

There are more problems, but that’s a good start.