Cross posted from http://blogs.msdn.com/willy-peter_schaub …
On the community blog server, http://dotnet.org.za back home in South-Africa, I noticed a series of WTF (will not elaborate on the acronym, unless it stands for word to field) which is turning ugly. So much so, that I felt like placing my Swiss steel helmet close by, just in case.
While the author of the blogs probably opted for a bad acronym and unfortunately disabled comments, his intentions were good. Instead of the flaming war which is currently raging between members of the community, the posts should have encouraged the readers to use the opportunity to “share experience” and allow everyone to share, learn and improve as a community. Unfortunately the comments were disabled for an obvious reason … when you enable comments on your blog you get 1% constructive feedback and 99% spam, offers to buy and evolve things you would never have dreamt of in the first place … I too, have disabled automatic comments on my blog and am spending a lot of unnecessary time separating the good from the bad.
Back to the WTF series of posts … here is my view for those interested:
- Be extremely careful when defining “guidelines”, “standards” or critiquing software designs and code. It needs to be reviewed and commented on in the context it was written, not in the context of the perfect world.
- Be open to share the good, the bad and the ugly, discuss not argue about about it and keep the discussions constructive … never ever take IT personally, else you will GP fault sooner than later.
- Be careful when using terms such as WTF and RTFM, because they can cause unnecessary and often unintentional reactions … as was the case on http://dotnet.org.za.
The most important point, in my humble opinion, is that the context under which a solution and code was developed must be considered during discussions. Surely we have all had the pleasure of writing code in good times (lots of time, best specifications imaginable) and writing code “under fire”, moving milestones, incomplete specifications, no time, fixing a production bug, … in fact, the latter far exceeds the former.
At the end of the day it is important to remember that the paying stakeholder does not care how you fix a bug in production, which is holding up 100 traders during the busiest time of the day … just that you fix the bug. This, however, does not give you a license to kill, because we must always consider the maintenance team that will eventually take ownership and support the solution. Keep them in mind at all times, because well documented code, code that delivers business functionality and code that is simply maintainable, is far more appreciated that the perfect code.
In a perfect world we should always design perfect solutions and write perfect code. However, the world is definitely not a perfect place and it is more important to SHIP a working solution that to create a perfect solution that gets close to SHIP’ing, but never quite gets there. I often call Judge Dredd to the rescue when I am pondering over spending just that little more time to make it just that little bit more perfect, instead of shipping it “as is”.
Gentlemen, be critical, be interactive, but switch off those flame throwers and “collaborate”.