It's almost perfect.
That project you've been working on for months and months or maybe even years is almost into the test system.
You're running down your checklist of features, painstakingly assembled from a series of torn legal pads, post-it notes, and napkins. So far, everything is perfect.
Then, at 7:21 PM, you arrive back in the same old tired reality.
"I found another bug." Doh!
There are a number of problems with this scenario.
First, why have you been working on your project for months without putting something in your clients' hands?
There's a great book written by 37 Signals titled Getting Real. Getting real means having the right team: small and organized, with a developer, a designer, and a generalist to pull it all together. Getting real means staying focused: keeping the feature list small, and having a technical non-developer on-hand to establish completion.
But most importantly, getting real means getting real: drop the wireframes; forget about state diagrams; put fingers to keyboard and turn the idea into a product that can be used.
If you've never heard of or read the book yourself, check it out.
Second, if your checklist of features requires anything larger than a single piece of legal paper, then you have too many features planned, especially if you're only on your first release.
At Clutch I'm working on a piece of software that has exactly fifty business rules. Fifty rules is a lot of rules, but I've been doing this Web development stuff for a while. I'm seasoned. Plus, I've got people working with me: someone to do the straight-forward, fingers to the keyboard kind of work; and a crackshot designer to make it look good.
Feature creep begins innocently enough. "Instead of storing the shopping cart in the session, I'll start storing it in the database."
Before you know it, you're worrying about things like scalability, modularity or code reuse, and efficiency; and you're no longer getting real. Instead, you're tackling all those potential problems before honing any of those fifty business rules; and believe you me: those fifty business rules aren't going to go away: fifty business rules is a lot of rules.
Keep it lean, dude. Make it better later.
Third, why are you testing your own software?
Newbie mistake numero uno: you can't test your own business logic.
It made sense in your head. It made sense when you coded it. It makes sense everytime you push that little button, the application turns green, and you get a record in the database.
But when your client pushes that other button, your application turns red, and the database disappears. Suddenly, things stop making sense.
The only test you should do yourself is to push the play button on your unit testing code.
Unit testing code? As the name implies, unit testing code is code that tests other code in units or modules.
Say you have an application that allows its users to shop for widgets. The phrase "shop for widgets" implies all sorts of micro processes: loading records from the database, routing user requests, validating input, storing new records, sending e-mail, handling errors - the list goes on and on.
Each one of those micro processes is or is composed of units of work; and if you're coding the sane way, you're testing each one of those units independently of the whole.
It's much easier to detect a faulty feature in a data access object when the test doesn't involve the Web application interface - trust me.
These days, you can find a unit testing framework for any platform: JUnit for Java, SimpleTest for PHP, and NUnit on the .NET enterprise. I can't vouch for NUnit, but JUnit and SimpleTest are absolutely indispensible tools in my toolkit.
Once you're unit testing, you might as well start doing test-driven development. Test-driven development is development that is driven by tests.
First, you write some unit testing code that relies on a valid business process, e.g.,
public void testMaximum() {
assertEquals("The maximum of 4 and 2 is 4.", Math.max(2, 4), 4);
}
Then, you write the code that enacts the business process. You go back and run the test, and if the test passes, then you're free to move onto the business rule.
This formula for composing code puts the application's story ahead of the pages on which it's written. If you focus first on what the application is supposed to do, getting it there will feel more like winning the game than fighting an endless battle with yourself.
Fourth, why are you working at 7:21 PM?
Well, perhaps it's for the same reason that I'm writing this blog article at 10:49 PM: sometimes the creative juices just flow faster in the evening.
But if you're anything like me, you've also probably been at it since 8 AM; and even though you feel like the code is flowing easily, the reality is much more stark.
You're creating tomorrow's messes, today. Hooray for your stamina!
Always remember the rule of thirds: one-third of your life will be spent asleep (if you're lucky); one-third of your life will be spent at work; and the other third should be spent eating, doing things purely for fun (like sex), creating, or resting (sleeping some more, maybe?).
As developers who love to develop, we find it easy to be lulled into a sense of being creative through our work - that our work itself is part of that creating time belonging to the third-third of our lives.
Get real: work is work. And though it ain't like diggin' ditches, programming is hard on the body. Checked your posture lately? How do your eyes feel right now? Can you pinch an inch of fat around your midsection? That's what I thought. Believe me, I'm right there with you.
So the next time you look down and realize that you should have left work thirty minutes ago, try to remember the fifth thing that's wrong with our shared scenario.
Your code will never be perfect.
It is for this reason that Rands invented the Larry Test. Because Larry would never have been done, unless his test told him so.
As Rands explains, when left to his own devices, a developer's job is never done. We refine, recode, refactor, reevaluate, and recode some more, until we think we've achieved perfection.
But perfection never comes.
Perfection doesn't exist in our world any more than it does in the world outside the CPU. At a high level like JavaScript, everything is ones and zeros. With enough effort, you can probably herd all of those ones and zeros into a straight line, write a program to interpret them, and prevent cross-site scripting attacks along the way. Perfection seems achievable.
But were you aware that when you depress a button on an electronic device, there's a program somewhere, patiently and carefully waiting for the electrical switch to stop shaking wildly back and forth? Waiting patiently to take the final reading, and establish a one or a zero?
What happens if that one or zero never comes? It is, after all, nothing more than electricity. A stray magnet, and EMP of one variety or another, a lighting bolt. Any one of these will drive the voltage right of the charts, leaving that little program with nothing to measure and no way to recover from the failure.
Every single piece of code we write rests atop a stack of hardware: an inescapable electrical reality, confining our perfect programs to a dimension of physical randomness.
At the end of the day, fifty lines of code are probably just as efficient as five. It's only when your user base increases by an order of magnitude that the game becomes something different.
Consider how long its been since Twitter rolled out a new feature. Surely they have some good ideas on hand. But the developers at Twitter are busy doing one thing and one thing only: scaling their core feature set to 100,000 new users a month. Their idea of perfection is a Twitter than can stand the test of the 2008 elections, or the next Super Bowl, or a natural disaster of Katrina proportions.
So, the next time you embark on a new development project, remember these basics:
- Get real as soon as possible: make it your mission to create a physical manifestation of your ideas
- Keep the feature list small and allow your project to evolve iteratively
- Do not test your own software: start with code that expresses your business processes and work backward
- Go home at the end of the day: exercise, eat well, and invest your free time in another human being
- And for the love of peat, stop chasing perfection because it doesn't exist; and if you keep pursuing it, neither will you.
