I mentioned in my blog yesterday that I did a lot of work on the house over the weekend. Last night, having been removed from the hard work for a day, I could actually appreciate the work that I’ve done. I was impressed with the improved quality of my woodworking skills. It’s not really all that difficult, but it isn’t always easy to have the patience to do things right when there’s so much to be done. Measurements have become more precise and those subtle finishing touch tricks are all the more valuable. The thing is, like anything, the more you do something, the more mistakes you make and correct, the more you learn, the better you’ll get. I’ve learned a lot from my mistakes and the mistakes of others, both professionally and in my hobbies, and I keep learning every day.
The most common mistake that I make these days is having to be in such a rush that the planning part of my projects don’t get completed before the project begins. Like my first woodworking project this weekend, it’s not that I can’t use the tools, it’s that I didn’t think about how I wanted to use them, and plan it out before I did so, costing me time and frustration later on when I realized that I cut out the wrong side of my piece. I had to then figure out a fix for it, but all of that could be saved, had I actually planned out my work instead of just trying to wing it. Programming is very similar to that. Now granted, if I cut a piece of wood, the wood is cut, and there’s no going back, but there is wood filler. It’s not as nice, but if you’re painting the wood, it may not show up at all. When we don’t plan out programming projects and our project is ‘by the seat of your pants’ or even just not planned out and approved before starting the actual building, similar mistakes are made.
Lets say we have a project where there’s some sort of patient data database. Usually when we get a request for a ‘database’ it’s about that vague. What we try to do is build out the database tables, the fields we need and all of the relational parts and get that approved. This way before we even begin the programming part of things, we have a solid approved foundation to start. Sometimes it’s not very easy for clients to picture how the database is going to actually be represented, and in that case, we go with a more visual approach and show all of the fields in a basic HTML format. This seems to work the best for most clients. When we don’t have this process completed prior to starting work, what we begin to see is the need for the 5 gallon bucket of wood filler. We create the database and references, work on the coldfusion programming to read and write data from the tables, build forms and selection lists, all revolving around this ‘guessed’ database table. Then the client comes back with a handful or more revisions, which then causes us more work than I care to think about. Adding or changing fields in the table, then going through and doing the same for all of the forms and action pages, making sure not to forget one place, because then it all falls apart. It can quickly change your 5 hour project into a 30 hour project. I have learned in my years of programming that there are fixes to make the patchwork go more quickly, but I have learned that to program with finesse, the project needs to be well planned out before any coding happens so you always know where you’re going, and those trim corners look sharp.