Kevin Pang

Dependency Injection For Dummies

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Sat, 07 Nov 2009 11:52:00 -0800

The goal of this series is to introduce programming patterns and practices to developers who have little to no familiarity with them. This series does not intend to dive into the intricacies of each pattern / practice, but to give a brief overview that will (hopefully) inspire developers to learn more about them.

What is it?

In a nutshell, dependency injection is a design pattern where external dependencies are "injected" into components rather than baked in.

If that made your eyes glaze over, think about it like this: imagine your friend asked you to drive him to the supermarket:

You would probably just hop in your car and take him:

Now, what if your friend asked you to drive him, and his 5 friends, to the supermarket, but your car only seats 4?

You would need a bigger car, right? Well, the good news is that since most cars implement the same interface (steering wheel, accelerator, brakes, etc.), you're not only capable of driving your own car but many other cars as well. So if you had access to say, your mom's minivan, you could complete the trip:

At the root of it, that's what dependency injection is all about. Instead of you being stuck having to always use your car for your trips, you will be given the correct car to use based on the circumstances.

Bringing this back into software terminology, in the analogy above you (the driver) are a class and the car is your dependency. You depend on the car to drive your friend(s) to the supermarket. It doesn't matter which car you use, so long as it's familiar to you. Without dependency injection, the You class might look something like this:

Notice how you'll always be using that particular instance of Car to complete the trip. With dependency injection however, the You class would look something like this:

Notice how now you don't know (or care) what car you'll be getting to complete your trip. The car is given to you by an outside entity via the constructor.

Ok great, so why should I care?

One reason is the one alluded to above. Dependency injection helps you create "loosely coupled" classes. What this means is that your classes will have less knowledge about their dependencies. This is a good thing. First, because it allows you to only expose functionality in your dependencies that your classes need (e.g. you don't care what make or model or engine the car has, only that it drives and you're capable of driving it). Second, because it lets you quickly and easily substitute out your dependencies (e.g. replacing the car with a minivan), which makes your code more flexible and also lets you swap out implementation without having to modify or recompile your dependent class.

Another reason is for unit testing. Dependency injection allows for something called "mocking". What this means is that in your unit tests, you don't actually have to inject concrete dependencies. Instead, you can inject "mock objects", which are easy to create (via mocking frameworks) and define behavior for. This lets you test the behavior of your dependent class without having to worry about whether the dependencies are working as expected (you can test the dependencies in another unit test). This means your unit tests will be more in line with what unit tests are supposed to be: tests on individual units of an application (as opposed to tests on a unit and its dependencies and its dependencies dependencies, etc.)

Where can I learn more?

There's been a lot written about dependency injection, but I think the wiki article covers it pretty well.

Once you've got that down, the next thing you'll probably be interested in is Inversion of Control Containers. These containers make dependency injection a breeze by allowing you to configure default implementations to inject into your classes. Martin Fowler's article on dependency injection covers this well.

Note: Yes, I did draw all the pictures using Paint and a laptop trackpad. No, I do not plan on selling my artwork anytime soon.

There's No Such Thing As A Duct Tape Programmer

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Mon, 26 Oct 2009 17:47:00 -0800

About a month ago, Joel Spolsky had the software developer community up in arms over his article, "The Duct Tape Programmer". Everyone with a blog felt compelled to throw in their knee-jerk response, faithfully declaring their allegiance to either Joel and the duct tape crowd or the do-it-right crowd. And as so frequently happens on the internet, the whole argument degenerated into an enormous straw man fight. Duct tape programmers complained about how endlessly debating best practices and writing unit tests doesn't get anything done, while do-it-right programmers argued that poor design leads to maintenance nightmares down the line. Both assertions are correct of course, but they miss out on one key point: there's no such thing as a duct tape programmer.

To expand on Joel's analogy, you won't find a carpenter who only uses duct tape to fix things. Similarly, you also won't find a carpenter who doesn't know how to use duct tape or refuses to use it under any circumstances. All carpenters have duct tape in their toolbox. What differentiates a good carpenter from a bad one isn't whether they use duct tape, it's how well they use it and when they choose to use it.

Bringing this back into software terminology, there are situations where delivering code quickly is more important than delivering it correctly. Yes, even if it means there are bugs. Yes, even if it means maintenance will be a nightmare. For instance, when your team is in a race against other competitors to be the first one out the door (e.g. iPhone development, Facebook app development) or when deadlines absolutely, positively must be met (e.g. your company will be sued if it doesn't meet some compliance issue by a certain date or you'll lose a potential client if a certain feature isn't implemented by their go-live date). In situations like these, getting things done trumps anything else and if it has to come at the cost of good coding practices, then so be it.

But -- and this is a big but -- , these situations are the exception, not the rule. The difference between a good developer and a bad developer isn't whether they use duct tape, it's how well they can recognize whether a situation calls for it. Bad developers use duct tape far too often, either because they're too lazy to implement something correctly or because they simply don't know of any other way to do it. Good developers keep their duct tape handy for when they need it, but are usually smart enough to come up with better solutions instead.

Twitter's "Small Settings Update" Is Anything But

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Tue, 12 May 2009 21:05:00 -0800

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?

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Tue, 21 Apr 2009 15:50:00 -0800

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

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Sat, 28 Mar 2009 22:06:00 -0800

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

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Sat, 21 Mar 2009 14:52:00 -0800

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

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Thu, 12 Mar 2009 06:51:00 -0800

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

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Wed, 11 Feb 2009 14:18:00 -0800

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!

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Mon, 08 Dec 2008 20:02:00 -0800

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?

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Wed, 29 Oct 2008 08:43:00 -0800

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?

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Tue, 28 Oct 2008 09:08:00 -0800

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:

[code:c#]

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

[/code]

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:

[code:c#]

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

[/code]

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

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Tue, 07 Oct 2008 09:17:00 -0800

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

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Sat, 20 Sep 2008 04:51:00 -0800

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

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Mon, 15 Sep 2008 08:29:00 -0800

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

kpanghmc.nospam@nospam.gmail.com (Kevin Pang) — Tue, 09 Sep 2008 11:19:00 -0800

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! :-)

Kevin Pang

Dependency Injection For Dummies

What is it?

Ok great, so why should I care?

Where can I learn more?

There's No Such Thing As A Duct Tape Programmer

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

What is a good metric then?