Coding Before Designing
Weeks of coding can save hours of planning.
This is one in a series of articles on technical debt.
Tell me if this sounds familiar.
A client comes to you with a request for a new feature or project. You talk to the client to get a better understanding of their pain. As they're describing the issue, your brain is already working through the solution. By the end of the conversation you're already envisioning the final product.
You get to your computer, open up Access, and begin furiously creating forms and writing code while everything is still fresh in your head. The progress you make in those first few hours is amazing. Everything is coming together exactly as you imagined it. You don't want to stop working because you're making so much progress.
You come back the next day and pick up right where you left off. Progress continues apace. Your project is 25% complete. You're ahead of schedule! You keep going. The high of writing fresh code is invigorating. Your project is already over 50% complete. You can't figure out why it took you so long to do that last project. You're now 75% done. Aside from a few stumbles here and there, it's been smooth sailing.
And then the wheels come off.
You start working on those last few reports. The ones that the client mentioned in your first meeting. I mean, they must have mentioned them, because they're right there in your notes. Somehow, though, in all your unbridled excitement, you failed to really take those reports into account as you were busy assembling the finished product in your head that first day.
Now you're in what should be the home stretch and your stomach drops. You've had a horrible realization. Those two tables with the one-to-many relationship? Yeah, that's actually a many-to-many relationship. That means you need to change your database schema. And you don't even want to think about the ripple effects: all the queries you'll have to rewrite; that beautiful subform that doesn't even make sense any more; those reports that now have to be completely reformatted.
You walk away from your computer that night broken, a shell of your once-exhilarated self. You dread coming back to work the next day. Writing new code is fun! Refactoring existing code is not. Especially not when you just wrote it and you can't even mutter to yourself about the idiot whose mess you have to clean up. I mean, I suppose you can, but somehow it's less satisfying when you are the idiot.
You trudge through. You change the schema; 60% complete. You change the queries; 70% complete. You change the forms; 80% complete. You change the reports; 90% complete.
You're almost done. It's time to show the client what you've got.
"Looks good," she says. "Where's the button to inactivate a vendor?" she asks innocently.
Your stomach drops again. "We still need to add that," you say confidently. "Let me know if you see anything else we need to tweak."
Tweak! Ha, you actually use the word "tweak." You use that word even when you know the 'vendor inactivation feature' is an iceberg and the [Inactivate Vendor] button is just the part the client can see.
You know this "tweak" will take days to put in place. There will be another schema change to add an IsActive field to the Vendor table. You'll have to update every query to include only active vendors. Add filtering to allow the user to show only active vendors...or inactive vendors...or all vendors. On every form. And every report.
It looks like this project will be late after all.
At least now you've finally learned your lesson. And when the next project comes along, you'll know exactly what to do:
- Listen to your client begin to describe their pain
- Immediately begin thinking about how you can solve all the simplest bits
- Imagine the perfect, fully-realized solution all in your head
- Write all the code
- As fast as you possibly can
- Before your brain forgets anything
But whatever you do...DON'T WASTE ANY TIME PLANNING!
