Meta addiction

New domain, new blog

2009-06-12T06:17:00.002-05:00

After a long period of inactivity on this blog, I've decided that I need something better than blogger. My new blog is at http://www.apcjones.com/blog/.

I'm not moving any of the old posts across, so they will stay here indefinitely.
Bye bye blogger, it's been good.

Low-tech card storage

2007-07-16T17:44:00.000-05:00

An unexpected "feature" of this system is that the sleeves don't go on so far if the pile is thicker; you get some idea of how many cards there are from the width of the overall package.

It's null-time

2007-05-02T11:30:00.000-05:00

My phone line isn't working. I went to the faults website to check on progress:

You scheduled an appointment for: - null . An engineer arrived at the agreed time, however we were not able to gain access to your premises. Would you like to reschedule your appointment?

I wasn't at home at null o'clock, but it seems an engineer didn't turn up either; no card through the letterbox. Oh, of course, they put a null card through the letterbox...

Protect valuable assets

2007-05-02T07:29:00.000-05:00

It was a T-shirt day. What better on a T-shirt day than to wear a T-shirt, and shorts, and cycle to work in the unusual London sunshine? I whizzed past cars. I felt great. What's he indicating for? Oh shit.
I found myself lying on the road, a few feet away from the Mercedes that had suddenly blocked my path. I looked for my bike; it was some way behind.
The driver was apologetic. He noticed my arm was bleeding. I said I was fine. I figured out I must have landed on my head. The bike was fine apart from a crushed saddle. I cycled off, bought bandages from Boots, and got to the office a little late.

Now everything is repaired and my arm and shoulder are healing well. I'm left amazed and relieved that my head is uninjured after a hefty collision with the tarmac of Southwark Street.
So, thanks to the cycle helmet people - mine did the job, and I've bought a new one exactly the same.

Monkey Work

2007-01-02T16:26:00.000-06:00

I met a guy at a party who recently graduated in Computer Science, from the University of York. He has a job, starting this month, for one of the big-four accounting firms. I asked what he'd be doing. "IT Audit," was the department. Apparently this is mostly checking up on IT security, running through check-lists and then suggesting or taking corrective action. Trying to be as polite as possible (although I don't think it came out that way) I confessed that I wouldn't find that very interesting. I might even have used the word "boring". He didn't seem too bothered. "At least I'm not programming, that's just monkey work!"
Monkey Work! I went into shock. Was it just a joke? I don't think I'd told him by that point what I do, so little chance of retaliation for the b-word. At the end of the evening, I apologised in case I'd been too rude. He accepted my apology, but specifically said, "I don't take back that thing about programming being monkey work." Ok then, no joke.
What's my problem here? It's not that somebody else likes IT Audit while I like programming; that's fine. My problem is that a fresh graduate in Computer Science, a specifically technical degree, believes (or at least goes around saying) that programming is monkey work. Programming is not for everyone, and it's possible that students discover they don't like it during a Computer Science degree. But how can they graduate without appreciating some of the skill and ingenuity required to program well? If people who have been taught about computers don't understand what we do, who will?

how big is my potato?

2006-10-07T22:06:00.000-05:00

This important question is answered by my new website, howbigismypotato.com. Check it out.

"Pairing": two's productive, three's a crowd

2006-08-28T18:07:00.000-05:00

I find it productive and rewarding to have two people sitting at a computer. But if three people sit at a computer, things don't go so well. I get the feeling that we usually get less done than with two people, which is frustrating as well as wasteful.
So if somebody comes and joins your pair (probably because you wanted to show or ask them something) I suggest that one person should duck out. I call this "bump pairing" because somebody gets bumped out by the newcomer.

What should you do after being bumped out? You might well join somebody who is "odd" (sitting by themselves). It could be the person left behind by the newcomer who bumped you out: a straight swap. Or you could fill in for somebody missing through a natural break like having a smoke or taking an important call. A different option is to offer help to a complete pair. If your help is wanted then logically you should bump out one of its members. And so another person is free...

Bump pairing could result in faster pair rotation. I think of it as providing a higher frequency wave of pair rotation, overlaid on a more traditional slower wave of rotation. In this model each member of the team belongs to a single natural pair (the one that signed up to deliver a story, for example), but might also find themselves working in a number of short-term temporary pairs. I suspect something like this happens already in most teams, but it is useful to explicitly recommend that trioing is avoided.

Oh, the waste

2006-08-13T23:30:00.000-05:00

How important is wine? In our world where thousands die needlessly each day, and with terrorism on the doorstep, I suppose it's not very important at all. But to throw away whole bottles of good, well-chosen wine pained me immensely.
This morning I experienced some of the new restrictions to UK-related air travel. Liquids are not allowed in the cabin. We heard about the worrying developments of last week while on holiday in Italy, but we thought it would be fine to carry the few bottles we had already picked up in a suitcase. It's been a few years, but bottles of spirits used to make it back fine from Ibiza. Sadly this assumption was wrong and we had to remove 5 bottles of wine from their carefully protected positions in my Oyster luggage and dispose of them. There was no way for us to have them sent separately, and we didn't hold much hope of finding a shipping office open at 9am on a Sunday morning. We gave a couple of bottles to some Germans in the next check-in queue, who were not subject to the same restrictions, and we drunk most of a third before going through security. That left two bottles to be added to the impressive pile of bottles left by other passengers in the same situation. Drinking a bottle of wine in the airport was a surprisingly rewarding experience. A barman at the land-side bar was obligingly removing corks for a long line of us - no British jobsworth here. Then we sat outside in the morning sun - great.

Now I have to prepare for my next planned flight, London to New York on Tuesday. I suspect this will be more challenging. Let's just hope that the new restrictions combined with other action of the security services is effective against the current threat.

Sailing too far from the shore

2006-06-21T15:10:00.000-05:00

I've been looking for a metaphor to describe the situation when too many tests are broken. In the normal course of TDD only one or two tests are broken at a time (generally the new one I just wrote). However, sometimes I find myself breaking lots of tests, maybe lots of my code doesn't even compile. I've come to recognise this as a bad situation, because although my purpose is correct, and the changes I am making are valid, any significant time where my tests are broken (so I can't check in) is bad. The time taken to fix broken tests is roughly proportional to the number of broken tests, so the more that are broken, the longer it will be before I can check in.

Now when I see these signs, I turn to my pair and ask, "Do you think we might be sailing too far from the shore?". To understand the metaphor, imagine that you are traveling along a beautiful coastline in small sailing boat. You progress in a series of zig-zags, sailing out into the sea, then returning to the shore. Dry land represents the security of all tests passing, while the sea is the dangerous world of broken tests. The wind feels stronger over the more dangerous water - perhaps you are traveling faster. However, the further you are from the shore, the more tests are broken, and the longer it will take you to sail back to dry land, or to fix the tests. If something goes wrong while at sea (your compass breaks, your sail tears) then the coast guard tows you back to the point that you were last on dry land. This failure scenario represents having to throw away your changes, and no real progress being made. The change of your excursion failing is greater if it is a larger step, so it could be more efficient to make lots of small excursions than a few larger ones. It all boils down to saying "check in often".

I find this particular metaphor useful because I like to visualise the journey to get the code back into a passing state. It also makes me think about the size of task that I am biting off, and try to find a way to break it down into a series of smaller excursions into the sea.

Smiles and Waves

2006-05-13T07:34:00.000-05:00

Something strange happened in the office this week. First a child's bicycle bell was taped onto the wall, below the hundreds of story cards. Then we started to ring it when finishing a story. Finishing a story is good news, so a few people started to clap when the bell was rung. After a day, and about five rings of the bell, most people were clapping. Then a whisper went round, "Next time the bell rings, we're going to do a Mexican wave." And we did. Now it seems we will be ringing a bell and doing Mexican waves every day for the next few months

What happened here? How did my British cynicism fail to resist this onslaught of enthusiasm? I've shared an office with a sales team before and pitied them for their cheesy whistle-blowing, but I feel that the teams around us don't pity us, they might even be a little jealous. There's a lot of smiling going on and some giggling. Like the best humour, we're laughing at ourselves, but we're also smiling because we're doing a good job, and we've found a way to celebrate.

Whisper Pairing

2006-04-09T14:59:00.000-05:00

This week I lost my voice due to a sore throat. I suspect the trigger was screaming from Furnival Gardens at a very exciting university boat race. (However, medical opinion is divided on whether a bit of shouting on its own can trigger a prolonged sore throat).
The result was that I could only whisper all day long and found it more difficult than usual to be understood. It turns out pairing is a vocally-intensive activity and I had to resort to pointing a lot, as well as whispering. It's funny how people adjust quickly to the volume that others speak at; I'm sure the whole area was quieter than usual.

Pink Dates

2006-03-08T07:17:00.000-06:00

Pink Dates

I looked at this window for over a minute trying to work out which, if any, dates were pink. My girlfriend helped out by confirming that some were pink, but I still wasn't getting it. Then I happened to look at the screen from an oblique angle, and suddenly a few numbers looked different. It seems I was helped out by the relatively poor viewing angle on my PowerBook screen; the alignment of the sub-pixels leads to an occasionally helpful colour distortion.
We all need to pay attention to colour schemes, but maybe I should pay even more attention to usability for people with more serious disabilities than mere colour blindness.

Using Eclipse as an IntelliJ addict

2006-03-01T17:15:00.000-06:00

After 3 solid years of IntelliJ use, I've spent the last two months using Eclipse full-time.
The only two features I've really really missed:

The code generator for equals() and hashCode(). If there is such a feature, 5 minutes of searching didn't find it. Perhaps I need to install a plugin. Besides, IntelliJ's implementation is rock-solid and easily accessible - it's just on Alt-Insert (bizarrely Ctrl-N on the Mac). Even when I had a few medium sized classes to knock out equals() for, it wasn't enough for me to install IntelliJ.
Ctrl-Alt-Shift-N, that "browse for symbol" thing. When I'm trying to figure out what's going on in a velocity template this is a fantastic feature, and this one was enough for me to install IntelliJ in parallel. My problem was solved within a couple of minutes.

Although there were no other features I really missed, the editor still responds slowly and feels cumbersome. To me it's years behind IntelliJ. Both very impressive tools, but my preference hasn't changed.

Late hours

2006-02-10T05:33:00.000-06:00

Why don't pubs close at 11 anymore? Then I would have been chucked out in time to catch a tube home, rather than ending up getting a taxi, and before I had time to drink enough beer to give me a nasty hangover. I need to break the dependency on hearing a bell.

The most satisfying thing to do with source code

2006-01-31T15:03:00.000-06:00

Delete it.
And I don't just mean deleting bad code, in the same sense as you might enjoy clearing junk from your yard. I think it's even more satisfying to delete code that you like, that you had a hand in creating, that you feel proud of.
Deleting good code makes sense either when circumstances have changed so that it is no longer required, or when the code has served as a stepping stone but will not be used in the final solution.

Pseudo-examples

Changing Business

Write code to solve a business problem
Deploy the code into production and use it to run the business
Change the business, possibly due to a short term business opportunity
Delete the redundant code

Exploratory Test

Write a unit test to express how a part of the system should operate
While trying to make the test pass, discover a different abstraction that will be easier to test and implement
Write new tests and implementations using the new abstraction
Delete the original unit test

Refactoring Pontoon

Attempt a refactoring that is too large to complete in one step.
Write pontoon code, possibly many new classes, that will keep the system in a working state while the refactoring is in progress.
Complete the large refactoring after several steps
Delete the pontoon code

Once good code has been deleted, it's like an exemplary citizen - not only did it serve its purpose well while useful, but it imposes no burden on the remaining system after it has gone. Less code can mean less complexity, and a lower cost of change for the code that remains.

Deleting "perfectly good" code might seem wasteful, but going down that road is going bring you to the old fallacies about predicting programmer productivity by measuring their typing speed.

I've started to realise I feel proud when I delete good code, with an environmentally friendly kind of smugness. Hopefully I'm doing my bit to reduce my complexity footprint on the software landscape.

Reducing Risk: Frequent Releases vs Quiet Periods

2005-12-14T06:04:00.000-06:00

Agile methods encourage us to frequently release software into production. However, there is a force pulling in the opposite direction: a desire for gaps between changes, or "quiet periods".

for frequent releases:

Business value delivered sooner.
Each release is a smaller change.
Release process becomes well practiced and understood.

for quiet periods:

No new software defects can be introduced during a quiet period.
If each release requires downtime, keep it to a minimum by making fewer releases.

My approach for dealing with this conflict is to attack the (perfectly reasonable) advantages of quiet periods so that they become less important. For example

If you are worried about introducing bugs every time you make a release, maybe you need to invest more in automated testing, which tests both the code to be released, and that it has been deployed correctly in production.
If each release requires downtime, maybe you should automate as much of the deployment process as possible, so that the downtime is shortened. Ultimately it might be worthwhile changing the architecture so that a release can be completed without any downtime at all.

Of course you should strike a balance. I like the idea of releasing into production every half hour, as flickr is supposed to, but in reality few enterprises can invest enough to make this practical. I think releasing once a day is often achievable though.

A sorry tale of modern technology

2005-10-31T15:44:00.000-06:00

I arrived at the office and opened my PowerBook. It started beeping at me. Oh dear. Seemed fine on the train. Better reboot. Phew, beeping has stopped.
Now a new problem. I get a context menu everywhere I click, as if I'm clicking the right button, but there is only one button. I try playing with the Control key, it seems fine. I try playing in System Preferences, it makes no difference. "Is it the Control key?" suggests Darren, unaware that I have thoroughly inspected it.

And then it dawns on me.

My swanky new keyboard, which I purchased 3 days earlier, is in its box, in a bag, on the window sill, on the other side of the office. And sure enough I left it switched on, and the Control key was being held down by the polystyrene packaging. The wonders of Bluetooth - too much power to entrust to a simple software developer.

Raw coding is nonthinking work, apparently

2005-09-26T23:37:00.000-05:00

I read this in an InfoWorld article:

People go into an offshore deal thinking its only the nonthinking work [they] can move offshore -- the raw coding

Wow, so writing software requires no thought?

Even if it's not required, I will continue to think about the code I write, while my primary goal remains delivering business value. Maybe there was some time when coding had nothing to do with the proper business people who do all the "real thinking", but that time has passed.

blame-culture avoidance

2005-08-14T02:49:00.000-05:00

Who makes technical decisions in a team?
If you are asked "why did you do this, it seems like a bad idea?", the answer should never be "I knew it was a bad idea, but my boss/tech lead/arhictecture department told me to do it". Maybe you disagree with your boss, but it is your responsibility to explain your point of view and the boss' responsibility to explain theirs. You should be making a decision together, not making two decisions and throwing one away. "I knew it was a bad idea" becomes "I had reservations but we went that way because my boss explained..."
A related idea is that everybody in the team needs authority to make decisions, without having to gain approval from a leader. Most people who ask for approval know more about the question than the person they ask. This timewasting distracts from the things that really do need discussion. Pair programming provides a good sounding board for deciding whether a decision requires a full-team discussion. If it doesn't, just go ahead.

Graphic design makes people happy - bah humbug

2005-04-19T14:16:00.000-05:00

Graphic design in software is getting a lot better and making people (like me) smile more.
I'm an outsider to graphic design, but I think what's happened is that design for screen has continued to mature. At one time web design consisted of chopping design for print up into chunks and sticking it in an HTML table. We also had the TV inspired age where every corporate web site had to be introduced by a clunky animation. Perhaps we are now mature enough to see that design features are there to enhance the information rather than distract from it. It's about clear text and simple buttons. It's about being pixel-perfect rather than bold and flashy. It's back to good old fashioned typography. Designers realise again that the empty space around glyphs is as important as the glyphs themselves.
My favourite trick is how gmail seems text-based, and yet if you look closely you find loads of pixel-perfect rounded corners and tiny clever graphics. Like all the best design you don't notice it's there.
As a Java developer, I'm inclined not to care about pixel-perfect rendering of web pages. I tend to feel that the content, the domain model, the integrity of the data, even the usability of the system are more important. The rendering is just a detail, and besides, it's probably somebody else's problem.
I think we should worry about these issues much more. I think that the detail of your GUI has a subtle but significant effect on the user. For example, it makes me smile. I would like to think about these issues as software quality issues, in the same way that we think about bugs. How about raising a bug when one word hasn't been anti-aliased properly, or one pixel is the wrong shade of blue? Generally these things aren't a priority in the business-software world, but it would be nice if they were.
And maybe one day I might sort out my blog template.

Testing software with G-clamps

2005-04-13T16:57:00.000-05:00

Do you like G-clamps? I do. They’re great when you want to hold pieces of wood together while the glue sets, or even better holding a huge piece of plywood to the bench when cutting sweeping curves with the jigsaw.

To get to the point, I use G-clamps most often when explaining how I think about testing software. The metaphor is that I take some part of a software system and put a clamp around it. The part of the system being tested is the part inside the clamp. The clamp has two “ends”; at one end I pretend to be a user of this section (clicking buttons or calling methods) and see what happens, while at the other end I provide an environment for the test (put data in the database or simulate the response of an external system). In this kind of testing there are 3 roles:
1. The narrative of the test, or the tester, pretending to be a user of the system
2. The system being tested.
3. The components not being tested, but which 2 needs in order to work. The behaviour of these components must be simulated.

Or 1. Stimulate, 2. Operate, 3. Simulate (catchy! - not)
These roles map onto a G-clamp as follows:

G-clamps come in lots of different sizes, just as I like to test different sized pieces of my software system. I try to unit-test every part of the system (with small clamps) and I want to have integrations tests that test the whole system at once (with a huge clamp fastened around the whole system).

G-clamps also have some handy properties:
They are mobile, suggesting that you can test lots of different parts of the system with the same tool.
They have an adjustable screw reminding me that I can choose the thickness of section to test.

TDD helps with many aspects of design. One of these is understanding how each component depends on those around it. Although it’s not always possible, it’s desirable for the dependencies to form an acyclic graph, i.e. it’s a good thing to avoid cyclic dependencies. This applies to both large components like tiers, and to tiny components like individual classes. I find it helpful to visualise dependency graphs with the most depended-on things at the bottom of the page. If I draw my components out following this pattern then I find that I always “stimulate” further up the page than where I “simulate”. In other words, I find that all my clamps are vertical.

Where do mock objects fit into this picture? I see them as a convenient way of providing the bottom half of the clamp, most suited to a unit testing scenario, where you are only testing one layer of the graph. Are mocks desirable in all unit tests? If you are testing at the bottom of dependency graph then you are doing something wrong if you are using mocks because there is no lower level to simulate. However my experience is that objects that can be unit tested in isolation like this are very rare.

What type of test is best? (What is the best size of clamp?) Our vocabulary for types of test is poor right now (and some tests probably shouldn’t be called tests at all). I think it’s important to separate the concerns of what you intend to gain from your test, and what the scale of the test is. Also it’s important to appreciate that lots of different test scopes are possible. We tend to think of integration tests as horrible big beasts that use all the layers in our stack, while in reality we can write integration tests for just two classes, and every scale right up to the whole stack. So Alan's quote:

that if you never tested any collaborations with live objects, your rapid feedback test suite had limited use.

Is spot on; your rapid feedback suite should include tests of varying scale, some integrating with “real” objects. These don’t need to be the big heavy integration tests that take half an hour to run; you can write something just a shade bigger than a unit test, or whatever you need to find the things that break often.

In general we could test every line of code many times, just by unit testing, and testing all combinations of adjacent components. My proposal is that all code should be unit tested, and integration tests should exist where they help to trap bugs. So the choice of which scales of integration test are best (or which sizes of clamp are best) comes down to a question of which scales will be most efficient at trapping bugs.