Programming doesn’t have to be Magic
Posted
by Wes McClure
on Geeks with Blogs
See other posts from Geeks with Blogs
or by Wes McClure
Published on Wed, 11 Apr 2012 12:44:58 GMT
Indexed on
2012/04/11
23:31 UTC
Read the original article
Hit count: 592
In the show LOST, the Swan Station had a button that “had to be pushed” every 100 minutes to avoid disaster. Several characters in the show took it upon themselves to have faith and religiously push the button, resetting the clock and averting the unknown “disaster”. There are striking similarities in this story to the code we write every day. Here are some common ones that I encounter:
- “I don’t know what it does but the application doesn’t work without it”
- “I added that code because I saw it in other similar places, I didn’t understand it, but thought it was necessary.” (for consistency, or to make things “work”)
- “An error message recommended it”
- “I copied that code” (and didn’t look at what it was doing)
- “It was suggested in a forum online and it fixed my problem so I left it”
In all of these cases we haven’t done our due diligence to understand what the code we are writing is actually doing. In the rush to get things done it seems like we’re willing to push any button (add any line of code) just to get our desired result and move on. All of the above explanations are common things we encounter, and are valid ways to work through a problem we have, but when we find a solution to a task we are working on (whether a bug or a feature), we should take a moment to reflect on what we don’t understand. Remove what isn’t necessary, comprehend and simplify what is.
Why is it detrimental to commit code we don’t understand?
- Perpetuates unnecessary code
- If you copy code that isn’t necessary, someone else is more likely to do so, especially peers
- Perpetuates tech debt
- Adding unnecessary code leads to extra code that must be understood, maintained and eventually cleaned up in longer lived projects
- Tech debt begets tech debt as other developers copy or use this code as guidelines in similar situations
- Increases maintenance
- How do we know the code is simplified if we don’t understand it?
- Perpetuates a lack of ownership
- Makes it seem ok to commit anything so long as it “gets the job done”
- Perpetuates the notion that programming is magic
- If we don’t take the time to understand every line of code we add, then we are contributing to the notion that it is simply enough to make the code work, regardless of how.
TLDR
Don’t commit code that you don’t understand, take the time to understand it, simplify it and then commit it!
© Geeks with Blogs or respective owner