Wednesday, 26 October 2011

How to waste three hours

Earlier today (aka "yesterday") I wasted a few hour trying to figure out why Smarty hated me. In a project I'm working on, I need a navigation bar that appears on every page, so it's natural to sequester the navigation bar HTML into a sub-template. In the page's toplevel template, I had:

but when I refreshed my page, the navigation area contained, literally, {include file="mainmenu.tpl"}, and not the menu HTML as I expected.

It was just me though: Smarty was singling me out! Its own demo template also includes a sub-template, but that worked just fine.

Round and round I went, trying random settings. Perhaps Smarty wasn't finding its "sysplugins"? Or maybe it had cached Something Bad from an earlier attempt that was wrong for different reasons. Refresh, refresh, fiddle, refresh, curse!

Eventually I got so frustrated I started questioning the fundamentals [1]. Do variable expansions at least work? {$foo} — No! Not working! Just another grinning curly brace pair pseudo-emoticon taunting me in the browser tab!

At least the light went on. Then I discovered what I had forgotten:

$smarty->left_delimiter = '«';
$smarty->right_delimiter = '»';

Guillemet! (I need different delimiters to avoid having to escape CSS declarations sprinkled all over.) Having fixed my Smarty syntax to use those sneaky U+00AB and U+00BB instead of those ubiquitous curly braces, order is restored. Everything works again, and I shall hopefully never again forget that I am using nonstandard delimiters in this project.

[1] Why do I seem always to question my assumptions only when I am at the end of my tether? Recognizing this pattern is as frustrating as knowing that whatever I look for, will only be in the last pocket I search.

Tuesday, 25 October 2011

Another cost of staff turnover

At an undisclosed business, there has been a history of complete staff replacements over the years. In fact when I started working there, the entire development team (two people) had recently quit and left, with a night watchman soaking up as much as he could during their notice period and then helping me to wrap my head around things.

I coped quite well overall; somehow I was able to assimilate most of the important areas of the project quite quickly. It helps that I actively enjoy reading code - if only I knew how to get paid for rendering a code review service.

But every now and then, and invariably in the code that deals with Berkeley DB files, there'd be some lurking anti-aesthetic singularity, an infinite source of code entropy. Just reading that code makes me want to cry - it is beyond the point of equilibrium between fixing and introducing bugs. And because I rarely need to fight a fire there (which seems a miracle), I have had only sporadic and patchy understanding of it - I never truly grokked it all. Perhaps if I had spent twenty years working there instead of only four, I would have accumulated enough brain circuitry to achieve that level of oneness with the code.

That is the problem: nobody ever did - nobody from any of the previous development teams held tenure for even as short a period as I did. (Actually the night watchman is still there, in the morning, the following week, but he deals nearly exclusively with the codebase he and I accidentally rewrote - a codebase I like to believe is not yet at entropic equilibrium.)

This is a problem that costs you, whether in profit as an owner, or in boardroom clout as a manager, or in customer perceptions as a salesperson. It costs you because when there is a problem in such hairy code we aren't familiar with [1], we can't make any reliable estimates, let alone promises, about how long it will take to fix, or even if it is possible at all to fix. In statistical terms: this unfamiliarity represents a high variance in the cost of doing our business of software development.

So quit thinking of people as perfectly interchangeable units of production, as commodified development resources [2]. We might all be capable of learning new technologies, of gaining an effective familiarity with most of the work we do, and of replacing colleagues. It isn't a cheap replacement though - not like you can schedule one night of downtime in a factory and replace a few bearings. And as far as corporate lackeys, worker drones, and cogs in a machine go, we're a pretty expensive means of production. So keep your machine oiled, and try to keep the sand out. Do the fuzzy math - figure out what level of oiling and maintenance is cost-effective.

[1] You may argue that it is our (developers') job to become familiar with the code. But at whose expense do we study this rarely-visited code? Do we stop developing the new features you clamour for in order to study code we might not need to change for another few months? Shall we ignore other, directly visible bugs? There is a significant opportunity cost to having developers do anything, if we aren't sitting around waiting for work. (Yes, sometimes we goof off, and there lies a valid criticism - but not the same one. And normally we try to make up the debt somehow. We might not write it down on paper, but we - I anyway - do mentally "keep score".)

[2] The company where I worked before the undisclosed business that is the setting of this post, had a penchant for referring to developers as "resources" - both in speech and in writing. I understand that "resource" is a fairly standard part of the project management jargon, and is quite appropriate in that abstract world where one is pushing long candlesticks around on a Gantt chart. I find it quite offensive, though, to use such a dehumanizing term in reference to particular people and teams.