Who owns the backlog?

A conversation about bug lifetimes came up in a Slack discussion at work today, and a core question came up, that really summarised the entire tenor of the conversation: who owns the backlog?

The answer, if we’re being honest with ourselves, is everyone. The backlog of work to be done, and the prioritisation of that work, is not the exclusive province of any one member of the team, or any one group within your organisation. Everyone who has a stake in the backlog owns it, jointly.

No, seriously. This is especially true if you work in an organisational structure similar to Spotify’s popular squads model. It’s definitely a much more refreshing take on the division of labour than the fairly typical siloing of The Business, The Developers, and The Testers. Admittedly, even then, there really isn’t much excuse not to own your backlog, but when your work priorities are determined by someone on the other side of the office (if they even work in the same building as you), it’s at least understandable that developers might not have as much say about it as they’d like.

But at the end of the day, if you’re invited to periodic planning and prioritisation sessions, you own the backlog as much as everyone else in the room. Developers aren’t there to just be technical consultants on the projected time to complete a given feature. You’re there to contribute to what gets priority over something else.

This is all abstract and fluffy, I know, so here’s an example from my own life.

In the third quarter of 2015, my squad was charged with implementing a new feature on our mobile apps. As an organisation, we’d tried it once before, in 2010 or 2011, and it was an embarrassing failure, so I suspect that, throughout the business, people were a little shy about trying it again. But we had some new technology in place to support this feature, and we thought we could achieve it in a couple of months, by standing on the shoulders of giants, so to speak.

At the same time, we’ve been trying to commit to dual-track agile, so we’d set an aggressive schedule of in-house user testing sessions with the Android app, to validate our workflows and UI. This user testing is fairly expensive, especially if you miss a date, so we agreed upon certain milestones for each round of testing.

In order to make these milestones, we had to make a number of compromises internally. Lots of stuff where we said, “well, it doesn’t need to be complete for the test, but we need something in this UI element, so we’ll hardcode this thing, and fix it after the test.” The only problem—and you can probably see this coming already—is that we didn’t fix those things promptly after the user test. We continued plowing through new features to make the next test. Like I said, it was an aggressive schedule.

Cut to a month or so later, when those hardcoded elements start causing bugs in the interface. I probably spent a week and a half correcting and compensating for things we considered “acceptable” for the user tests, that if I’d either implemented properly in the first place, or immediately corrected it after that test, would have taken a day. This was obviously really frustrating, and I mentioned that frustration in my end-of-year review. I complained that because we were so focussed on the milestones, at launch, it wasn't properly monitored, and it delayed other work, and said I was disappointed with having to release something retroactively dubbed a “public beta”.

When my manager and I reviewed the year, both his comments and mine, he had one simple question for me that stopped me in my tracks: why didn’t you say something right then? And I didn’t have an answer for him. Because I didn’t say anything at the time it came up. I didn’t open tickets for the defects. I may have mentioned the concessions made, in passing, during standups, and counted on my project manager and product owner to open the tickets.

So why didn’t I say something? Because I was acting like someone else owned the backlog, and my job is just to take work off it. This isn’t true. I could have saved myself, and everyone else, a lot of trouble, by recognising that I own the backlog as much as anybody else. If bugs are languishing in the backlog, then it’s your responsibility, as a member of the team, to bring that up during planning sessions. Your manager will appreciate your taking the lead on reducing technical debt and advocating for improving your code base.

On emotional labour

My awesome wife who's awesome wrote an amazing tweetstorm earlier tonight about the unpaid emotional labour women are socialised to do, and it’s made me pensive about a few things.

First up: I am absolutely guilty of a lot of these things. I hope less so recently than I used to be, but I have enough self-awareness to admit that yes, I have said and done these things. (She promises me it wasn’t directed at me, but that doesn’t mean I’m innocent—and I think I know her well enough to know she’d never subtweet the Hell out of me like that—but I think even that is part of the truckload of unpaid emotional labour that she, as a woman, has been brought up to do) And to be quite honest, if you’re a guy… you’ve done these things too. If you look at me and think to yourself, “well, I don’t think I’m like this,” you almost certainly are like that. Only if you can specifically identify things you do that are not like that… you’re like that.

Because, honestly, guys are socialised to do exactly that. And you even see a lot of it in what jobs in tech are coded as being “inherently” oriented toward men or women. QA and project management, which are both roles that require diligence, attention to minute detail, and an aptitude for predicting someone’s needs before they are aware of it, are coded as and performed by women much more than most other roles in the tech industry. Of tech roles within a tech company, they’re the only positions that I’ve consistently observed having anything close to gender-wise parity.

So why do I think that guys are socialised not to do this work? Because, let’s be honest, it is work. I had an opportunity to fill in for my team’s project manager (who, it’s important to point out, is a woman) late last year, and holy mother of God that job is hard. Like, Nintendo-hard. And at least she’s getting paid for it, but I guarantee she’s been doing this her whole life, because that’s what society’s taught her to do. And I haven’t. Instead, I’ve grown up around a lot of media that’s suggested that one set of gifts (chocolate, teddy bears, and diamonds) will satisfy any woman I may be involved with (here’s a hint: that’s a load of crap), and an escalating and never-ending series of ostensible jokes along the lines of “bitches be cray” when her birthday, or anniversary is forgotten.

And why the hell shouldn’t they be? Seriously, think about it for a minute. The person who you’ve decided to open up to and be most vulnerable with comes home on your birthday, or on the anniversary of the day you got married, and they have no idea what’s happened today, however long ago. They can’t bring it to mind at all.

Wouldn’t you be upset? I would be. I have been.

Long story short, just like math and art, the everyday things that women “just seem to do better than men” are things that they’ve practised, constantly, since they were very young. (Men have, conversely, been raised to ignore those things.) Anything you do every day of your life, for about as long as you can remember… yeah, you’re going to be pretty damn good at. Doesn’t make it easy, just habit. (Professional athletes are a great example of this) If you really want to show some kind of appreciation for the women in your life, and all the things they do for you… do them yourself.

Upgrade your models from PHP to Java

I’ve recently had an opportunity to work with my team’s new developer, as part of the ongoing campaign to bring him over to core Java development from our soon-to-be end-of-lifed PHP tools. Since I was once in his position, only two years ago—in fact, he inherited the PHP tools from me when I was forcefully reassigned to the Java team—I feel a certain affinity toward him, and a desire to see him succeed.

Like me, he also has some limited Java experience, but nothing at the enterprise scale I now work with every day, and nothing especially recent. So, I gave him a copy of the same Java certification handbook I used to prepare for my OCA Java 7 exam, as well as any other resources I could track down that seemed to be potentially helpful. This sprint he’s physically, and semi-officially, joined our team, working on the replacement for the product he’s been maintaining since he was hired.

And just to make the learning curve a little bit steeper, this tool uses JavaServer Faces. If you’ve developed for JSF before, you’re familiar with how much of a thorough pain in the ass it can be. Apparently we’re trying to weed out the non-hackers, Gunnery Sergeant Hartman style.

So, as part of his team onboarding process, we picked up a task to begin migrating data from the old tool to the new. On investigating the requirements, and the destination data model, we discovered that one of the elements that this task expects has not yet been implemented. What a great opportunity! Not only is he essentially new to Java, he’s also new to test-driven development, so I gave him a quick walkthrough the test process while we tried to write a test for the new features we needed to implement.

As a quick sidebar, in trying to write the tests, we quickly discovered that we were planning on modifying (or at least starting with) the wrong layer. If we’d just started writing code, it probably would have taken half an hour or more to discover this. By trying to write the test first, we figured this out within ten minutes, because the integration points rapidly made no sense for what we were trying to do. Hurray!

Anyway, lunch time promptly rolled around while I was writing up the test. I’d suggested we play “TDD ping-pong”—I write a test, then he implements it, and the test was mostly set up. I said I’d finish up the test on the new service we needed, and stub out the data-access object and the backing entity so he’d at least have methods to work with. After I sent it his way, I checked in after about an hour, to see how he was doing, and he mentioned something that hadn’t occurred to me, because I had become so used to Java: he was completely unfamiliar with enterprise Java’s usual architecture of service, DAO and DTO.

And of course, why would he be? I’m not aware of any PHP frameworks that use this architecture, because it’s based on an availability of dependency injection, compiled code and persistent classes that is pretty much anathema to the entire request lifecycle of PHP. For every request, PHP loads, compiles, and executes each class anew. So pre-loading your business model with the CRUD utility methods, and operating on them as semi-proper Objects that can persist themselves to your stable storage, is practically a necessity. Fat model, skinny controller, indeed.

Java has a huge advantage here, because the service, DAO, and whole persistence layer, never leave memory between requests, just request-specific context. Classes don’t get reloaded until the servlet container gets restarted (unless you’re using JSF, in which case, they’re serialised onto disk and rehydrated when you restart, for… some reason). So you can write your code where your controller asks a service for records, and the service calls out to the DAO, which return an entity (or collection thereof), or a single field’s value for a given identifier.

This is actually a really good thing to do, from an engineering perspective.

For a long time, with Project Alchemy, I was trying to write a persistence architecture that would be as storage-agnostic as possible—objects could be persisted to database, to disk, or into shared memory, and the object itself didn’t need to care where it went. I only ever got as far as implementing it for database (and even then, specifically for MySQL), but it was a pretty valiant effort, and one that I’d still like to return to, when I get the opportunity, if for no other reason than to say I finished it. But the entity’s superclass still had the save() and find() methods that meant that persistence logic was, at some level in the class inheritance hierarchy, part of the entity. While effective for PHP, in terms of performance, this unfortunately doesn’t result in the cleanest of all possible code.

Using a service layer provides separation of concerns that the typical PHP model doesn’t allow for. The entity that moves data out of stable storage and into a bean also contains both business logic and an awareness of how it’s stored. It really doesn’t have to, and should. Talking to the database shouldn’t be your entity’s problem.

But it’s still, overall, part of the business model. The service and the entity, combined, provide the business model, and the DAO just packs it away and gets it back for you when you need it. This two classes should be viewed as part of a whole business model, within the context of a “Model-View-Controller” framework. The controller needs to be aware of both classes, certainly, but they should form two parts of a whole.

Besides, if you can pull all your persistence logic out of your entity, it should be almost trivial to change storage engines if and when the time comes. Say you needed to move from JPA and Hibernate to an XML- or JSON-based document storage system. You could probably just get away with re-annotating your entity, and writing a new DAO (which should always be pretty minimal), then adjusting how your DAO is wired into your service.

Try doing that in PHP if your entity knows how it’s stored!

One of these days, I’ll have to lay out a guide for how this architecture works best. I’d love to get involved in teaching undergrad students how large organisations try to conduct software engineering, so if I can explain it visually, then so much the better!

How you speak reflects how you think

My good friend Audra pointed me to this list of “20 programming jargons” that is just full of awfulness. First of all—and this is the easy, facile complaint—I’ve never heard any of these terms (at least, with these definitions) used in the wild. Maybe it’s because I’ve generally worked for reasonably grown-up companies where we attempted to act like professionals, but who can say? I don’t quite know why these terms are so foreign to me, but some of them are just bad.

First, the good… or, at least, neutral:

Baklava/Lasagne Code

Okay, this one’s actually kind of good. Lasagne code evokes a particular variety of spaghetti code that got that way by adhering a little too closely to old “enterprise” techniques of organising class responsibilities, and by applying code patterns for the sake of applying code patterns. I’m hesitant to use baklava to describe this phenomenon because (a) baklava’s delicious, (b) there’s too good of a parallel to spaghetti code with lasagne, and (c) it feels like it’s making fun of Muslims, and I just don’t go in for that.

Banana Banana Banana

I’ve never heard of this, that I can recall. As an actor, I’m definitely familiar with rhubarb rhubarb rhubarb, the chorus equivalent of making it look like you’re having a conversation onstage without actually saying anything particularly coherent, that would pull focus.

Claustrocodeia

Can’t say I’m familiar with this term. Granted, I don’t like moving away from my nice 24” screen at the office, and working on my laptop screen, but it’s not like it’s anything more than a minor inconvenience. Get over it. Or buy yourself a big screen and expense it.

Stringly Typed

Again, this one’s pretty good. I’ve seen code like this, and it’s always much more of a headache than it could possibly be worth.

There’s Already A Word For This

Bugfoot

Over here, where the professionals work, we call this an “intermittent bug”. Could be environmental, could be infrastructure, could be code. But while we can’t replicate it, we don’t want to dismiss it out-of-hand, because this also means we can’t gauge its impact on the end user.

Jenga Code

Also known as “tightly coupled”. If you don’t already know this, or for some reason refuse to use this industry standard terminology, I frankly worry for the quality of your code.

Shrug Report

The bug report with insufficient detail. This is just a bad bug report, and should get sent back to the reporter for more details.

Unicorny

Otherwise known as “the business’s problem”. Unless you’re being called in to provide swag work estimates. I’ve also heard this as a “future project”.

Your Professionalism Is Showing

Counterbug

Code review isn’t supposed to be an adversarial process. When another programmer is reviewing your code, this is supposed to be about everyone’s professional development. Your reviewer may learn techniques they weren’t previously familiar with, and will gain exposure to more areas of the codebase, and that’s always a good thing. And by the same token, you’ll have the opportunity to learn techniques you weren’t previously familiar with, because your reviewed may be able to suggest a better (or even just different) way of solving the problem at hand. By saying, “yeah, well, you did this wrong”, you aren’t helping anyone (beyond exposing additional bugs to be fixed).

That said, getting used to code review as a collaborative process, and no longer hearing their comments as a personal attack, takes a conscious effort at first. But it’s effort that’s worth it. So when a reviewer points out an error, you should first bite your tongue, then think about what you can do better the next time around.

Duck

The business is not your enemy. Distracting their attention away from one particular area of the software is staggeringly unprofessional. It suggests that either you didn’t do your job properly there, or you think you know better what the business, or customer, wants. You might. You probably don’t; the business holds all the cards, and knows things they haven’t bothered to tell you, because they didn’t consider it germane to the feature request. If you have an issue with their ideas, the best thing to do is to take it up with them. In the event that they didn’t consider your alternative approach, then you might get them to reconsider their approach, and create an ultimately better product.

Refactoring

There’s a great maxim about how to write software: write code as though the next maintainer is an axe-wielding psychopath who knows where you live. Vivid, I know, and pretty violent, but I think it kind of gets the point across. Another, less aggressive version, describes the next maintainer as someone less capable than you with no context. If you’re writing code, or refactoring, and you don’t leave it in such a state that any developer could read it and know immediately what it does, you’re doing it wrong.

I know, I know; I’ve written before about self-documenting code being a lie. That doesn’t mean your code should be incomprehensible; it’s about not eschewing documenting your classes at a high level, simply because another developer need only read the code to understand it. Being a nice person to the next person is what self-documenting code is supposed to be about.

Smug Report

I’ll be the first to admit that I’m guilty of having this reaction to an external bug report that suggests that the reporter knows more about what’s going on than the developer. I’ll also cop to the reality that I’ve probably filed a few of these bug reports, as well. However, instead of going into adversarial mode, or trying to belittle the reporter, acknowledge something: you probably have a particularly technically competent reporter on your hands. If they’re outside your organisation, then you basically have someone who will do free testing for you! Make use of this reality, because you have someone on your level, who you probably wouldn’t have to work very hard to convince to do black-box testing. These reporters are gifts in human form.

Unfortunately, there are some that betray an awful interpersonal culture. Presented in no particular order, and certainly not the original order:

Being A Good Person: You’re Doing It Wrong

Jimmy

This, frankly, reads more like an in-joke at one particular organisation. Probably Jimmy was a wet-behind-the-ears recent graduate who managed to get past the interview, only to flail wildly until he was put out of the rest of the team’s misery. It happens sometimes. It’s unfortunate for Jimmy that no one on his team was willing to mentor him into a good programmer, but if the rest of the list was written at the same company, there probably weren’t many qualified candidates.

Not to say that professionals don’t turn colleagues’ names into in-jokes. Never mind that at the foosball table, I can think of at least four developers whose names are used to describe particular moves, one of our developers was, due to a fluke of seating assignments, regularly forgotten to be pulled into impromptu meetings. He’s now a verb, used when something (or, more typically, someone) is carelessly forgotten. However, this is done (a) in jest, and (b) is aimed squarely at the forgetter, not the forgettee. Poor guy just got it named after him after we did it so often that we started using his name as a shorthand for “we forgot him!’

So why is it unfair to call the clueless newbie a Jimmy? Because it pokes fun at the clueless newbie for being just that. Instead of mocking the new kid, they should be welcomed with open arms and guided into being a better developer.

Chug/Drug Report

Yes, suggest that the bug reporter was, at best, in an altered mental state when they wrote the report. This seems fair. Or, you could be working with a language barrier. Perhaps two, depending on when you, as the reader of the bug report, learned the language it’s written in. Assume that the reporter did their best to convey what they encountered, and give them the benefit of the doubt.

Mad Girlfriend Bug

First of all, this kind of bug is pretty much any bug that isn’t completely straightforward. Second of all, this is an idiotic gender stereotype. If you aren’t willing to try to communicate with your signficant other when you’re having an argument, your miserable relationship is your own problem. Finally, reinforcing idiotic gender stereotypes in the workplace is just one of the reasons that the gender balance both in the workforce and in school is so completely out to lunch. It’s one of the reasons that twice as many women as men exit programming as a profession. It creates a hostile work environment for your peers. Don’t do this.

Barack Obama

This one feels vaguely racist, and the fact that it’s the editors’s favourite, of everything on the list, gives a certain amount of credence to my worry in this regard. I want this to be a joke about Healthcare.gov, or about how a lot of liberal people had a lot of hope which has been repeatedly dashed, but the bit about “which would not otherwise get approval” bears a pretty strong suggestion that African Americans only voted for Obama because of the colour of his skin… and that just a reference of questionable future usefulness into a racist joke.

Ghetto Code

While I was simply wondering if the Obama project account was racist, this one pretty obviously is. Inelegant code is just that. Inelegant, perhaps sloppy. Tightly coupled. Not cohesive. Spaghetti code. With so many descriptors for code that isn’t elegant available… why on Earth would you go for the one that takes advantage of a marginalised group of people? Other than the obvious explanation that you almost certainly grew up in a life of privilege, with no idea of what it’s like to live in a ghetto. Bear in mind that the word ghetto was first used to refer to the quarters of the European cities where Jews were effectively obligated to live, because the Christians in power viewed the Jews as something less than themselves. Ghettos are areas of both crippling poverty and, at least once (if not still), systematic oppression. Your inelegant code is not described by this. Just stop using this word entirely.

As a profession, we get a lot of flak for how we treat people who don’t look like us… and I can’t say it isn’t well-earned. By adopting, using, and promoting language like this, all we’re doing is saying that we think it’s okay to do exactly that. It isn’t. So other than the two phrases up at the top… this stuff all has to go. The writers and editors at EFY Times who wrote and approved this list should give some serious consideration to what they’re really saying when they publish lists like this.

E3, or, Seventy-two hours of misogyny

After lunch most days, before returning to work, I typically take a few minutes’ break to catch up with Reddit and Twitter, to see if any of my friends have said anything funny or interesting today, or maybe there’s an programming-related article I can share with my colleagues. However, today, my Twitter feed had this waiting for me, courtesy of a retweet from @lindsaybieda:

Holy shit. Female 343 games producer walks on the Microsoft stage and a man *seriously* wolf whistled at her. Fuck you.

— brandon sheffield (@necrosofty) June 10, 2013

My immediate reaction was not unlike Gollum’s, when Sméagol tells him in the film of The Two Towers, “Master looks after us now. We don’t need you any more.”… what?

Now, I knew going into this that E3 is a ridiculous three-day-long display of sexism, objectification, and misogyny (oh, and something about video games, too). Last year, Scott R Kurtz had a character deliver a webcast from “either E3, or the world’s largest Hooters.” I have privately, among my friends, and probably publicly, too, lamented every marketing department’s decision to hire booth babes for a conference—to use women as little more than decoration and furniture— and I’ve written before about the technology industry’s rampant misogyny. It's not as though I didn’t at least somewhat expect the result of what I did next.

I ran a Twitter search for “#E3 Bonnie Ross”—just that—and was promptly given a feed full of complaints about the new Halo, pleas for 343 Industries not to mess it up… and a litany of tweets about Bonnie Ross: how good she looks, how inept she (apparently) was as a presenter, and multiple people explaining in sometimes graphic details that they want to have sex with her. In particular, @Boogie2988’s gem (since, it seems, deleted):

£429 do we get a complimentary blow job off Bonnie Ross with that?"

— Boogie2988 (@Boogie2988) June 10, 2013

I can’t believe that I have to ask this, but where the fuck do these guys get off, thinking that this shit is okay to suggest, let alone think?! Bonnie Ross is not the studio head of 343 Industries for you to cat-call, or to ask for sexual favours from. She is there to do a job, and judging by the Halo sales, she seems to be doing a pretty good one at that. If you think she’s a dull presenter, fine (during the BB10 launch, I described BlackBerry CEO Thorsten Hiens as having “all the personality of a wet dishrag”), but for God’s sake, can a woman, for once, show up at E3 and be treated with some basic human respect? Is that so hard, guys? Maybe, you know, not call her a MILF. Perhaps not suggest that “that bitch had to have skipped speech class.”

I went on a bit of a tear on Twitter, quote-tweeting and retweeting some of the more egregious offenders, because you know what? I am sick to death of the way that men in my industry talk about women, whether they’re presenting for their favourite console, or the speaker’s colleagues and peers. I would really like to think that, in this day and age, we were raised better than that, but, clearly, this isn’t the case:

@mgpcoe do you want to fight?

— goodsmell (@G__REX) June 10, 2013

@mgpcoe Oh sorry, didn’t realize I was being monitored. That FEMALE must have skipped speech class.

— sinrin. (@SannyRanny) June 10, 2013

@sannyranny @mgpcoe mgpcoe is the definition of a floppy wet turd. #E3 #goofball #letscaremorethanweshould

— Lawrence Fidelis (@HeyFiddy777) June 10, 2013

@mgpcoe It’s my opinion and I will freely state it anywhere I want. Your judgement means shit

— Vel (@God_Damn_Vel) June 10, 2013

I’m a little proud of eliciting “let’s care more than we should” as a hashtag; it really demonstrates the work that still needs to be done. And I have to say, I haven’t been challenged to a fight since Grade 9, so well done over there, too. However, one of the guys I quote-tweeted (the one who made the crack about speech class) got back to me and we had this conversation. It’s too long to embed without messing around with Storify, but I broke it down for this guy that, basically, what you say on Twitter is open for public critique (and I was just criticising his statement, not his character) but his closing statement, “I was in a casual context, speaking with kids just out of high school who couldn’t care less about semantics,” really reminded me, despite all the fucked-up things that have happened this year, that kids today still need to be taught this.

I’m sure he and his friends couldn’t care less about the semantics of what they’re saying, but the reality of the situation is that we need them to. Just as we, as adults and parents and nurturers and teachers, need to teach them to care. We need to carefully teach the younger generations about respect, and about the hidden messages they may not realise they’re delivering when they use certain words. We need to not only self-correct, and demonstrate the right behaviour; we need to call out the wrong behaviour in others. They may not realise what they’re doing, but that doesn’t mean they shouldn’t be taken to task for it. After all, not knowing that, in this particular jurisdiction, you can’t turn right on a red light doesn’t mean the traffic police are going to let you off the hook.

To make this abundantly clear, if you were one of the guys who decided to judge Bonnie Ross’ ability or competence based on her appearance or gender, or you made—or laughed at—jokes about her, using language specifically reserved for insulting women, you are part of the problem. You are holding back the human race from evolving beyond prejudice, beyond hatred, and beyond unwarranted fear. And I refuse to stand idly by and watch you do it.

On monitors and error detection

Earlier today, a colleague and I were discussing monitoring tools for Web services. He recently joined our team as a systems administrator, and I was filling him in on a homebrew monitoring service I put together a couple of years ago, to cover a gap in our existing monitor’s configuration, done in the spirit of Big Brother. He had praise for its elegance, and we joked a bit about reusing it outside the company, the fact that it would need to be completely rebuilt in that case (since, though it wasn’t composed of original ideas, just a merger of Big Brother and Cacti, it remains the intellectual property of $EMPLOYER$), and whether or not I would even need such a service for Prophecy.

After thinking about it briefly, I realized that not only will Project Seshat deserve some kind of monitoring once I install it on my server—I guess I’ll just add that to the pile of TODOs—but I remembered that I have a WordPress instance running for the Cu Nim Gliding Club, in Okotoks, Alberta. Surely a production install of WordPress deserves monitoring, in order to make sure that Cu Nim's visitors can access the site.

So, while waiting at a restaurant for my wife and our dinner guests to arrive, I took to The Internet to look for any existing solutions for monitoring WordPress with, say, Nagios. I may not be familiar with many monitors, but I know enough about Nagios to know that it works well with heartbeats—URIs that indicate the health of a particular aspect of a service.

The first hit I found that wasn’t a plugin for one of the two was a blog entry describing how to manually set up a few monitors for a local WordPress instance. It explained how to configu Nagios to run a few basic service checks: that the host in question can serve HTTP, that it can access the MySQL server, and that WordPress is configured, a single check on the homepage.

To me, this seems woefully incomplete. A single check to see that anything is returned by WordPress, even if you are separately checking on Apache and MySQL, strikes me as being little more than an “allswell” test. Certainly, success of this test can be reasonably inferred to indicate good health of the system, but failure of this test could mean any number of things, which would need to be investigated to determine what has gone wrong, and the priority of the fix.

When I use a monitoring system, I want it to be able to tell me exactly what went wrong, to the best of its ability. I want it to be able to tell me when things are behaving out of the ordinary. I want it to tell me that, even though the page loaded, it took longer than some threshold that I've set (which would probably warrant a different level of concern and urgency than the page not loading at all, which would be the case with a single request having a short timeout). In short, I want more than just the night watch to call out, “twelve o’clock and all’s well!”.

The options that I could take to accomplish this goal are myriad. First of all, yes, I want something in place to monitor the WordPress instance. But for original products, like Project Seshat, I would definitely like something not just more robust, but also more automatic. Project Alchemy is intended to create an audit trail for all edits without having to specifically issue calls to auditing methods in the controllers. I’d love to take a page from JavaMelody and create an aspect-oriented monitoring solution that can report request timing, method timing, errors per request, and perhaps even send out notifications the first time an error of a particular severity occurs, instead of the way Big Brother does it, where it polls regularly to gather data.

Don’t get me wrong, it’s probably a huge undertaking. I don’t expect to launch Project Seshat with such a system in place (as much as I’d love to). But it’s certainly food for thought for what to work on next. And when Seshat does launch, I will want to have a few basic checks to make sure that it hasn’t completely fallen over. After all, so far, I’ve been adhering to the principle of “make it work, then make it pretty.” May as well keep it up.