Boy Meets World

Mike is currently…

snowboarding in Banff

[ 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

Thu, 14 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.

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 ]

[ 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.