The Best Programmers Eat Their Applications
September 27th, 2007 : David CarnesI have a theory.
A web application will be at least 100% better if the developers who create it also actively use it.
It is akin to a meal prepared by an expert chef. The best chefs constantly sample their creations as they prepare a meal. When it is ready, they’ll serve it to their patrons and then sit down themselves to enjoy what they have lovingly created.
Like a chef, expert developers need to actively sample (test and use) their software while working on it, then sit down and consume their own code as a user would.
QA provided by testing experts definitely has its place - but I fear that sometimes developers (even good ones) miss significant opportunities to write better applications because they rely too heavily on testers / users to catch bugs and provide interface feedback. This reliance costs time - but even more significantly, we lose opportunities to improve the user experience because those who know how to change the code don’t take the time to actively engage and use the application. This lost opportunity for creative improvement could be avoided if developers spent an hour actively using the application for every 10 hours spent coding.
When I say using - I don’t mean quick tests, scripted testing, a little demo or anything like that - I mean actively using the application like their users will have to. I’m talking really, really use it and engage. A good chef will sit down and eat the meals he prepares - from that he draws inspiration for improvement. Programmers who consume the applications they write will create better software - hands down.
Tags:ArcStone nerds Object Oriented Programming productivity
September 28th, 2007 at 4:52 pm
I feel like this post might be about me–know this–that after the document indexing feature hit, I’m actively using Wonderfile. In principle, I agree with you, but some applications (no examples needed) just don’t lend themselves to use by developers. Wonderfile isn’t one of those apps, it’s very useful for me now. You know that us coder types think about apps differently, we have more tolerance for odd behavior if it buys us some efficiency. Still, for the most part, you’re right. If nothing else, we’ll appreciate our own work more if we benefit from it.
October 1st, 2007 at 1:43 pm
we have more tolerance for odd behavior if it buys us some efficiency
I would suggest developers tolerate odd behavior because it often functionally works. Not that it works in the mental model most people might have, but it works in our little fiefdom.
Software is much, much better than it used to be. It still has a hella way to go though.
October 1st, 2007 at 3:56 pm
It’s a challenge to balance getting an app done within budget while spending the time required to reach a level of craftsmanship that makes the end-user experience painless and intuitive.
Programmers have to balance those two demands… how to code within budget while not requiring odd user behavior. It also demands a clearly communicated feature set from the client and an adequate budget to get the job done right.
Contrary to Austin’s comments - the post wasn’t directed at him - it’s just been a rant I’ve been on the last week or so.
There should be a formal, thorough, first pass test by the programmer tasked as the lead for a project, before the application is sent to QA.
October 2nd, 2007 at 6:10 pm
I disagree with this.
Yes, programmers should be familiar with the apps they work on; yes, they should test them for usability while they’re working on them, and yes, they should absolutely ensure that the use experience is where it’s supposed to be.
However, what you’re talking about isn’t so much testing for functionality as it is evaluating usability: Programmers should not be expected to review design decisions during development any more than designers (on whose shoulders this responsibility does fall) should be expected to go over the final back-end code and suggest changes from an efficiency standpoint.
I think the solution to this problem is a good spec and a solid, -comprehensive-, well-reviewed, accepted design — all of which are things that should be present before any back-end code is written.
A painter shouldn’t have to worry about redesigning his easel while he’s working on his canvas, and you don’t ask a construction foreman to rethink the blueprints he’s given. There’s a separation of responsibility there that applies here as well: Designers are there to lay the groundwork for the application. Asking the artist to work on his easel will distract him and sap his creativity; asking the foreman to improve his skyscraper’s feng shui will result in delays at best and disasters at worst.
Again… I’m not saying programmers shouldn’t use their apps. I’m just saying that the improvement you get in the final product, if any, probably will not be significant, and your cost to benefit will almost certainly make you wonder what went wrong.
Separation of church and state, baby!