Coding Like a Cowboy

If you feel like coding like a cowboy, go ahead...but keep in mind, you need to do it properly.

One of my friends (Darell K.) from Erie, PA always told me that when he received requirements for a project, he would always start coding immediately. I asked him why he would always do this. You would need to code a prototype and then review the code, ask questions, then start building the code properly. I firmly agreed with his approach, but our supervisor at the time didn't (Sorry Fran). :-)

The idea that was explained to me was to find any gotchas in the feature/enhancement requested.

I've found out another hidden benefit of this. If you go to a meeting and discuss this feature/enhancement and you have a good part of it coded, you may notice that you have a firm grasp on what they want in the feature. If you do, then you may even be able to recommended suggestions on how to improve the feature set, making your software better than projected.

Well, that advice has followed me throughout my career and I thank my friend from Erie for that. Now, my coding idol, Nick Bradbury, has just confirmed what I believe in a post: Start Coding Like a Cowboy.

As he says in his post:

[So] the goal here isn't to complete a feature quickly (although that's often a side effect), but instead to discover the gotchas up-front so you can design the feature correctly.

 Wow, deja vu. This advice given to me back in 1995 has caught up with me today in a post.

As a Rubes cartoon once stated, "Technology changes, people don't."

(BTW, if anybody has seen this cartoon, please let me know, I'm trying to track it down).