On failure

By Serdar Yegulalp | 2015/09/28 21:56


[Before you wonder, no, this isn't about me deciding to throw in the towel with MeTal. This is a meditation in a different vein.]

There is a crack in everything
That's how the light gets in.
-- Leonard Cohen, "Anthem"

It's good for things to break.

For those who don't write software, this is counterintuitive. Users need things not to break. Software that throws cryptic exceptions is useless to them; they need to get work done, not file bug reports and pray to the gods of the digital wild blue yonder that whatever they were working on had a draft saved before the bomb went off.

But developers need things to break. They need them to break because it's better that they break on their own time than on the user's.

I run my own software both as a user and as a developer. I have to keep two hats on the rack next to me, and swap them as need dictates. Sometimes this is jarring: I'll be in the middle of using the application as a user, and wham! I'll hit something that forces me to be a developer again for two hours.

It's jarring and unpleasant, but it keep me honest. It means I have to be that much more forward-thinking when I write my code. That said, at some point you are always going to end up smoking out bugs you had no way to plan for. if my users are likely to encounter those things because they attempt to do things I didn't anticipate, the I owe it to myself to be as much like them as possible when I use the program. I owe it to myself to break things. I owe it to myself to not play nice with my software because users aren't supposed to do that, and they'd know it if they bothered to read the (so far non-existent) documentation.

A lot of the time, it isn't so much that things break as they are irritants. I have the sneaking suspicion, for instance, that when I start using the image upload feature more often, I'll get really frustrated with the fact that I made the image drop target so small. If something bugs me as a user, there's a good chance it's going to really bug a regular user, because he isn't going to be in a position to change anything. It's up to me to make sure my pain doesn't become his pain.

This isn't something that comes naturally. It's hard to wear two hats, even interchangeably. It's tempting to think that if you explain to someone else why something is a certain way, they'll nod gamely and go back to working around your assumptions about things. Nowhere, except in the wildest dreams of a software developer who spends too much time behind his keyboard, is this ever the case. Frustrated users become ex-users, and a project with no users is a project with no testers, no sounding board, no real-world evangelists.

A big part of why I started building MeTal was because the developers -- well, more the marketers than the developers -- of the product I'd used before had decided to focus their attention on the needs of their paying customers. This was not an illogical decision, but it was a frustrating one. It meant that my good decade-and-change investment in the product was coming to naught. It didn't matter that their snub wasn't personal; it sure felt personal. For most people, even people who knew better like me, that was all that mattered. I didn't want to recapitulate that mistake if I could help it.

That meant having to retrain myself to not let my instincts as a developer override my instincts as a user. I had to be able to let the crack that formed in my work be allowed to let the light in.

Finally, many of the most severe testing issues would be made easier with a test suite. I know. MeTal currently has no test suite, and that's entirely my fault. I wasn't in the habit of writing a test suite with an application when I started creating MeTal.

But that's not an irreparable mistake; it's just one of those things that means I have old habits that need breaking. It can be fixed in time, and it will be. (I suspect I will have to pattern the test suite after the sort written for other Web-based projects built in Python; that would be the most logical place to begin, wouldn't it?) The light will get in, one way or another.

[Postscript: Right after I made this post live, I attempted to tweak the formatting of the blog-page template and immediately ran into a fresh new bug involving the way templates are previewed. Well, that's what eating your own dogfood is all about, right? On the plus side, the edit/preview/post/update cycle works great so far...]


Tags: programming


comments powered by Disqus