Kevin Pang

Twitter's "Small Settings Update" Is Anything But

Kevin Pang — Tue, 12 May 2009 21:05:00 -0700

Twitter's latest blog post titled Small Settings Update states the following:

We've updated the Notices section of Settings to better reflect how folks are using Twitter regarding replies. Based on usage patterns and feedback, we've learned most people want to see when someone they follow replies to another person they follow—it's a good way to stay in the loop. However, receiving one-sided fragments via replies sent to folks you don't follow in your timeline is undesirable. Today's update removes this undesirable and confusing option.

In other words, before this change you simply saw all tweets posted by the people you followed. Twitter has decided that that was too complicated. So instead, now you will only see tweets posted by people you follow if they are not replies to people you don't follow...unless the tweet doesn't begin with "@userwhoyoudontfollow", in which case you will still see the tweet since it's not really a "reply", but a "mention". There, much better! Thanks for clearing that up Twitter!

I honestly don't understand the motivation behind this change. From my perspective, the less tweets I see, the less valuable Twitter is to me as a conversation and communication service. I'm not sure what problem they were trying to address here, but judging from the initial response on Twitter there's obviously a disconnect between how Twitter thinks its users use it and how they actually use it.

Luckily there is a workaround.

Later in the Twitter blog post, they reveal that "discovery" is still possible:

Spotting new folks in tweets is an interesting way to check out new profiles and find new people to follow. Despite this update, you'll still see mentions or references linking to people you don't follow. For example, you'll continue to see, "Ev meeting with @biz about work stuff" even if you don't follow @biz. We'll be introducing better ways to discover and follow interesting accounts as we release more features in this space.

In other words, while replies to people you don't follow are now hidden from you, tweets that only "mention" people you don't follow are still visible.

Let's say I am following user A but not user B. Twitter's latest change makes it so that I won't see user A's tweet "@userB Let's go to the park!". However, if user A only "mentions" user B in their tweet: "I'm going to the park with @userB", then I can still see it.

So, if you want to make sure your replies are visible to all of your followers, just make sure your replies are actually "mentions" by prefixing them with a character. Expanding on the user A / user B example above, if user A changed their tweet to read "! @userB Let's go to the park!", I'd be able to see it again since it didn't start with "@userB". It's a silly hack, but then again it's a silly feature too so I don't feel too bad using it.

I'm hoping that this was just a temporary brain fart on Twitter's part and that it will soon be fixed or that there is some hidden benefit to this feature that I'm missing. What do you think about Twitter's "Small Settings Update"?

Edit 5/13/2009:

Due to user feedback, Twitter has decided to change how replies work again. Now, you should be able to see @user replies again, regardless of where the @user is placed...unless the reply was generated by clicking on the "reply" link, in which case it's still invisible. It's really amazing how many different, but equally infuriating, ways Twitter can come up with to solve this problem. They have also went against their original claim that this was changed for simplicity sake and now admit that the change was done because of architectural limitations.

Should You Use ASP.NET MVC?

Kevin Pang — Tue, 21 Apr 2009 15:50:00 -0700

There are a lot of ASP.NET web forms developers out there who admit that they simply don't "get it" when it comes to all the hubbub surrounding ASP.NET MVC. In some ways, I can sympathize with them. The vocal minority that raves about ASP.NET MVC gush about it with such zeal that they make it sound like you'd have to be a fool not to switch over. In actuality, the decision isn't nearly as black and white.

ASP.NET web forms aren't going anywhere. As much as I love ASP.NET MVC, it is not the end-all-be-all one-size-fits-all solution to web development. Both of these approaches have their rightful place in a web developer's toolbox and it's important to recognize their strengths and weaknesses. In general, the ASP.NET MVC framework tends to sacrafice ease-of-use (e.g. viewstate, validation, etc.) in order give developers tighter control over the reins. This can be a great thing, but only if you take advantage of it. Otherwise it can just as easily be a hindrance.

With that in mind, I have developed a quick metric to determine if ASP.NET MVC is right for you. The way I see it, there are three primary reasons a developer should choose the ASP.NET MVC framework over ASP.NET web forms. If none of these reasons are compelling to you, then you should stick with ASP.NET web forms:

To Unit Test

This, in my opinion, is the most compelling reason to use ASP.NET MVC. When it comes to unit testing, ASP.NET MVC simply blows ASP.NET web forms out of the water. It's not even close. Whereas ASP.NET web forms requires you to jump through all sorts of hoops to test around the page event lifecycle, the ASP.NET MVC framework practically begs to be tested. There are interfaces everywhere screaming "mock me!".

There's a reason why the biggest ASP.NET MVC supporters also tend to be TDD proponents; it's because ASP.NET MVC actually allows for TDD. Personally, I think this is where all the zeal comes from. Simply put: it's really, really hard to do TDD with ASP.NET web forms and really, really easy to do it in ASP.NET MVC.

To Gain Control and Extensibility

As pointed out in the comments, ASP.NET MVC gives you more control and extensibility options than ASP.NET web forms. You get complete control over the page request lifecycle and the ability to substitute out several key pieces of the framework (e.g. view engine, routing, etc.), none of which is possible with ASP.NET web forms.

In addition to this, you also gain full control over the rendered HTML. In general, the rendered HTML from ASP.NET web forms applications is atrocious. The web controls it utilizes generate garbage ids and hidden fields galore that not only hamper the performance of a site, but also make CSS styling and Javascript development a pain. ASP.NET MVC forces you to be more in tune with your HTML. There aren't any repeaters or datagrids that magically generate markup for you. There aren't any hidden fields to persist state for you. It's just you, the HTML, and a few extension methods (which you don't even have to use).

To Learn Something New

In other words, "because you feel like it". This was actually why I started using ASP.NET MVC. It never hurts to look at how you're approaching development from another angle.

I should also point out that learning ASP.NET MVC is incredibly engaging process since the ASP.NET MVC framework team has been so interactive in the process. I think a large part of the appeal of ASP.NET MVC is that the community's input is not only being taken into consideration, it is actively being sought after. The framework has sparked so many discussions and debates over best practices that simply following along introduces you to concepts you might previously have been unaware of. I would actually recommend learning the ASP.NET MVC framework for this reason alone. The threads on TDD, BDD, ORM, AJAX, etc. you stumble across during the learning process are worth it.

So there you have it. Aside from those three, I can't think of any other reasons why a developer would learn ASP.NET MVC. Maybe this is why the adoption rate isn't nearly as high as we think it should be. The incentive for using the framework essentially boils down to unit testing, control/extensibility, and boredom/curiosity. Good reasons, to be sure, but hardly game breakers for the vast majority of developers out there.

What do you think? I'm interested in seeing if anyone can come up with another reason(s) that I may have missed here. Why do you use ASP.NET MVC?

Content-Stealing Jerks

Kevin Pang — Sat, 28 Mar 2009 22:06:00 -0700

Edit 3/29/2009 7:23 PM:

It appears that Delimitdesign has finally caught wind of this thread and has altered their post to look less like a blatant rip off of mine. They also modified the post date from 3/28/2009 to 5/28/2008. Right. Too bad Google cache clearly shows their original post in its full copy & paste glory with the actual date they had posted it on:

You can view the full screenshot here. I took it just in case the Google cache page updated.

Original post:

I've grown somewhat accustomed to seeing my articles regurgitated on some random blogger's site and passed off as their own. Usually I just send the content-stealing jerk (CSJ for future reference) an e-mail asking that they provide some sort of link back to my original article and leave it at that. Sometimes they comply, oftentimes they don't. In the end, life goes on. After all, it's not like I'm going to press charges over it.

It's a problem that's existed ever since the advent of blogging. In general, I think bloggers have pretty much become desensitized to it. Every few months you'll hear someone cry foul, but that's about all we can do. Personally, I'm not a big fan of smear campaigns, especially since they tend to give the CSJs more traffic than they would have gotten otherwise. However, it seems that the CSJs are finally evolving from no-name bloggers with 5 readers to large, professional-looking CMS-type deals.

Thanks to some heads-up readers e-mails today, I found out that a site called Delimitdesign was featuring an article on their home page that was copied word-for-word from my blog.


My post	Delimitdesign's carbon copy

I promptly sent them an e-mail which thus far has gone unanswered. I also left a couple replies to the post which were not approved (surprise, surprise). I even @replied to them on Twitter without any luck. What's worse, it appears that I'm not the only one they've ripped off. Out of curiosity, I took a look at another one of their articles featured on their home page:

http://delimitdesign.com/inspirational/101-ways-to-know-your-software-project-management-is-doomed/

A quick Google search revealed that it was a carbon copy of an article written by someone else:

http://www.codesqueeze.com/101-ways-to-know-your-software-project-is-doomed/

After some more digging around, it became quite clear that several of their posts were turning up a separate, but identical, blog post written by someone else. In other words, the site appears to be digging up old, popular posts and regurgitating them as their own.

This is nothing new of course. I think most bloggers have put up with it so long simply because thus far the CSJs have been relatively harmless. But what do we do when the CSJs become more established?

Honestly, I'm not entirely sure how to react. My only recourses, thus far, have been to politely ask them to stop and to notify the public of their behavior.

It's not just the blogging CSJs we have to worry about either. As Jeff Atwood noticed today, someone seems to have ripped off the entire StackOverflow site:


StackOverflow	CNProg's carbon copy

What do we do in this case? It's not like Jeff has a copyright on his CSS, javascript, or design (edit: as pointed out by several commenters both here and on Reddit, he very well may, but whether or not he can enforce it is still questionable and dependent on where the infringers live and possibly how much is copied). It seems his only retort -- as well as mine -- is to cry foul and throw a little mud (exactly what I'm doing here). I think Jeff, and anyone else who has had their content ripped off, would agree that mud slinging isn't all that satisfying.

The only solution that I have devised to curtail this is to take away the CSJs incentive for ripping off other people's content (e.g. their visitors and thus, their advertising revenue). I propose a new site: ContentStealingJerks.com, which would let people flag articles they recognize as blatant ripoffs of someone else's original content. It could come with a firefox plugin that would redirect users to the original article when they visit a flagged page. What do you think? Good idea? Bad idea? Or already implemented and I just haven't realized it?

Edit 3/29/2009 3:58 AM:

Thanks to the comments readers have left here and on Reddit and Hacker News, I've learned that there are indeed things I can do. I have now reported Delimitdesign through Google Adsense's complaint feature (which should eliminate any monetary gains they've gained from their content ripping) as well as through Google Webmaster Tools (which should remove them from Google's search index). Tomorrow, I plan on filing a DMCA complaint as well.

I also discovered that Delimitdesign didn't bother to swap out the images when they copy/pasted my article, meaning their article is using images hosted on my server. So I took the liberty of swapping them out. Here's the final result:

Yes, I know. I missed a golden opportunity to use goatse or tubgirl or something along those lines. Don't think I wasn't tempted. In the end though, I'd rather just get the message out rather than gross out their (presumably) innocent visitors.

What ASP.NET MVC Can Learn From Ruby on Rails

Kevin Pang — Sat, 21 Mar 2009 14:52:00 -0700

Simon Torkumine, a Ruby on Rails developer, recently blogged about how the ASP.NET MVC framework compares to Ruby on Rails. While there are some parts of his post that I don't necessarily agree with (e.g. the anemic community, C# being too verbose), one point he brought up rang true to me:

.NET MVC is actually .NET VC. It is an attempt to replicate the Actionpack components of Rails. There is nothing included aside from a folder labeled “Models” to help you with your persistence later and domain modeling. As others have mentioned, there are other ORM tools out there, but bear in mind these are targeted at traditional ASP.NET development and are not integrated into the framework as in other MVC’s. This means that you’ll be writing your own validation and form handling code for starters.

I couldn't agree more. The biggest pain point in my development experience with the ASP.NET MVC framework has been its incredibly lax approach to the "M" in "MVC". Whereas the views and controllers are pretty much hashed out, developers are essentially thrown into the deep end when it comes to the model. That means that persistence and validation is completely up to us, which is great for experienced developers who have very opinionated views on what best to insert here but extremely terrifying when for developers approaching the framework for the very first time.

This may be a matter of opinion here, but for me web application frameworks are expected to come with all the necessities to get a basic site up and running. This is not so when it comes to the ASP.NET MVC framework. At first it appeared that Linq 2 Sql would be the clear-cut answer to the persistence question. After all, Linq 2 Sql was developed by Microsoft and was used in almost every single Microsoft blogger's posts on ASP.NET MVC. But then something happened. Microsoft announced that it would no longer be supporting Linq 2 Sql and ever since then the community has been a flock without a sheppard.

Microsoft's suggested replacement, the Entity Framework, is so actively despised by the community that there was a petition against it. To date, I have yet to see a single example of integrating the Entity Framework into an ASP.NET MVC application. NHibernate has a decent following, but it's not exactly user friendly or easy to set up. Subsonic, the obvious alternative to Linq 2 Sql doesn't appear to have garnered too much support.

Validation has also gone by the wayside because of this as it is tends to be tied in with the persistence layer. Scott Guthrie's initial post on validation in the ASP.NET MVC framework revolved around handling Linq 2 Sql's "OnValidate" event when saving off entities to the database. Now that Linq 2 Sql is essentially out of the picture, we're left with either writing our own or going with one of the many newly created OSS solutions like xVal.

There is a significant difference between being allowed to go outside the box and being forced to. The "rails way or the highway" approach that Ruby on Rails takes is great for beginners, but not so great when you want to go outside of the box. ASP.NET MVC's complete lack of guidance when it comes to models has the opposite problem in that beginners don't know what to do, but are free to explore whatever options they want. This may prove to be a big problem for the adoption rate of ASP.NET MVC now that it's advancing past the point of early adopters who are willing to put up with the growing pains.

To be clear here: I know that there are several valid solutions for how to handle validation and persistence in ASP.NET MVC, and it's great that each of them is available to us. The problem is that you have to actively hunt these solutions down instead of having one of them baked into the framework. It's great that ASP.NET MVC is so extensible that you can essentially plug in whatever you want, but at some point some basic guidance is called for. A blank slate is intimidating and not very user friendly.

In the end, it seems like there should be a middle ground between the Ruby on Rails approach and the ASP.NET MVC approach. Perhaps the project template could ask the user if they wanted to link this application up to an existing database or create a new one? If they did, it could generate the model (even if it were empty) using Linq 2 Sql and throw in Scott Guthrie's validation code in there as well? That would provide users with a starting point at least that could be easily ignored or stripped out if so desired.

What are your thoughts? I want as much as anyone else to see ASP.NET MVC become successful -- and in my opinion it could be -- and it would be a shame to see if struggle in the wild because it didn't take a few extra steps to cater to the beginner audience.

A Programmer's Plea to Laptop Makers

Kevin Pang — Thu, 12 Mar 2009 06:51:00 -0700

My laptop died recently and because of this I've been doing some preliminary research to find myself a replacement. It's been awhile since I've had to purchase a laptop, so I was a bit surprised when I couldn't immediately find one that I was satisfied with. For some reason I thought that finding a suitable laptop for development that met my short list of criteria wouldn't be very difficult. But the more research I did the more apparent it became that "software developer" wasn't a target demographic laptop manufacturers were trying to capture. With that being said, here's my short plea to laptop makers:

Don't Mess With the Home/End/Page Up/Page Down/Insert/Delete Keys

Seriously. We need those. There's a reason why the QWERTY keyboard layout has remained stagnant throughout the years. It's because people are used to it and they would riot in the streets if it suddenly changed. Why then, are the home/end/page up/page down/insert/delete keys somehow considered free game to be mangled beyond recognition? I realize that there are space constraints with laptop keyboards, but it's not as though preserving their layout hasn't been done before. In fact, I seem to recall more laptops with the standard 2x3 layout in the past than I see now.

Honorable mention: As someone mentioned in the comments, another common keyboard change is switching the function and ctrl keys. Most programmers -- and computer users in general -- use copy (ctrl-c + ctrl-v) and paste (ctrl-x + ctrl-v) so much that it's become a muscle reflex. Swapping these two keys takes a *lot* of adjusting to get used to.

Test the Heat Under Heavy Load

Ok, so here's the thing: every single laptop I have ever owned turns into a scalding hot piece of plastic punishment after running Visual Studio for 1-2 hours. I realize there are physical constraints that make cooling a laptop a significant challenge -- and I know that I may also be in the minority here -- but I'd be willing to put up with a bulkier (read: larger *gasp*) laptop if it meant that I could get proper cooling in return.

For the most part I think laptop "portability" is vastly overrated. The difference between carrying a 4 pound laptop and an 8 pound laptop isn't that big unless you're Steve Urkel (ok, so this may be a concern for the programmer demographic). I'm not playing shotput with my laptop. I'm not doing curls with my laptop. I'm putting it on my lap, which can handle a little extra weight being put on it. What it can't handle however is being scalded by a poorly ventilated brick of heat.

A 5400 RPM Hard Drive Is NOT Fast Enough

Scott Guthrie has a great blog post -- written one and a half years ago -- about how a 5400 RPM hard drive is often a bottleneck when developing on a laptop. Nowadays it's easy to find standard cookie-cutter laptop configurations with 4 GB of RAM and 2+ GHZ dual core processors that are secretly tied down by a 5400 RPM hard drive. Granted, this is less of a problem if you're willing to pay up the wazoo to upgrade to a solid state drive (and the advantages of these are even debatable in a development environment). For the rest of us, we're lucky to have an option to upgrade to a 7200 RPM hard drive, let alone a 10,000 RPM one.

Glossy Screens Can't Be Read In Daylight

As great as a glossy screen can be for watching DVDs in the black of night, I can't read a single thing on them in the daylight. Granted, this really isn't much of a problem since programmers are deathly allergic to natural light. But on the off chance that I want to get some work done at a park or at the beach, there's absolutely no way of doing this with a glossy screen.

Not All of Us Want a Widescreen

As mentioned in the comments, a widescreen isn't always best for programming. Vertical space is far more precious to a developer than horizontal space. Most code is in the first 80 characters, so having the abililty to see 300 characters across usually just leads to a bunch of excessive whitespace. Yes, if you're running multiple apps side-by-side, the widescreen monitor becomes very handy. But for the typical Visual Studio developer, this usually isn't the case.

Well, that's my list. I still haven't pulled the trigger on a purchase yet, but the comments have given me a lot to think about and research. I don't claim to be a hardware expert so if I have grossly mistated anything here, let me know. Have any other suggestions for this list? Leave them in the comments below.

Jeff Atwood Finally Jumps the Shark

Kevin Pang — Wed, 11 Feb 2009 14:18:00 -0700

Well, we all knew it had to happen eventually. After years of great blog posts and insightful commentary on the programming world, Jeff Atwood has finally jumped the shark in his latest post which essentially says "programming is hard, let's go shopping!".

Now I'm not entirely sure why Jeff and Joel have decided to wage war against SOLID. At first I thought it was just a bit of verbal diarrhea and I sympathized. I am very aware of how easy it is to say something stupid when you're just casually bantering with a friend or colleague. However, from the tone of his post and the subsequent comments it received, it seems that lines are being drawn and the battle is on.

Honestly, I don't really understand what all the commotion is about. SOLID isn't all that controversial in my opinion. Jeff's main problem seems to be that by introducing so many best principles and practices, we run the risk of overwhelming programmers with too much guidance:

The bigger and more grandiose the set of rules you come up with, the more severe the danger. A few broad guidelines on a paint can begets thirty rules for painting, which begets a hundred detailed principles of painting..

Pretty soon you'll find yourself believing that every possible situation in software development can be prescribed, if only you could come up with a sufficiently detailed set of rules! And, of course, a critical mass of programmers patient enough to read Volumes I - XV of said rules. You'll also want to set up a few messageboards for these programmers to argue endlessly amongst themselves about the meaning and interpretation of the rules.

He has a point, of course. If we reached the point where programmers relied so heavily on rules that it hindered their ability to code, then yes, we would have a serious problem on our hands. The problem is that this scenario is so laughably far from the reality of what average programmers are like that I wonder if Jeff and Joel are secretly just messing with us to see how much commotion they can stir up.

Dance puppets, dance!

The reality of the situation is this: the average programmer has probably never even heard of SOLID and couldn't care less about it even after it was explained to them. The idea that we are soon going to be swamped in bureaucratic rules that force us to think too much about the software we write is ludicrous when sites like TheDailyWTF still exist. If anything, we should be in support of anything that will force programmers to think more about the code they write, not less.

In the end though, Jeff has a hundred thousand RSS followers and I have orders of magnitude less. His post appeals to the lowest common denominator. It reinforces the belief that quality of code doesn't matter and it will garner massive support while mine will be lucky to get 20 people to even read through the first paragraph. That alone should be a testament to how skewed the software industry is in terms of those who care about quality code vs those who don't. Given that, are we absolutely sure we want to go down this path?

We're Pregnant!

Kevin Pang — Mon, 08 Dec 2008 20:02:00 -0700

In general I try to keep this blog as programming-centric as possible. However, I will make an exception for this:

We're Pregnant!

7 weeks along so far for those interested. All signs are normal right now *knock on wood*. With any luck, we'll be welcoming our new child into the world sometime around 7/28/2009! :-)

Do We Need Another Open ID Provider?

Kevin Pang — Wed, 29 Oct 2008 08:43:00 -0700

As many of you have undoubtedly have heard by now, Microsoft officially announced during PDC 2008 that Windows Live ID will become an Open ID provider. From the Live Services blog:

"You will soon be able to use your Windows Live ID account to sign in to any OpenID Web site!"

That's right! Soon you will be able to use your Windows Live ID account to log in to the 5 sites on the internet that suport Open ID!

All sarcasm aside, it does not appear that Microsoft will be joining those 5 sites and accepting Open ID logins. Color me unimpressed.

The success of Open ID has always, and continues to, hinge on there being websites that accept Open IDs. It's great and all that Microsoft has decided to join the Open ID party, but what they're doing doesn't really increase its utility. The whole point of Open ID is to make it so that users do not have to memorize a bunch of usernames and passwords to log into their accounts. Microsoft's latest move does little to further that cause since I still have to remember the same number of usernames and passwords as I did before.

At this point, the only sites that I use that accept Open ID are StackOverflow and ... I can't even think of another one. When you consider how many big names have now thrown their weight behind the Open ID movement -- Yahoo, AOL, and now Microsoft -- it should be shocking that when you mention Open ID to the average internet user all you get is a blank stare. That tells me that there is something systematically wrong with the way it is being promoted.

Update 10/29/2009 3:05 PM

It appears that Google has joined the list of Open ID providers who don't accept Open ID as well. Only they went one step further -- in the wrong direction -- by forking Open ID and implementing it in a way that isn't compatible with any other Open ID providers. Are you kidding me?

I think this Slashdot comment summarizes it quite well:

OpenID's vision statement:

OpenID eliminates the need for multiple usernames across different websites, simplifying your online experience.

Everyone else's vision statement:

Fuck OpenID, I'm in control now.

Is Code Coverage Really All That Useful?

Kevin Pang — Tue, 28 Oct 2008 09:08:00 -0700

Test driven development proponents often tend to push code coverage as a useful metric for gauging how well tested an application is. 100% code coverage has long been the ultimate goal of testing fanatics. But is code coverage really all that useful? If I told you that my application has 100% code coverage, should that mean anything to you?

What does code coverage tell us?

Code coverage tells us which lines in our application are executed by our unit tests. For example, the code below has 50% code coverage if the unit tests only call Foo with condition = true:

string Foo(bool condition)
{
   if (condition)
   return "true";
   else
   return "false";
}

What does code coverage not tell us?

Code coverage does not tell us what code is working and what code is not. Again, code coverage only tells us what was executed by our unit tests, not what executed correctly. This is an important distinction to make. Just because a line of code is executed by a unit test, does not necessarily mean that that line of code is working as intended.

For example, the following code could have 100% code coverage and pass all unit tests if it is never called with b = 0. However, once this code is introduced into the wild it could very well crash with a div by zero exception:

double Foo(double a, double b)
{
return a / b;
}

So what is code coverage good for then?

To borrow an analogy from Scott Hanselman's interview with Quetzal Bradley, imagine you are a civil engineer responsible for testing a newly constructed series of roads. To test the roads, your first thought might be to drive over them in your car, making sure that there are no potholes, missing bridges, etc. After driving over all of the roads a few times, you might conclude that they have been tested and are ready for public use. But once you open the roads to the public, you discover that the bridge overhangs are too low for big rigs, the turns are too sharp for sports cars, and that certain areas of the roads flood when it rains.

In the above scenario, you had the equivalent of 100% code coverage since you had driven over all the roads, but you only superficially tested their behavior. Specifically, you didn't test the roads in different vehicles and under different weather conditions. So although you went through each possible execution path, you failed to accomodate for different states while doing so.

In light of this, the only solid conclusion you can draw from code coverage seems to be what lines of your code have definitely not been tested. The lines that have been tested are still up for grabs it seems unless you are willing to go through each and every possible state the application can be in when executing them. This makes code coverage far less useful as a metric as it only tells you what still needs testing but offers you no help in determining when you are done testing.

What is a good metric then?

Unfortunately, there doesn't seem to be a good metric for determining whether a line of code has been thoroughly tested or when a developer is done testing. Perhaps this is a good thing as it keeps us from falling into a false sense of complacency. It simply isn't feasible in even a moderately complex application to test each and every line of code under every possible circumstance. The best case scenario seems to be to test the most common scenarios and reasonable edge cases, then add additional tests as functionality inevitably breaks on those scenarios that you didn't account for. It's an admitedly clumsy system, but it's a realistic one compared to depending on 100% code coverage to weed out all possible bugs. That's not to say that there isn't use in achieving 100% code coverage. Executing the code in one particular state still has value, just not as much as developers seem to give it.

As always, I'm very interested to hear your thoughts and observations on this. Please leave them in the comments below.

10 Programming Proverbs Every Developer Should Know

Kevin Pang — Tue, 07 Oct 2008 09:17:00 -0700

Proverbs are used to express universal truths or life lessons in a short and memorable fashion. I find that they are a great way to keep things in perspective, both in life and in work. Because of this, I have assembled 10 programming proverbs that every developer needs in their arsenal.

1. There is no smoke without fire

Relax. It's probably just another fire drill

Poorly designed code tends to manifest itself through some common tell-tale signs. Some examples of these are:

Giant classes and/or functions
Large blocks of commented out code
Duplicated logic
Deeply nested if/else blocks

Developers often refer to these as code smells, but personally, I think the term "code smoke" or "code fumes" is more appropriate as it implies a higher sense of urgency. If you don't address the underlying problem it will come back to burn you later on.

2. An ounce of prevention is worth a pound of cure

Ok, I'm convinced

Toyota's assembly line of the 1980s was famously efficient due to its revolutionary approach towards defect prevention. Each member of the assembly line was given the ability to halt production when they noticed a problem in their sector. The idea was that it was better to halt production and fix the problem as early on as possible than to continue producing faulty units that would be tougher and more costly to fix/replace/recall later on.

Developers often make the faulty assumption that productivity = cranking out code quickly. Many programmers dive straight into coding without a second thought towards design. Unfortunately, this Leeroy Jenkins approach towards software development tends to lead to sloppy, fragile code that will need to be constantly monitored and patched -- perhaps even replaced altogether down the line. Ultimately, productivity must be measured not only in how much time is spent writing it, but also by how much time is spent debugging it. A short term gain may prove to be a long term loss if one isn't careful.

3. Don't put all your eggs in one basket

A software team's bus factor is defined as "the total number of key developers who would if incapacitated, as by getting hit by a bus, send the project into such disarray that it would not be able to proceed".

In other words, what happens if you suddenly lost a key member of your team? Would business continue as usual or would it grind to a halt?

Unfortunately, most software teams fall into the latter category. These are the teams that turn their programmers into "domain experts" who only deal with requests that fall into their area of expertise.. At first, this appears to be a fairly reasonable approach. It works for the automaking assembly lines, why not for software development teams? After all, it's unreasonable to expect each member of the team to be intimately familiar with each and every nuance in the application, right?

The problem is that developers cannot be easily substituted and replaced. And while the pidgeon-hole approach works fairly well when everybody is available and accounted for, it quickly falls apart when "domain experts" suddenly become unavailable due to turnover, sickness, or even freak bus accidents. It is imperative that software teams have some sort of redundancy built in. Code reviews, pair programming, and communal code go a long way to foster an environment where each developer is at least superficially familiar with parts of the system outside their comfort zone.

4. As you sow, so shall you reap

The Pragmatic Programmer has this to say about the Broken Window theory:

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.

We've seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

In short, good code begets good code and bad code begets bad code. Do not underestimate the power of inertia. No one wants to be the one who has to clean up sloppy code, but neither does anyone want to be the one that makes a mess out of beautiful code. Write it right and your code will have a far better chance at standing the test of time.

5. Great haste makes great waste

Managers, clients, and programmers are getting more impatient by the day. Everything needs to be done and it needs to be done now. Because of this, the temptation to throw together hacks and quick-fixes becomes very tough to resist.

No time to properly unit test a new feature? Oh well, it works for the one test run you put it through. You can always come back to it later!

Mysterious object referencing error when you try to access property Y? Whatever, just throw a try/catch block around the code. We've got bigger fish to fry!

Sound familiar? It's because we've all done it at some point in time. And in certain instances, it is justifiable. After all, we have deadlines to meet and clients/managers to satisfy. But do it too often and you'll soon find yourself with a very unstable code base full of hotfixes, duplicated logic, untested solutions, and porous error handling. In the end, you have to strike a balance between getting things done and getting things done right.

6. Look before you leap

The term "Agile Development" is used and abused frequently these days, often as a way for programmers to justify ignoring the dreaded planning/designing phase of software development. We are creators, and as such we derive pleasure from seeing actual progress made towards a finished product. Surprisingly, UML diagrams and use case analysis just don't seem to satisfy that desire. So, we developers often start off coding without any idea of what we are doing or where we are going. It's like heading out for dinner when you haven't yet decided where you want to go. You're hungry so you don't want to waste time finding a restaurant and booking a table. Instead, you just hop in your car and figure you'll think of something along the way. Only, it ends up taking you longer because you have to make a bunch of U-turns and stops at restaurants that end up having too long of a wait. True, you'll probably find your way to food eventually, but you probably didn't end up with the meal you wanted and it probably took a lot more time and hassle than it would have had you just called and booked a reservation at a restaurant you wanted to go to.

7. When the only tool you have is a hammer, everything looks like a nail

See? I *told* you Active Record would work for this project!

Programmers have a tendency to get tunnel vision when it comes to their tools. Once something "just works" for us on one project, we tend to insist on using it for every project therafter. It can be a pain to learn something new and, at times, highly unsettling. The entire time we're thinking "it would have been easier had I just done it the old way!". Enough of these moments and we will simply go with what we know, even if it isn't a perfect fit for the task.

It's easy to stick with what you know, but in the long run it's much easier to pick the right tools for the job. Otherwise you will be fitting square pegs into round holes for the rest of your career.

8. Silence is construed as approval

I see nothing! Nuh-thing!

This ties in with the theory on broken windows and programming inertia, only on a larger scale. The programming community is just that, a community. Each programmer is a reflection on the craft. The more bad code that is released into the wild, the more it becomes the status quo. If you don't make an effort to write good, clean, SOLID code, you will find yourself having to work with it on a day-to-day basis.

Likewise, if you see poorly designed code written by someone else, you should make the effort to bring it up with the creator. I should note, however, that tact ought to be employed in such a situation. In general, programmers are willing to admit that they do not know everything there is to know about software development and will appreciate the gesture. We all benefit when we help each other out. Turning a blind eye to problems only perpetuates them.

9. A bird in the hand is worth two in the bush

There is a time and place to discuss system architecture and refactoring opportunities, and a time to just get things done. It is important to weigh the pros and cons of revamping something that already works just to make it cleaner. It's an admirable goal, of course, but there will always be code that you want to restructure. The programming world simply changes too frequently for code to not get outdated. But at some point you have to provide value to your customers. The simple fact remains: you can't do two things at once. The more time you spend refactoring old code, the less time you spend creating new code. Striking a balance is critical to enhancing as well as maintaining your application in a timely manner.

10. With great power comes great responsibility

Software has undoubtedly become an integral and vital part of our lives. Because of this, practicing good software development is more crucial than ever. It's one thing to have a bug in a game of Pong, it's another to have one in the guidance system of a space shuttle or air traffic control system. Slashdot recently posted an article describing how a minor glitch in Google News singlehandedly evaporated $1.14 billion in shareholder wealth. Events such as these demonstrate how much power we wield. It's a little frightening to think that the code you write today, whether you intend it to or not, may one day be recycled and depended upon for mission-critical applications. Write accordingly.

Do you have any proverbs you feel should be added to this list? Feel free to let me know in the comments!

Mapping Enums to Strings and Strings to Enums in .NET

Kevin Pang — Sat, 20 Sep 2008 04:51:00 -0700

I recently stumbled across a blog post demonstrating how to convert enums to strings using the Description attribute. I thought it might be useful to expand on that example by providing a function that reverses the process (e.g. takes in the resulting string and converts it back to the enum). This would allow you to do things like store off the description into a database and load it back into an enum or populate a dropdown list with the descriptions and save the user's selection back into your domain as an enum.

Rather than diving straight into code, let's just take a quick look at what the finished product lets you do. Say you have the following enumeration:

The code from the original blog post will allow you to retrieve any of the Description attributes by calling the ToDescription extension method:

And with the code I wrote, you will be able to perform the opposite conversion by calling the ToEnum extension method:

Ok, now let's look at how it all works:

Here is the slightly modified version of the extension method from the original blog post. It's pretty straightforward. It's an extension method on the Enum class that uses reflection to grab the Description attribute and output it. If no Description attribute is found, it returns the result of the ToString() function:

And here is my extension method that reverses the process. This extension method on the string class iterates over all enum values for the given enumeration, trying to find the one that has a Description attribute that matches the string that called it. If the extension method can't find this enum, it returns the default enum passed in the parameters.

I'm sure there are probably cleaner ways of doing this, but for mypurposes this works great and is easy to implement and manage. I'd be interested in hearing how others are handling this scenario in their own apps and whether this implementation would be useful at all. Let me know in the comments!

Debugging and the Five Stages of Grief

Kevin Pang — Mon, 15 Sep 2008 08:29:00 -0700

My latest article, Debugging and the Five Stages of Grief, has been published on Datamation! Here's a short excerpt from the intro:

As a programmer, you learn to accept bugs as a part of life. No matter how hard you try, there is no simple way to avoid them. What separates good programmers from bad programmers is not only their ability to avoid bugs, but also their ability to deal with them when they arise.

When programmers are confronted with bugs in their applications, they typically progress through what psychologists call the five stages of grief. These stages are a series of emotional states people experience when dealing with tragedy or loss in their lives.

It may seem a bit odd that something as common and benign as a bug could trigger this type of emotional reaction, but, in a way, it makes sense. Our applications are like our babies. We create them. We raise them. We watch them grow, all in the hopes that, someday, they will be able to set out on their own (and make some money to support us in our old age).

Click here to read the rest of the article, and don't forget to leave your comments!

Top 200 Tech Blogs

Kevin Pang — Tue, 09 Sep 2008 11:19:00 -0700

Datamation just posted their list of the Top 200 Tech Blogs and my blog came in at #165!

I'm honored. There are a lot of great sites in that list (#147 Joel on Software, #149 Coding Horror) and it's humbling to be included, especially given the short amount of time that I've been blogging.

On a side note, I'm currently wrapping up my next article and it should be posted shortly. Stay tuned! :-)

Top 10 Things That Annoy Programmers

Kevin Pang — Thu, 28 Aug 2008 10:21:00 -0700

Programmers all have their pet peeves. Whether it's scope creep, Hungarian notation, or smelly coworkers, we've come to accept that there are certain nuisances that come with our line of work. The following is a list of the top 10 things that annoy programmers, compiled from the results of my recent question on StackOverflow along with some of my own experiences:

10. Comments that explain the "how" but not the "why"

Introductory-level programming courses teach students to comment early and comment often. The idea is that it's better to have too many comments than to have too few. Unfortunately, many programmers seem to take this as a personal challenge to comment every single line of code. This is why you will often see something like this code snippit taken from Jeff Atwood's post on Coding Without Comments:

[code:c#]

r = n / 2; // Set r to n divided by 2

// Loop while r - (n/r) is greater than t
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}

[/code]

Do you have any idea what this code does? Me neither. The problem is that while there are plenty of comments describing what the code is doing, there are none describing why it's doing it.

Now, consider the same code with a different commenting methodology:

[code:c#]

// square root of n with Newton-Raphson approximation
r = n / 2;

while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}

[/code]

Much better! We still might not understand exactly what's going on here, but at least we have a starting point.

Comments are supposed to help the reader understand the code, not the syntax. It's a fair assumption that the reader has a basic understanding of how a for loop works; there's no need to add comments such as "// iterate over a list of customers". What the reader is not going to be familiar with is why your code works and why you chose to write it the way you did.

9. Interruptions

Very few programmers can go from 0 to code at the drop of a hat. In general, we tend to be more akin to locomotives than ferraris; it may take us awhile to get started, but once we hit our stride we can get an impressive amount of work done. Unfortunately, it's very hard to get into a programming zone when your train of thought is constantly being derailed by clients, managers, and fellow programmers.

There is simply too much information we need to keep in mind while we're working on a task to be able to drop the task, handle another issue, then pick up the task without missing a beat. Interruptions kill our train of thought and getting it back is often a time-consuming, frustrating, and worst of all, error-prone process.

8. Scope creep

From Wikipedia:

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project's scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided.

Scope creep turns relatively simple requests into horribly complex and time consuming monsters. It only takes a few innocent keystrokes by the requirements guy for scope creep to happen:

Version 1: Show a map of the location
Version 2: Show a 3D map of the location
Version 3: Show a 3D map of the location that the user can fly through

Argh! What used to be a 30 minute task just turned into a massively complex system that could take hundreds of man hours. Even worse, most of the time scope creep happens during development, which requires rewriting, refactoring, and sometimes throwing out code that was developed just days prior.

7. Management that doesn't understand programming

Ok, so maybe there are some perks.

Management is not an easy job. People suck; we're fickle and fragile and we're all out for #1. Keeping a large group of us content and cohesive is a mountain of a task. However, that doesn't mean that managers should be able to get away without having some basic understanding of what their subordinates are doing. When management cannot grasp the basic concepts of our jobs, we end up with scope creep, unrealistic deadlines, and general frustration on both sides of the table. This is a pretty common complaint amongst programmers and the source of a lot of angst (as well as one hilarious cartoon).

6. Documenting our applications

Let me preface this by saying that yes, I know that there are a lot of documentation-generating applications out there, but in my experience those are usually only good for generating API documentation for other programmers to read. If you are working with an application that normal everyday people are using, you're going to have to write some documentation that the average layman can understand (e.g. how your application works, troubleshooting guides, etc.).

It's not hard to see that this is something programmers dread doing. Take a quick look at all the open-source projects out there. What's the one thing that all of them are constantly asking for help with? Documentation.

I think I can safely speak on behalf of all programmers everywhere when I say, "can't someone else do it?".

5. Applications without documentation

I never said that we weren't hypocrites. :-) Programmers are constantly asked to incorporate 3rd party libraries and applications into their work. In order to do that, we need documentation. Unfortunately, as mentioned in item 6, programmers hate writing documentation. No, the irony is not lost on us.

There is nothing more frustrating than trying to utilize a 3rd party library while having absolutely no fricken idea what half the functions in the API do. What's the difference between poorlyNamedFunctionA() and poorlyButSimilarlyNamedFunctionB()? Do I need to perform a null check before accessing PropertyX? I guess I'll just have to find out through trial and error! Ugh.

4. Hardware

Any programmer who has ever been called upon to debug a strange crash on the database server or why the RAID drives aren't working properly knows that hardware problems are a pain. There seems to be a common misconception that since programmers work with computers, we must know how to fix them. Granted, this may be true for some programmers, but I reckon the vast majority of us don't know or really care about what's going on after the code gets translated into assembly. We just want the stuff to work like it's supposed to so we can focus on higher level tasks.

3. Vagueness

"The website is broken". "Feature X isn't working properly". Vague requests are a pain to deal with. It's always surprising to me how exasperated non-programmers tend to get when they are asked to reproduce a problem for a programmer. They don't seem to understand that "it's broken, fix it!" is not enough information for us to work off of.

Software is (for the most part) deterministic. We like it that way. Humor us by letting us figure out which step of the process is broken instead of asking us to simply "fix it".

2. Other programmers

Programmers don't always get along with other programmers. Shocking, but true. This could easily be its own top 10 list, so I'm just going to list some of the common traits programmers have that annoy their fellow programmers and save going into detail for a separate post:

Being grumpy to the point of being hostile.
Failing to understand that there is a time to debate system architecture and a time to get things done.
Inability to communicate effectively and confusing terminology.
Failure to pull ones own weight.
Being apathetic towards the code base and project

And last, but not least, the number 1 thing that annoys programmers...

1. Their own code, 6 months later

Don't sneeze, I think I see a bug.

Ever look back at some of your old code and grimace in pain? How stupid you were! How could you, who know so much now, have written that? Burn it! Burn it with fire!

Well, good news. You're not alone.

The truth is, the programming world is one that is constantly changing. What we regard as a best practice today can be obsolete tomorrow. It's simply not possible to write perfect code because the standards upon which our code is judged is evolving every day. It's tough to cope with the fact that your work, as beautiful as it may be now, is probably going to be ridiculed later. It's frustrating because no matter how much research we do into the latest and greatest tools, designs, frameworks, and best practices, there's always the sense that what we're truly after is slightly out of reach. For me, this is the most annoying thing about being a programmer. The fragility of what we do is necessary to facilitate improvement, but I can't help feeling like I'm one of those sand-painting monks.

Well, there you have it. The top 10 things that annoy programmers. Again, if you feel that I missed anything please be sure to let me know in the comments!

Visual Studio Tip: Split Views

Kevin Pang — Tue, 19 Aug 2008 08:43:00 -0700

There are a couple of ways to get a split view in Visual Studio. Both are incredible time savers that I use daily. The first is one that most developers will be aware of, but the second seems to be one that many do not seem to know about.

Viewing Two Files in a Split View

Let's say you have two classes you want to compare side by side:

Move your mouse over the Class1 tab and click and drag to anywhere on the window. When you let go, Visual Studio will prompt you on whether you wish to open a new horizontal tab group or a new vertical tab group:

As you might expect, a new horizontal tab group will split your screen horizontally, and a new vertical tab group will split your screen vertically. For most developers, I would say a horizontal split makes more sense so you don't have to scroll to see the end of your lines:

This is a very convenient way to compare and edit files side by side. I have seen several developers take advantage of this feature and it's a great alternative to switching back and forth via the tabs or keyboard shortcuts.

Viewing the Same File in a Split View

What I haven't seen many developers take advantage of however, is a technique I use nearly as often: splitting the same file in Visual Studio. Let's say you have a single file that is relatively long:

If you want to compare code from one section of this file to another, normally you would have to set bookmarks or just manually scroll back and forth to see both sections of the code. However, if you hover your mouse over the region right above the scroll bar, you will notice your mouse icon changes from the pointer to the vertical resize tool:

Now if you click and drag down, you'll get a split view of your current file!

Both sections of the split view are editable and will update each other in real time. When you're done, simply drag the divider all the way to the top and you're back to the normal view!

This feature comes in very handy when you have long functions or classes and want to compare sections of the code (e.g. reviewing object instantiation before using the object, looking over similar business logic that you want to mimic, etc.). This feature is available in Visual Studio 2005 and 2008 (and possibly earlier versions, if anyone can confirm please let me know).

Kevin Pang

Twitter's "Small Settings Update" Is Anything But

Should You Use ASP.NET MVC?

To Unit Test

To Gain Control and Extensibility

To Learn Something New

Content-Stealing Jerks

What ASP.NET MVC Can Learn From Ruby on Rails

A Programmer's Plea to Laptop Makers

Don't Mess With the Home/End/Page Up/Page Down/Insert/Delete Keys

Test the Heat Under Heavy Load

A 5400 RPM Hard Drive Is NOT Fast Enough

Glossy Screens Can't Be Read In Daylight

Not All of Us Want a Widescreen

Jeff Atwood Finally Jumps the Shark

We're Pregnant!

We're Pregnant!

Do We Need Another Open ID Provider?

Is Code Coverage Really All That Useful?

What does code coverage tell us?

What does code coverage not tell us?

So what is code coverage good for then?

What *is* a good metric then?

10 Programming Proverbs Every Developer Should Know

1. There is no smoke without fire

2. An ounce of prevention is worth a pound of cure

3. Don't put all your eggs in one basket

4. As you sow, so shall you reap

5. Great haste makes great waste

6. Look before you leap

7. When the only tool you have is a hammer, everything looks like a nail

8. Silence is construed as approval

9. A bird in the hand is worth two in the bush

10. With great power comes great responsibility

Mapping Enums to Strings and Strings to Enums in .NET

Debugging and the Five Stages of Grief

Top 200 Tech Blogs

Top 10 Things That Annoy Programmers

10. Comments that explain the "how" but not the "why"

9. Interruptions

8. Scope creep

7. Management that doesn't understand programming

6. Documenting our applications

5. Applications without documentation

4. Hardware

3. Vagueness

2. Other programmers

1. Their own code, 6 months later

Visual Studio Tip: Split Views

Viewing Two Files in a Split View

Viewing the Same File in a Split View

What is a good metric then?