I recently read a good article titled “The Dark Side of Craftsmanship“. In the article Ted Neward tells a story about a well-meaning developer who posts some sloppy code to a public forum and is criticized harshly. Mr. Neward correctly points-out that the criticism was over-the-top and downright rude and un-classy. You had to feel bad for the victim because she was trying to be nice and participate in a public forum. The criticism was not constructive or helpful. Mr. Neward continued by pointing-out that not everybody needs to be a ninja and it is okay to be a code slinger because the world needs some of them too.
I must confess that I wholeheartedly agreed with his article until I started thinking about the other end of the spectrum. Then I wholeheartedly disagreed at the same time. Oh, such inner conflict! I nearly became emotional.
The point Mr. Neward was trying to make is that some people get carried away with elitism and forget their original purpose. Bottom line: programmers just produce programs that provide a service to people and you don’t need to be a fancy-pants to accomplish that goal. Elitists sometimes get caught up in their own glory and tend to look down on others who are not on a quest for self-perfection.
To that end, I say bravo. One of my favorite battle cries is: “First, get it done. Then make it better.” Overcomplicating any project is a mistake clothed in artificial brilliance. An over-complicated program will get rewritten every time (that is, if it is ever completed in the first place).
The only problem is that some people misuse this rationale as an excuse for carelessness and for delivering poor quality. I have been criticized that “First get it done. Then make it better.” Often gets truncated after the first sentence. People try to “first get it done” and then move-on and never make it better. They leave you with a stinking mess and say it was Tim’s idea. So be careful with that.
Every project that you do, should be written rapidly and reliably to meet the needs of the project with regard to usability and maintainability, without overdoing it. For example: If I am making a data-loading app that only needs to run once and never run again, then I really don’t need a fancy UI, or TDD, etc. I know it is a disposable program and it won’t be anything else. I provide the best value to my employer by keeping the cost down and the timeline short by getting it to work as soon as I can. However, if I am whipping up a quick prototype that I suspect is somehow going to get deployed as a production app and won’t be replaced for 5 years, then I really should feel obliged to put a little more quality behind it. This is even more critical if I suspect that somebody else may have to maintain any of it. The solution should fit the problem.
Bottom line: provide a good value to your employer. Find the balance between hack and perfectionist.