Boy Meets World

Mike is currently…

hanging out in Calgary

[ subversion book ]

obligatory book plug

[ syndicate ]

rss 2.0 feed for boy meets world

[ contact ]

drop me a line

[ about ]

this is mike mason's weblog

[ eskimoman.net ]

original web pages

Fri, 29 Aug 2003

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

People Problems

I’m sitting in the sun, on holiday in Portugal, and I realise I’m having the same kinds of problems to deal with that I do when I’m at work: people. Whilst I work for a software company, the software isn’t usually the most challenging aspect of a project. Technology is usually the easy bit – let’s face it, writing big enterprise applications isn’t exactly rocket science. (If it were rocket science, we’d still have people problems – Nasa’s software might only contain one defect per million lines of code, but if two people get confused between feet and metres it’ll still slam a probe into the surface of Mars at 30,000 miles per hour…) There are plenty of instrinsically-hard technical problems being solved, but these are being worked on by research teams and academics. I found out at uni that this really wasn’t going to be my thing – I seem to be much more of a “technical people person”.

Tech is easier than people. This holiday I’ve been driving around perfectly happily on the wrong side of the road in an unfamiliar hire car, figuring out the lights, where the wipers and gearstick are, how to fill it with diesel, and it’s all been plain sailing. The people, however, are a different matter. I’m mainly trying to relate to the person I’m on holiday with, and it’s fraught with difficulties. We misunderstand each other, have different ideas about how to deal with each situation (mostly getting lost!) and generally have a bunch of problems to deal with. Software is the same – despite what we might like the rest of the world to think, writing an application to add up a bunch of numbers isn’t hard. We just need to know which numbers, and how we should carry our multiplications.

Back at work, we tend to write a lot of software. It’s kind of what we’re good at. We’re so good at it, in fact, that software can end up looking like the cure-all for our people problems. We can just write a tool for this, a script for that, and sometimes you lose sight of the fact that the underlying problems are people problems. Sure, we need to have good frameworks and toolsets for our developers to use, but we should always keep sight of the fact that people write our software, and people are why we succeed or fail. It’s one of the reasons that Agile practices like the daily standup help us work so well. I think most of what I’m trying to say has been said quite well already by the Agile Manifesto.

And on a non-technical note, hanging out in Portugal has reminded me of Speaker for the Dead, which is part of a great series of books. I keep thinking weird things about peoples accents…

Posted 16:58, 29 Aug 2003.

[ permalink ]

Tue, 19 Aug 2003

Out of our control

I’m off on holiday this week, and was contemplating how best to get to the airport. I have to get from my current client site down to Heathrow, pretty much a trek across a quarter of London. I ended up thinking about it in “ideal minutes” and then adding 20% to cover things going wrong, but the strategy I think is most telling is one of avoiding public transport. I’m going to drive home (rather than maybe getting the train to work that day), get a taxi to Paddington (rather than use the tube) and restrict my use of public transport to the Heathrow Express for the journey out to the airport. Ignoring the question of whether public transport in the UK is any good, I find myself being stressed catching the tube, even if everything’s on time and working happily. I think this is mostly because it’s out of my control. When something going wrong is my fault, I might not be happy about it but it bothers me less.

Developers get stressed out by the same lack of control. We spend most of our time (if we’re lucky) attacking problems in code and generally being clever about fixing problems. When we find problems outside of the code — process, management, politics, the canteen food, the neighbor’s cat — we try to fix them too. Failure to fix non-code problems in the same way we fix code problems makes us unhappy.

I’m working on a large project right now, and at lunch we sometimes chuck around ideas for making various aspects of the project work better, smoother, faster, etc, and are generally frustrated with the fact that a big project just isn’t as fun as a small one. Maybe if we just accepted that this is as good as it gets, that big projects are intrinsically more difficult and less sexy, we could stop trying to fix stuff that’s out of our control and be content with what we have. This caused a few smiles amongst those present that lunchtime, but wouldn’t we be happier if we simply worried less?

Posted 14:50, 19 Aug 2003.

[ permalink ]

Mon, 18 Aug 2003

Soundtrack to your life

Last night I was out listening to a friend of mine DJ, and he played one of those tracks that send shivers down your spine. I’ve heard this tune a bunch of times, and asked whether it was from a film or something. Marty replied, “It’s the soundtrack to your life”, and he’s dead right. Music really does stir memories, and even if I can’t remember the exact context for a particular song, I feel the same kind of way on hearing it. I think sometimes I listen to music that fits my mood, but I also listen to music to change my mood. Current favourite “shivers down the spine” tune is Misty Blue. It’s quite interesting to think how the soundtrack to your life has changed over the years – I think I’ve discovered my “thing” with deep house like Tom Middleton.

In other news, it appears imitation is the sincerest form of flattery!

Posted 17:31, 18 Aug 2003.

[ permalink ]

Fri, 15 Aug 2003

TDD in a debugger

My colleage Stacy Curl pointed me at the coolest thing I’ve seen for ages (well, this week at least). It’s Test Driven Development performed with the aid of the Eclipse debugger. The viewlet shows an implementation of the classic Money class, test first, implementing the methods whilst the program is running. Very cool indeed.

The viewlet and original posting by Carlos Perez is here or you can watch just the viewlet.

Posted 20:07, 15 Aug 2003.

[ permalink ]

Thu, 14 Aug 2003

Infrastructure Smells

Tim Bacon posted about design smells, or rather the absence of them, in determining that something is a “good design”. I’ve tended to be involved with “infrastructure” for the last couple of years, both at ThoughtWorks and previous companies, and thought I’d list some infrastructure smells that indicate warning signs for a project.

Lengthy build times

Building a project from scratch should take no more than a few minutes. Building a project incrementally (both in your IDE and from the command line) should take a few seconds. If builds are taking a long time, it could be a sign the project isn’t modular enough, or is simply too big.

Slow test cycle

Unit tests are meant to test one class at a time, and just that class. Even in a system with thousands of classes and tens of thousands of tests, the tests should run quickly. One of the main reasons tests run slowly is that they actually test lots of things at once – it’s common to see a test actually exercising a class and a whole bunch of other components, like the domain model and the database. A test that actually tests your database connection is slow, and in fact likely to be unreliable. Using mock objects is a good way around this – you produce a “mock” database connection and get your tests to use that instead of a real one. Bingo, tests running all in memory with no I/O, blistering performance, and no dependency on your database containing the correct test data.

Frequent merge problems

Having difficulty with merges between developers can mean your revision control system is under-featured, or that you have areas of “high traffic” code that everybody wants to change. Both of these indicate problems you’ll want to correct, either by fixing your source control system or breaking your code into smaller modules.

Slow source control system

Developers spend half their lives waiting for things to happen, and a lot of that waiting can be for their revision control system to catch up with them. I’ve blogged about source control before, but a long update cycle can mean developers don’t synchronise their code for days. This leads to a whole raft of difficulties, increased merge times, and the like. If your source control system is responding slowly, it’s probably one of three things: inadequate hardware for the server, attempts to store large binary files (documentation should be on a different server to the source code), or an inappropriate source control system – use Perforce!

Sluggish IDE response

Modern IDEs allow a developer to do all sorts of fancy code completion, refactoring and analysis of the code they’re working on. If your IDE starts to run slowly, editing code can become a frustrating experience. Slowness can be caused by a lack of memory for the IDE, or an attempt to work on large numbers of classes in a project. An IDE will load and cache information about your classes, increasing memory usage and possibly leading to swapping – even if there’s enough memory, traversing large sets of data (details of classes and methods) can cause the IDE to be unresponsive. A slow IDE may actually be a smell caused by lack of modularisation in your project.

Frequently broken builds

Here I’m assuming that your environment has continuous integration, or at least some other mechanism for determining if a build “passes”. If a project has a high proportion of broken builds, it can mean that your environment is causing your developers problems – not just that they should be more careful with their checkins! All of the other infrastructure smells can conspire to increase the odds of a broken build.

Don’t let it happen to you

Whilst the list might look obvious, most projects don’t start out with half-hour build times and hour-long test cycles. Some of them get that way. Keeping track of a set of “infrastructure metrics” may be enough to ensure that problems are spotted early and addressed. Setting thresholds above which warning messages are triggered could be a way of doing this. In a continuous integration environment, it would even be possible to fail a build or reject a change that causes a threshold to be broken. With a concrete metric, the right people can be made aware of an emerging problem and fix it.

Posted 21:07, 14 Aug 2003.

[ permalink ]

Tue, 12 Aug 2003

RSS Feed Updated

I’ve thrown together some Blosxom flavour templates for RSS 2.0 and switched the link on the left to point to it. The old 0.91 feed continues to work, but doesn’t suport dates or guids for channel items. These two bits of information help aggregators like FeedDemon figure out when a post was actually made and uniquely identify it, so you can avoid reading it twice.

There’s a bit of a power struggle going on in the blogging and syndication world right now. It’ll be interesting to see how things turn out – I reckon RSS will continue to be dominant amongst blogging tools, but we’ll see widespread support for the alternatives when they arrive. After all, converting blog information into a simple XML format isn’t neuroscience. What’s probably more interesting is whether any of the big players like Microsoft and IBM get involved (publicly or not) in trying to leverage the format.

For what it’s worth, I’ll make sure to have an Atom feed once the format stabilises a bit. My Blosxom RSS 2.0 templates are available for download, but you should eyeball them and fix things like the author before using them. To install, just expand the zip into your Blosxom data directory and start asking for pages with a .rss20 extension. For static generation, make sure to add “rss20” to blosxom.cgi’s @static_flavours variable.

Posted 22:39, 12 Aug 2003.

[ permalink ]

Mon, 11 Aug 2003

Laziness Is A Virtue

Good programmers are lazy. According to Larry Wall, creator of the Perl programming language, the three virtues of programming are laziness, impatience and hubris (in that order). I’d agree with the first two, I’m not yet cocky enough to think the code I write is the best it could be. You often see examples of laziness and impatience in the things that differentiate good programmers from mediocre ones.

Good programmers use a decent IDE like IntelliJ Idea or Eclipse, learning all the shortcut keys and hardly ever touching the mouse. Mediocre programmers might use an IDE if it’s forced on them, but don’t know their way around they keyboard, sometimes not even knowing standard Windows mechanisms for highlighting text, cutting and pasting.

Good programmers do something more than once, and figure out a way to do it faster the next time. If they estimate it’ll take longer to build a tool than to do the thing manually (obviously this depends on the number of times they think they’ll use the tool) it’s not worth the investment and they grit their teeth and get on with it. This goes for one-shot tools like a fancy find and replace which needs a bit of scripting – Perl or Ruby to the rescue. Mediocre programmers are often happy to do the same thing over and over, even when it’s pretty dull.

Good programmers realise the answer to most questions is “the computer can tell you”. Much of the time when someone asks a question, it’ll be the kind of question already asked by someone else, or at least the same class of question. This means there’s a tool, a menu option, or a piece of technology that tells you the answer – you just have to put a little effort into asking the question the right way. Performance questions are often the ones where mediocre programmers (or worse, mediocre “heads of development” or “lead programmers” or “architects”) assume they know all about the way a system works and jump right into reengineering bits of it. The computer knows which bits are slow – using a profiling tool is the right way of asking the question, and you’ll get real answers.

Rather than laziness, perhaps the wish to avoid doing boring things is what makes a difference between those who are good or great at something, and those who aren’t. Successful professionals like to share their knowledge and techniques, because it is not just proprietary information that makes them successful. Unfortunately, I’ve often seen mediocre people carefully guarding their knowledge because they think it makes their job safer, and because they don’t want to push the limits of their abilities. Figuring out how to spend more time doing interesting, fun stuff is what most people enjoy about their jobs – I certainly enjoy being lazy and getting the machine to do the hard work. I’m still working on the hubris thing though…

Posted 17:17, 11 Aug 2003.

[ permalink ]

Sat, 09 Aug 2003

My first Blosxom Plugins

I’ve been playing with Blosxom. It’s quite fun, and gives me an excuse to write some easy bits of Perl code. The silly status messages in the top right corner are now generated by a “userstatus” plugin, and the list of other blog links to the right is generated by a “bloglinks” plugin.

Both the plugins were pretty trivial and simply read text from a data file then spit it out with some formatting. Other people have written much better versions (there’s an OPML blogroll generator here for example) but mine do the formatting exactly how I want.

Download bloglinks 0.2 or userstatus 0.1.

Posted 12:28, 09 Aug 2003.

[ permalink ]

Wed, 06 Aug 2003

Things I Need from Source Control

This is a rant. You’ll have heard it before.

I need revision control for my source code in order to make my life easier, store my code more safely, and allow me to collaborate with others. Management need source control to give them a useful and tangible artifact from the development process, and to help them feel happy the developers aren’t going to have their laptops (and the company source code!) stolen and lost.

My source control system needs the following features:

Speed

I want to use source control whenever the computer can tell me something I’ve forgotten, or when it can answer a question quicker than me (which should be all the time). Questions like “what exactly did I change since last night?”, or “which bozo wrote this code?” should take a couple of mouse clicks and achieve sub-second response times. Getting my code up to date with everyone else’s changes should also be fast – the only noticeable delay might be to do with the network or my hard disk.

Automatic operation

Anything the computer can do without my intervention it should do. If I made changes to the same file somebody else changed, and the computer can merge the changes, I don’t want to be asked about it. If someone else deleted a file, I certainly don’t want that file any more, and it should be deleted from my machine too. Source control should make sure my version of the files are as similar to everyone else’s as possible. When a situation arises that the computer can’t deal with, I should be able to easily figure things out and keep moving.

Atomic commit

When a developer makes changes, those changes should be visible only to the person making them. Once they’re ready to let everyone else see them, they do a “commit” or “check in” and submit their changes. This submission should be atomic in the database sense – either the whole change succeeds or none of it does. By “change” I also mean file addition, deletion and move.

And the winner is…

I don’t think this is an unreasonable list of features, but so far I’ve only found two source control systems that actually provide them. First off is the excellent Perforce which I grew to love at my last job, and Subversion, an open-source replacement for CVS (which would make it onto my list, except for the lack of atomic commits). So why is it so hard for people to make good source control systems? And why do companies insist on encouraging these people by buying them?!? Perforce is half the price of the software we’re using on a project right now, ten-times as fast, and we’d lose a lot less time with people accidentally deleting other people’s files…

Posted 20:22, 06 Aug 2003.

[ permalink ]

Why I Love My Job, Part 17

Today I found out that my Ward Number is a quite-respectable 3. And on Thursday morning Martin Fowler popped into the office, the coffee machine in our building was broken, and thus we had an excuse to wander over to a different building and take a half-hour coffee break (well, me and half-a-dozen others!). I returned to my desk feeling refreshed and very positive about life at ThoughtWorks – I guess that’s why they pay him the big bucks!

Posted 19:49, 06 Aug 2003.

[ permalink ]

[ tim bacon ]

musings of an xp coach

[ ian bourke ]

enhancing core competencies since 1976

[ martin fowler ]

a cross between a blog and a wiki

[ alan francis ]

agile != good

[ paul hammant ]

part of the problem…

[ darren hobbs ]

the blog formerly known as pushing the envelope

[ mike roberts ]

on life and technology

[ chris stevenson ]

skizz-biz

[ joe walnes ]

joe's new jelly

[ rob baillie ]

oracle

Registered plugins: SmartyPants, antispam, bloglinks (v0.2), calendar (v0+6i), pluginfo (v1.0), and userstatus (v0.1)
This work is licensed under a Creative Commons License.