We have all worked with that-guy, the person who points out inconsistencies in your SCM commit comments, the guy that can go on and on about best practices for documentation and put your whole lunch group to sleep. That is not the reason why you became a developer, you want to be creative, clever, and solve problems in novel ways with the latest and the greatest languages and tools. Anyway your nerves are a little fried because you just got off a week of grinding away at the final merge for your latest project and when you deployed to QA today the new version of the application wouldn't raise on nginx. No one is in the mood to listen to this guy.
I hate to rain on all our parades but we need to listen to process wonks and best practice nerds because those long weeks are a direct result of sloppy development and a lack of engineering discipline. Best practices exist for a reason, I have a friend and former co-worker who use to say that he was paid to create nothing, he would ask, "Have you ever actually seen software!? I'm not sure software actually exists, I don't believe it."
My interpretation of what my friend's point is, is that software isn't so much about 1's and 0's on a disk but the effect those 1's and 0's create. The basic fundamentals about what software does are encoded in SCM, code standards, documentation, and testing that make up best practices in software engineering. The absolute basics that all software must do are, the code base must be maintainable and the builds of the software released for use must be easily reproducible. But as humans we have a tendency to place high value on more exciting and emotionally stimulating aspects. Allow me to continue.
There is also the the other-guy that we work with, the guru who writes such awesome code, this guy can get anything to do just about anything he wants. You spent hours in awe when you had the privilege to work on a refactor of one of his early projects. You got to pair with the guru as he walked you through his code and the ideas behind his decisions. You learned a lot, saw things that blew your mind, and you would not have been able to work on that refactor without first being enlightened by the guru.
Needing to be walked through an existing code base by the developer who created the software in order to understand the application is not something to exalt. Even worse is to have to spend weeks writing missing unit tests and documentation as you walk through an existing code base written by someone else who is no longer available to speak with, or has limited availability. Having to reverse engineer someone else's work is colloquially known as 'eating someone else's dog food' and I don't particularly care for it. I have left opportunities for no other reason than I spent most of my day eating a star developer's dog food with no end in sight because was no will in management to improve code quality or the development process. The star developer delivered what management wanted when management wanted it, and management saw no reason to enforce any change.
Often accompanying the guru's projects are a collection of undocumented scripts and configuration files that must be refactored for each deployment through a trial and error process. These script and config files are often passed back and forth in emails, placed on shared drives and can even be found dangling on someone's USB drive attached to their keychain. Sometimes there was an attempt at some point to create universal versions of these scripts and config files, but those checked in versions quickly go out of date as old habits die hard. Much like our mothers nagging us about eating our vegetables, wearing clean underwear, and bringing our jacket, we know we should but it just isn't cool. Well neither is spending weeks putting in long hours to fix bugs and deployment issues. Following some best practices and enforcing some processes would go a long way to reducing the frequency of those long weeks.
I personally am more of process wonk/best practice nerd, I don't enjoy hacking away at code trying to get something to work without doing the engineering necessary to unsure that the solution is sustainable and stable. The code I produce is managed by SCM, unit tested, commented/documented and tagged in SCM for easy access. I believe that anything short of taking these steps is professional miss conduct, and I personally view the code that I create as a legacy. How that software is perceived when another engineer opens those files next week, next month or years from now is as important as the effect that the software creates when run.
No comments:
Post a Comment