Managing technical projects

Low Impact Management also applies to running technical projects. Micro-managing is a waste of time and energy, and drives developers to despair.

Introducing agile techniques such as pair programming and short iterations through example and opportunity, rather then by mandate and overbearing authority, ensures that developers feel comfortable picking up new techniques, and reduces the risk that they’ll feel pressure to perform.

Pressure is no bad thing, but as a manager you should ensure that your programmers work in a framework where a bit of pressure gains results, rather than simply increasing stress and fracturing the team. Developers tend to be the kind of people that perform well under stress, but they shouldn’t constantly be fighting agile build systems, or have new techniques forced upon them. Many agile consultancies see their ideas as the silver bullet that, once applied, makes any developer perform, and any project succeed.

Those of us that have read the book know better.

Ten years ago, OO using Java was the silver bullet. Before that, CORBA ensured a strong revenue stream for technical consultants. What we have to learn is that there isn’t one practice that works 100% for every team, and that we need the wisdom to pick and choose from the best of the bunch. That’s where agile consultants can earn their bread – through advice rather than proscription. It’s Low Impact Management.

Silly season

It’s silly season at work. There are two every year. In the summer, the place is quiet because the staff with children take the opportunity to go on two-week summer holidays. Nothing gets done, so you can plan ahead and get a stack of things ready to do then.

It’s a good time to work in isolation, not least because no emails you send or voicemail messages you leave are going to be answered for a while. Get used to finding things to do.

It was even worse when I worked for a large Anglo-Swedish pharmaceutical manufacturer. Sweden is heavily unionised, and the entire country effectively went on holiday for six weeks in the Summer. Completely ludicrous, but the third rail of management was trying to do something about it, so it went unspoken. Half the firm ground to a halt over the summer. The other half, of course, was in America, and they thought they were running the show.

Christmas is the other quiet time, when virtually everyone takes holiday. That seems really silly to me, becuase there’s quiet often nothing to do for those left in the office. Most people are there on production support, but their users are away drinking mulled wine at home. The others take long lunches and work short hours, which, to my mind, makes it a great time to be at my desk.

Whilst I’ve got all this time, I’m trying to learn New Things. I’m brushing up on my C++, and trying my hand (again) at Python. I bought the O’Reilly book years ago and never read it, and I’ve just installed the fantasic IronPython Studio, so now is a perfect time to give it another go.

Here’s a list of things to do:

• Tidy up your project website.
• Comment your public API.
• Clean up your source control repository.
• Arrange your stationary in reverse order of size.
• Learn a new programming language
• Learn the double-checked locking pattern
• Learn about exception safety
• Learn erlang.

Hiring good developers

Hiring good developers is hard. It turns out, there just aren’t that many out there. Occasionally, you’ll get lucky. You’ll look further afield and find a pocket of clever people, but you’ll bring them all in on tasty salaries, only to find that they all clock off at five pm, or they want to re-write everything you’ve got in erlang.

Well, that’s just tough luck. From what I’ve seen, the best way to ensure a great time is to hire hard. When we interview C# developers we tend to ask C++ questions. You’d better know your memory model inside out, because anything on your CV is fair game.

There’s nothing more painful than watching an average candidate fall apart because she put ‘Advanced Java’ on her list of skills, then didn’t know static from abstract, but it happens all the time. The thing is, we want you to succeed, we really do. Most of us enjoy interviewing because it’s a chance to geek out with someone who has the same interests.

We interview hard – you’re going to have at least two hours of technical interviews before you get hired, but the single most important question we ask ourselves, after every interview, is “could I work with this person?”. If the answer isn’t a resounding “yes”, then the answer has to be “no”. Sorry!

But it has to be like this. If it weren’t then you’d end up with people you like but who couldn’t do the job. In the best cast you’d end up resenting them. In a small firm, they might have an effect on your company’s bottom line.

Boo: Niche programming languages

A colleage recommended, last week, that I look at the Boo programming language.

There are certainly some lovely features. I’ve been writing lots of F# recently, and have developed a great love of Type Inference. Similarly, lambdas (albeit fairly immature ones – they look like anonymous delegates from C# 2) and their logical offspring, first-class functions.

I love the idea of a compiler that checks your spelling! It can be a maintenance nightmare to clean up after a colleague who can’t spell, and it’s quite necessary. FxCop helps if you make it a post-compile step, but it’s fiddly to do, and takes some time to reflect over your assembly. Much better to have something analyse your source.

But I can’t bring myself to like duck-typing. Simply put, duck-typing is an attempt to escape the strictures of static typing in a static language. You’ll hear enthusiasts saying things like “it’s my <thing>, why shouldn’t I be able to treat it as a <other-thing>?”. Well, the point is that it’s not your thing, it’s the compiler’s. And the reason you can’t treat it as a other-thing is because it isn’t one.

It’s true – I often find myself saying to the compiler “Just trust me for a second, ok?”. I’m sure we all do. My current gripe is that circular-dependency hell you can get into while editing a XAML document when the code behind (in the generated code) is incomplete. The XAML won’t pass type-checking because the generated code is incomplete, and the code won’t compile because, well, you can guess. Sometimes you just want to turn off a bit of time compiler, or do two runs for the thing to compile, like you do when you want a Table of Contents in your Latex document. On second thoughts, maybe not!

There are all sorts of issues of self-documentation, of course. Languagues like C# make it fairly simple for the next guy to work out what your intentions were from the code. F# moreso, I would argue, and part of that intention inference is knowing what kind of things you’re dealing with.

It’s slow, too – the CLR is implicitly statically typed (the DLR does a compilation-and-memoization stage at runtime as functions are called, so at the moment of invocation your method is static), and to get past the type checker your functions have to be called using reflection. Not Pretty.

User-defined languages extensions? Silly! Firstly, you have to know about (and code to) the internals of the language compiler to introduce something to the language. At first glance it seems like quite a nice model – we’ve sometimes wished that we could get a hook into the compiler to play some games with the syntax, but you lose the benefits of the IDE if you end up introducing language extensions. Unless, that is, the language service uses the language extensions you’ve defined, which I doubt.

Once you put some thought into it, though, most of the things you’d like to see in your favourite language either already exist in another one, or are so common that everyone would define them as Boo macros, at which point they should probably be introduced into the base language anyway. If your favourite language isn’t evolving, maybe it’s time to drop it?

Low impact management

I want to explain a little about how things worked in a team I used to work for. I’ve been lucky enought to work with a few really great groups of people in my short career, so I think I’ve picked up a couple of hints.

When I first started work in my job, I was straight out of university. The bank had sent me and forty or so others on a long training course to get us up to speed with how things worked in the office: mostly proprietary technology and advanced Java. We had a fantastic time! I probably learned more in those few weeks than in three years at university, and drank enough beer to match, too.

After that, I ended up in an infrastructure group building and maintaining .NET libraries for application development groups. It was a fairly hardcore scene, and I had to learn really fast. The firm’s infrastructure team are amongst the best developers in the world, so I had lots of great people to learn from. Amongst the ranks are rocket scientists we poached from NASA, and two (count ‘em!) chess Grand Masters.

But after 18 months I was well on my feet, and was confident in my knowledge. People asked me questions, I taught classes, and meanwhile I wrote a lot of code. For a time, when my project leader was in New York, I ran the project in London. I presented at internal technical forums, represented the firm at universities across the country, and even appeared on the recruitment pages of the firm’s website!

Looking back, some of people that had been on the training course with me, back when we started, hadn’t been as lucky as me. Many of them were better, technically, than I was. I’ve spent some time thinking about what outside factor had given me so many opportunities to do well, and I think I’ve cracked it.

It’s the team, stupid

My team was fantastic. Being around really smart developers drives you to excel. My boss called it the Symphony Orchestra effect – if you’re at college learning the violin, and practise hard, you’ll do well. If you’re stuck playing in the middle of a symphony orchestra you’re going to excel. You’re going to be the best young violinist you know.

We were doing some really cool things, too. For a geek, it was absolutely the best place to work. We wrote compilers, took things apart, broke Garbage Collection, and fed code into the Microsoft Machine. My boss had this talent for encouraging you to get stuff done without being heavy-handed. I’ve called it “low impact management”.

It means not caring about presenteeism – if you’ve not got any clean shirts, work from home. If you need to pop out and run an errand, do it. As long as the work gets done. And it did (and then some!), because we enjoyed all the cool things we were doing.

We ate and drank together. We went for lunch mostly every day, with our wider team. And we’d talk whilst we ate – it’s terrible for digestion, but you get a really good feel for what’s going on around you. That makes you more knowledgable, and more valuable. On Fridays, we’d all troop down to the pub for lunch.

Quite regularly we’d head out drinking in the evening, too, because we enjoyed each others’ company. Your nearest management consultant would disagree with me, but I maintain that the single best icebreaker is to get a team into a pub with £100 behind the bar!

We didn’t really go in for agile development, but we did have a Stand-Up Meeting, and it worked wonders. Instead of being separate groups of people divided by oceans, we became a team. Instead of complaining about Sally not checking in her changelist, or David not releasing his patch on time, we’d call those guys and have a chat.

Low impact management caused all that. Our boss rarely mandated anything – he led by example, and by influence. It didn’t hurt that, in his time, he’d been a hot developer himself and could still give most of us a run for our money at times.

He never played political games with people that worked for him. Senior management are fair game, but he knew better than to lose the trust and respect of his staff.

It’s difficult to do – once you’re in a position of power, to give it up. It must seem like things are going to fall apart if you don’t keep tight hold of what people are doing, but it’s rarely the case. If you’ve spent a while hiring the best people for your group, the least you can do is trust them to work hard and do the right thing!

C# 4.0 Wishlist

Everyone under the sun has done one of these, so I’m going to change tack a little.

Two things I wish Hejlsberg would nick from F# for C# 4.0:

Tuples – simple, ad-hoc types with members accessed by order rather than by name. Take the example of being able to return a host/port pair. In F# you can say:

let getHostPort(servicename) =
 let host, port = serviceBroker.GetDetails serviceName //this function returns a tuple
 (host, port)                                          //this is what we return.

In C# you’d have to create a class (or worse, an inner class!), as anonymous functions don’t really keep well out of their function scope.

Options – are a nice way to handle null. I’ve always hated how you can end up with null as the return value of a function just because some lazy hack couldn’t be bothered throwing a decent exception, or in some misguided fit of premature optimisation thought it would be better to have me check the return value of everything I call against null.

Options are a way to declare that a variable can either be a typed Something, or a Nothing. Underneath, they use null to represent the Nothing, which is fine – it’s kept well away from me and the consumers of my code.

I can legitimately say that for a valid request there is no result right now, or throw an Exception on an invalid request. But the type of the return value is Option<T>, rather than a T which could be null. Nicer, see?

I’m sure there are more things, but this is a fairly good start. I’ve been writing F# for quite a few months now, and going back to C# feels dirty. C# is making great strides towards functional programming (with lambdas and anonymous types), and I’m no Functional evangelist, but I think those two would be a great practical addition to the language.

You have to be careful with Tuples. There are certainly situations under which they can be misused, and you should think carefully before you expose them via your public API. The values have no names, so your code (if it ever was) is no longer self-documenting, and difficulties with the way they’re implemented in FSharp.Core make reflection difficult. But used wisely, and with the right tweaks to the language, they could be a great boon.

F# on Monodevelop

From Don Syme’s F# blog: Wildart has released an F# extension for Monodevelop, allowing .NET developers on platforms other than Windows to embrace functional programming.

This is great news! The F# team have worked hard to ensure Mono compatibility with the F# compiler, interpreter, and libraries, and it’s great to see that the Mono community takes F# seriously.

Little Plastic Squares

I’m a .NET developer, and I work in a large financial institution in London. I don’t think I can reveal who I am, but I won’t be posting anything work specific anyway, so I’m not too worried about concealing my identity.

Little Plastic Squares won’t be too much more than a collection of links and code snippets that people might find useful. Let’s kick off:

MPI (Message Passing Interface) for .NET: MPI is an alternative to request-response based cross-machine work distribution architectures that you often find running grids.

With MPI, you define the path that data takes as it travels through a set of grid nodes, as well as what actually happens on the node. When data gets to the node, some work happens, and the node knows which other node to send the result to.

MPI has been in academia for ages, and is one of those things that, because Moore’s law doesn’t work any more, the “real world” is starting to notice. cf Functional Programming, Transactional Memory.

This implemetation is nice because (1) it doesn’t force the developer to use the actual function-calls defined by the interface (“MPI_INIT” etc), and (2) it’s supported by Microsoft’s WinHPC suite.