Wednesday, June 27, 2012

Ad Management services versus doing it yourself

Should you use an advertising management solution such as DFP Small Business or do it yourself?

(DFP stands for DoubleClick For Publishers. DoubleClick was bought by Google in March 2008 for $3.1 billion.)

If someone approaches me and wants to advertise on one of my sites my usual response is to tell them to use Google's AdWords program and target my site or pages on my site with their adverts. In my opinion, Google does a great job and they only take 32%. I don't have to get involved at all.

Sometimes it is worth my while to split that 32% with an advertiser and I'll add their advert to a site for a given time period.

The advantages of doing it yourself are advantages for the the advertiser, not for you the publisher:

  • If you host the advert's image and text on your site then it is almost impossible for Ad Blockers to block the ads because they are integrated images.
  • Your advertiser gets a one-way follow link to their site from your page.

The disadvantage is that you have to create an embedded solution to allow advertisers to upload their adverts to your site (the sophisticated solution) or you have to do it manually. Doing this yourself requires work on your part either way and you will have to measure the Return On Investment and if that extra revenue over AdSense is worth it.

Wednesday, June 20, 2012

Should the team upgrade to the latest version?

I manage a couple of teams of .NET developers. Like everyone else we are under pressure and deadlines to push out the next feature and keep our products moving forward, feature rich and profitable. Nothing new here.




The usual arguments put forward to justify an upgrade to the latest version of a framework or tool are one or more of the following:
  • It has new features.
  • It fixes bugs
  • It runs faster
They are acceptable and reasonable reasons but in my opinion not the most important.
The most important reasons for me to keep us on the latest releases are for developer engagement, retention and recruitment.
As a developer I hate to hear about features that are available but I cannot use because I'm not on the latest release and I know that most other developers feel the same way. The latest feature or paradigm in the current RTM version of your framework might not be the best solution for your project but we don't want it to be excluded because we don't have access to it. We want to be able to actively exclude it because it's not right for us.
When recruiting new members onto your team it makes it easier to be able to say "we use .NET [latest version] with ASP.NET MVC [latest version] and jQuery [latest version]." There are obviously other factors involved but this (1) eliminates the fear that the tools might not be current and (2) keeps you open to almost all developers out there. i.e. those that don't want to regress to earlier versions of a framework. We might not be using any features that have been introduced in the latest versions (we are) but at least that option is open to us.
For engagement and retention it's important for the same reasons. Everyone's happy because we all have access to the latest.
I believe that early upgrade is important to reduce the pain and is ultimately more efficient. If the team is used to upgrading the frameworks and/or tools frequently then it will be familiar, less painful and easier to plan for. For example, we try and upgrade to the latest version of jQuery once a quarter. We do this because our QA team likes to do a full multi-browser regression once a quarter and an upgrade to a new version of jQuery requires this type of regression.
I rarely attempt an immediate upgrade when a new version is released. I like to let it bake for 4 to 12 weeks and read some of the upgrade comments and let the owners address any of the issues the early adopters have encountered. By then there are a few good instructional blogs out there on how to deal with unusual errors and edge case upgrades.
I usually isolate the upgrade to be done by one developer, have him or her extensively document the experience and put a hard time limit on the upgrade attempt. If possible we push the upgrade out as its own release and don't combine it with features and bug fixes.