Week 5 Reading Response

In order to uphold tradition, I will be beginning this post with this week's all-famous Peeblogs. Unfortunately Mr. Peebles was abroad for the majority of the week, so Peeblogs were few and far between. However, despite the scarcity of these little nuggets of truth, I still managed to garner just a few:

--It is very difficult to implement a system that regulates employee promotions and bonuses accurately. This is primarily caused by what Sir Peebles referred to as "optimizing to the metric." In other words, if you setup a metric that is supposed to measure how much an employee has accomplished, that employee will always pay extra-special attention to that metric, making sure to go "above and beyond the call of duty" in the specific area of that metric. This makes it seem that the employee deserves a raise or a promotion, when, in reality, they have merely "optimized to the metric."

--It is quite common for an employee to be promoted to his "highest level of incompetency." This results from the employee working his way up the career ladder, earning rightful promotions until he eventually gets promoted to such a high position that he is no longer competent to do his job. The employer is then faced with a dilemma. Should the employee continue to underperform in his current role, be demoted back to his highest level of competency, or be let go?

--The corollary to the previous point is that managers must think very long and hard before they promote an employee. Demotions are rarely a feasible option, as it generally leaves the employee dejected, dispirited, and embarrassed. Promoting an employee too far is a good way for a company to lose of its most valuable and successful workers.

Moving on, week 5's assigned reading involved three articles on unit testing, which were helpful, because I ended up spending the majority of Week 5 writing my first unit test. I will touch upon each of the three articles briefly.

Article #1 was entitled "Why are we embarrassed to admit that we don't know how to write tests?" It's author drove home the point that "The secret in testing is in writing testable code!" He gave several practices to avoid in order to write code that can very easily have unit tests written for it. I will now quote his second point, which I felt was his best comment in the entire article, "The developers are where the mistakes are made, and testers are the ones who feel the pain. Do you think that the developers have any incentive to change their behavior if they don't feel the pain of their mistakes?" I feel that Sentry addresses this issue by requesting that the developer also be the one to write a corresponding unit test for his own code.

Article #2 was "The Advantages of Unit Testing Early." Three advantages that stood out to me:

Instantaneous Gratification-

-Writing a unit test as you code or even before you code allows you to test a small component of a larger application that has not yet been completed.

Refactoring Safety Net-

-Having a pre-existing unit test allows a developer to refactor code and then check to make sure that he did not break anything.

Documentation-

-Unit tests can be used as a reference to find out what a particular method or class is supposed to do and how.

Article #3--"How to Write 3v1L, Untestable Code." This last article was a blend of poorly written and hilarious. The author decided to turn his blog into satire, writing from a purely sarcastic standpoint. I couldn't have agreed more with one of the readers who aptly commented that, "While the content of this post was excellent, the disingenuous, sarcastic, say-the-opposite-of-what-I-mean style of it was a complete turn-off. I hope you consider re-posting this information in a positive, "what-to-do" style, so that people don't have to parse through all of your negations just to get some good tips." The principle that hit home for me was that I should not use lengthy/intricate if-branches. I have a nasty habit of doing such at school on projects that are merely tested for functionality, and this was a good reminder to break such a habit. I will let points #2 and #3 speak for themselves as they are quite comical and will allow a small glimpse of the sarcastic style of the article:

"Macros are your Friends - Always use #ifdef PROD and other compile-time switches to make sure the testies can't get at your really important blocks of code and test them. In fact, this code won't even run: until it gets to production!"

"Final Methods - Use final classes and methods all the time. They can't be overridden for testing (-; But don't bother making fields final, or using value objects (without setters) - just let your objects' state be changed by anything and anyone. No sense in guaranteeing state, it'd make things too easy."

As parting words of hope, I would just like to let you know that it is merely Monday, and I have already acquired useful material for next week's Peeblogs!