Comments on a ‘Programming Sins’ Blog

Comments on a ‘Programming Sins’ Blog

Comments on a ‘Programming Sins’ Blog 150 150 infrastructure

Recently my attention was caught by an article titled “The 7 Deadly Sins of Software Development.” (Since they do not allow new users to register on their site, I’m posting my comments here.) It challenged me enough to see how relevant and true were the points mentioned by the blog author. Although it can be said that the “sins” do exist and should be tackled or avoided, these are not one hundred percent applicable to all situations.

Let me cite a few exceptions on the subject, like contradicting habits.

It might be due to the competitiveness of man that one is tempted to introduce a new idea or method to an already running or established work. Undoubtedly, this can cause disturbance and since one cannot really guarantee whether the new idea will function or not, then it could be considered to be wrong to take up the new idea on top of an existing and tested program. However, if the “new” idea was known, tested and proven to be a good one and confirmed to be compatible with all aspects of the work involved, then it will be better to apply the new idea and use it instead of maintaining the old one just for the sake of avoiding the added work of adjusting the details needed for the transition of the program format from old to new.

Improving on one’s work is never wrong especially when we consider how technology changes so quickly at present.

Another common error on the job is “gobbling up plate after plate of new features” and thereby losing time to evaluate the real effect of each one, whether it is efficient and truly useful for the user. Time constraint is usually the excuse given when one cannot check on the various features implemented one on top of the other, but this should not be an acceptable norm for a software developer if one truly wanted to be effective and accomplished. The periodic review and making of applicable code refactoring is a sound practice that should be done in this case. It will ultimately result to having good software development since adjustment or improvement could be done as soon as the problem is spotted and further evaluation is continuously done as fresh technology becomes known to the developer.

Also mentioned in the article is the common effect of communication in the work place, particularly with regard to the absence of proper communication flow. Intrigue, redundancy of tasks done and many others can result from having ineffective communication flow which we also call “misunderstanding.”

When a job is not discussed properly among team members, there is the tendency of unintentional overlapping or doing the same things over by some members that could be misconstrued as an act of “competing across teams.” When “commenting of codes” is omitted on the pretext that others should also know about it, is also a common cause of miscommunication and should be avoided as much as possible. It is better to create a program based on clear facts rather than making one based on assumptions that could be faulty.

In conclusion, the seven sins cited by the author indeed merit attention, especially from developers who want to excel on their field and be progressive.