Journal Articles

CVu Journal Vol 29, #2 - May 2017 + Programming Topics
Browse in : All > Journals > CVu > 292 (9)
All > Topics > Programming (877)
Any of these categories - All of these categories

Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.

Title: An Ode to Code

Author: Martin Moene

Date: 08 May 2017 09:17:58 +01:00 or Mon, 08 May 2017 09:17:58 +01:00

Summary: Pete Goodliffe shares his annual programming practice poem.

Body: 

For the last few years at the excellent ACCU Conference, I’ve shared a short coding poem as one of the lightening talks. (I have to admit that the lightening talks have always been somewhat of a highlight of the conference for me not only because of my contributions. You never know what short nugget of wisdom or entertainment you’ll hear next.)

This year I felt I couldn’t possibly break from this tradition, so I present for your delight this year’s entry. It’s worth reproducing in CVu because: many of the membership are not able to attend the conference, and every time I ‘perform’ a poem, people come up afterwards and ask for a copy. Well, here it is…

Every year a coder here1 will bring a coding rhyme.

Some might be bad, but five minutes is not too long a time.

But often these performances, whilst they might entertain

Don’t do much to help us learn, to teach us, or to train.

So this year, here, I’d like to bring a far more useful thing:

Coder wisdom, earned with scars, that’s set for you to sing.

Hopefully among the other conference presentations

Its memorable, through meter, humour and practical demonstration.

ACT 1

‘Lay code out well’ is our first theme, it’s what we’re often taught.

But should we care? Yes! Let me share one way that I was caught...

One time I worked upon some code of Japanese descent;

The experience was eye opening and led to this lament.

When you can’t tell a single thing about the code you’re reading,

The lack of comprehension makes your working quite misleading.

Without clear names and clean code shape, subtle bugs can hide.

So, syntax faults and code horrors can lurk unseen inside.

It bit us once: to ship this beast with behaviour that was dumb

caused by a missing equals sign (that should stand out like a sore thumb)

We had to spend more than four days on extended bug foray.

If the sign aligned, we’d save that time, and reduce shipping delay.

Whilst you yourself might not have code from more than one location,

The lesson from this story serves as adequate indication.

Care how code looks; the ease of reading every coding line

Impacts the speed of your code feed: you shrink your debug time.

ACT 2

‘Code reviews’ are our theme two, a practice often skipped,

Although without it quality is often seen to slip.

We want the highest standard code, we aim for code hygiene;

Review accountability helps to achieve this dream.

It shouldn’t take much extra time if it is done correctly,

The benefits outweigh the costs; you’ll reap rewards directly.

Is interesting that modern workflows agree that this is best;

It’s seen most clearly used today in Github’s pull request.

You don’t want such an onerous scheme that it is hard to do.

You need to find the review balance that works the best for you.

And, if you don’t – you let your team commit what code they wanta --

Don’t be surprised if over time the code becomes a monster.

Story two that I’ll tell you corroborates this claim,

And shows why code reviewing should be high among your aims.

We’ll see a way a team once failed through poorly managed process,

And hopefully improve when learning from the diagnosis.

To get some software fully built the team, but one, ploughed on

To fix the final showstoppers and get a release done.

A solitary coder split to start on the next thing.

“We’ll join you shortly” said the rest, believing their planning.

But problem upon problem beset the release crew;

And as quickly as they worked they found more work they had to do.

So, rather than a week or two, for months they parted ways,

And the solitary coder worked with no-one to appraise.

He built most of the next release, and built it by himself.

One man writing all code alone may not lead to code health.

His labours worked, the code it ran, so all seemed pretty cool.

But some time later they found out he was a coding fool.

After months and months of coding, the next release was nigh.

There was no time to re-write, so they used his code and sighed.

It was painful but they did it, the next release date met.

But their precious codebase was now stuck with much more technical debt.

The moral of the story told is clear for you to see:

Coding and design reviews help you work efficiently.

Even the most accomplished dev, when given things to do

May get it wrong, and code review helps stop you go askew.

EPILOGUE

So that’s the end of this lecture; my five minutes are done.

I trust the lessons shared with you were useful and were fun.

Now, keep your coding clean and your process goodness showing,

Or else you’ll end up starring in a conference coding poem.

Notes: 

More fields may be available via dynamicdata ..