As an IT professional I hear a lot of things that make me cringe. Yesterday I heard an old school mantra. "Our code is pretty bad because we didn't have time to clean it up." I can't count the times I've heard this same statement uttered, either exactly or in spirit.
It blows my mind that in the age of agile development that people are still cowboy coding. The days of mindless hacking must end; IT needs to mature into a formal scientific discipline. Would you ever hear an architect say, well I was just experimenting, I meant to get the foundation complete but I wanted to make sure the roof worked first. While the physical examples of architecture can go a long way to describe a software developer's work the metaphor can become strained, but the point is valid. When building code you must always be cognizant of what, how and why of your problem domain: What are you building, how are you building it, why are you building it. If you keep all three of these questions in mind your development won't slip into cowboy coding. Better yet, practice TDD and you won't have to keep these principles in memory.
Test Driven Development guides you through th big three questions about any code you write. You write the test to meet the user's story and then the code almost writes itself. For example, if you have a user story that a user wants a way to figure out what day of the week they were born (I know its pretty contrived). You first write a test that guarantees that if someone were to be born today that whatever calculation you use in your code will return the correct day of the week. Then come up with a few random test cases, your own birthday, the current President's birthday, your spouses birthday or whatever. Finally, come up with some edge cases, what happens if someone were born on Feb 29, 2004, what about someone born before the Gregorian Calendar took affect. Then if you write code to pass these test you will of answered all three vitals; what are you writing: a solution for determining the day of the week for a given date, why are you writing it: to meet the user's requirement for a date tool, how are you going to build it: take in a date spit out the day of the week.
Another step in becoming more than a coding monkey is desire. As a developer do you sometimes find yourself falling back on what you know, on what is easy. That lethargy will never evolved your simian tendencies. A monkey has it easy they don't have to worry about lay-offs or that their knowledge going stale; but we developers have to constantly be worried about these real threats to our career survival. Developers are knowledge workers and our one and only commodity is our knowledge so why would you allow it to rot? Every line of code you write you should be pushing yourself to do it better (clearer, more concise) than you did on the last line of code. Refactoring is great for fixing smelly code, but what we need to have is a desire to prefactor: fixing smelly code before its written. The best developers I know never say, it isnt' as good as I could do but its good enough; instead I hear them say, I did the best I could but I know I can do better. The best developers have a desire to improve their craft. I just finished reading a great post How to be an expert, by Kathy Sierra on the blog Passionate that describes this idea much better than I ever could.
Most IT shops are broken, but there are solid ways to improve and even fix a lot of the problems. We, the developers, just need step up and realize that we are part of the problem but we can be part of the solution. Stop being a coding monkey and become a software craftsman.
No comments:
Post a Comment