Author: Scott

NCover goes corporate

Posted on by Scott

I was on vacation when this happened, but NCover has become a product you pay for.  The rationale for the change is a fair one, and I’m impressed by how Gnoso (the vendor of NCover) is looking out for people who donated to the project when it was free.  NCover 1.58 remains free, but doesn’t have the same level of features as NCover 2.0 (or 2.0 Enterprise).

Gnoso has that product niche basically themselves since Cenqua, the vendor of Clover.NET, got bought by Atlassian in August.  Since Atlassian is end-of-lifing Clover.NET, the coverage tool bundled with Team Foundation Server is the only option for .NET code coverage functionality.
Given the choice between paying for functionality that used to be free and losing it altogether (as happened with NDoc), I’d fork over the dough in at least some cases.  Whatever they intend to charge, odds are they won’t be Microsoft prices.
It will be interesting to see how many other tools that are currently free make a similar transition.

Lessons from failure

Posted on by Scott

It’s an older Reg Braithwaite post, but an excellent one.  His four most important causes of failure are all painfully familiar.  The paragraphs he writes on hiring practices and “development hygiene” are especially important.  In an environment where the cheapest vendor wins, those two areas are the source of many problems.

The post does a very good job of pointing out how weak stakeholders can doom a project.  There’s also a clear example of how office politics can play havoc with outcomes.

It’s a pretty long post, but very worthwhile reading.

Back from vacation

Posted on by Scott

While I haven’t made much headway on my other four resolutions for 2007, I just accomplished the fifth one–a two-week vacation. From September 5-19, I visited Seattle, Vancouver (BC), and Portland. Two weeks was definitely the right amount of time to decompress from work and its typical concerns.

Of the three cities I visited, Vancouver impressed me the most. It’s the only city I’ve ever visited with a public transit system that can take you from the heart of downtown to the base of a mountain (Grouse Mountain). Stanley Park is a two-in-one attraction because it’s home to the Vancouver Aquarium too. Harbour Centre (in downtown Vancouver) has a Space Needle-like observation deck stuck on top of it that gives you a 360-degree view of the city.  Vancouver was easily the most expensive of the three cities where I stayed.  Some Canadians must be doing quite well financially, because there appeared to be an abundance of late-model Porsches on the streets.

Seattle was the first city I’d visited that had wi-fi on its public buses.  It also proved to be as hilly as San Francisco.  I got to enjoy plenty of great seafood there, though I didn’t see any flying fish at Pike Place Market.  Seattle was also more of a college football town than I expected.  There were fans everywhere in Washington State Cougars and Washington Huskies gear.  There were also a lot of orange-shirted fans from Idaho (the Huskies opponent the weekend I was in Seattle).  The most interesting thing about the Space Needle was the exhibit inside where you could view time lapse photos of Seattle over a 24-hour period taken from cameras mounted on top.  The monorail was underwhelming, but I was quite entertained by the Experience Music Project and the Science Fiction Museum and Hall of Fame.  People in Seattle have a great sense of humor.

The only really “touristy” things I did in Portland were check out Vista House and some of the waterfalls in the Columbia River Gorge.   There’s a lot of forest and great hiking out there.  The only thing missing was sunny weather (which Seattle and Vancouver had no shortage of).

One thing I wish I’d done in at least one of the cities was some cycling.  Each one of them seemed quite bike friendly.

Now that I’ve spent a couple weeks in the Pacific Northwest, I can see why people are ditching California to move north.

I hate DTS

Posted on by Scott

I’ve spent a good chunk of this week trying to revise some DTS packages to account for changes in how MapQuest provides access to data they’ve geocoded for us. Since I haven’t used it in years, I’d forgotten how much I dislike the user interface for it. It probably didn’t help that I was trying to edit this things with a plug-in you install for SQL Server 2005.

Trying to have separate development and test environments to avoid the horrors of doing development and testing in a production environment is quite a trial also. I think you can put settings in a configuration file, but it’s probably something like an INI file.

It’s probably just as well that DTS was replaced by SSIS. I did use that to do a bit of flat file validation for the same project and didn’t find it nearly as painful to use.

Windows Software “Best Of” Lists

Posted on by Scott

Scott Hanselman updates this list every year.  I use 4 of his top-10 utilities on my work laptop (my personal machine is a Macbook Pro).  I use TestDriven.NET a lot as well.  If you use Windows, the list is definitely worth a look.

A number of the applications Hanselman refers to can be found at Open Source Windows.  It’s all really good software  with an even better price ($0.00).

Universal vs. Apple on DRM-free Music

Posted on by Scott

A very interesting take on Universal offering DRM-free music directly instead of through iTunes. I think the writer is on target in describing the motives of Universal in cutting Apple out as a distribution channel.

If memory serves, the big record companies tried to push Apple into variable pricing not long ago. That move didn’t seem to work, as the 99-cent single is alive and well on iTunes.

The idea of Apple signing artists directly is an interesting one, but I don’t see Apple signing artists anytime soon.  Artist management is quite far afield from what they do best. It might violate their recent deal with Apple Corps too. That said, if Apple could make it easier and cheaper for indie bands to put their music out without violating that deal, they’d probably make some money they aren’t currently getting.  It might even help them sell more iPods (which is really the whole point of iTunes anyway).

Improving developers

Posted on by Scott

Scott Hanselman posts a number of great tips for  improving development teams.  The technical brown bag idea is one we’ve been following at work since the spring.  We call them “learning lunches”, and they’ve proven to be an excellent vehicle for knowledge transfer, as well as connecting different offices of the company.

At my current employer and the previous one, I’ve tried to promote conferences, off-site training, and .NET user groups.  Getting the staff to attend them has been more of a challenge here than at my last job.  They’re all excellent ways of keeping technical skills sharp as well as networking opportunities.

Now that we have a new CIO at work, it will be interesting to see to what degree he’d buy in to some of these ideas.

To rewrite, or not to rewrite?

Posted on by Scott

This question comes up rather often in my job, and this post by Adam Turoff answers the question by including “when” as a variable.  In short, the sooner a project needs to succeed, the less likely it is that a rewrite will succeed.

Whenever I come across an application that isn’t designed or implemented as well as it should be, I’m biased in favor of rewriting the application.  That approach tends to meet resistance because the “when” is usually very short.  Refactoring is a good fallback option, but only if the application is relatively current.  My desire to refactor single-tier classic ASP is nil.

Leading by example

Posted on by Scott

I found this post on technical leadership particularly useful because it’s my role at work. Humility, discretion, tact, and willingness to “walk the walk” are necessary to succeed as a leader. The only thing I would add to the author’s list is the importance of patience in leading development staff. You can follow all the advice and still not see changes for awhile. I’ve been in that situation before, and always found it frustrating.

The comments on the post were enlightening as well, particularly this one by Greg Askew:

“Individuals are responsible for fixing themselves. Leading by example is a noble concept, but at the end of the day everyone is accountable for their own performance.”

The quote is a great reminder that as managers, we can only influence–not control–employees. Askew makes two other strong arguments about hiring and motivation. His latter point is echoed by Steven McConnell’s summary of classic mistakes and by Jim Collins in Good to Great. Undermining people’s motivation (and/or hiring people who aren’t self-motivated) can be counted on to yield a substandard result in the end.

The full article that inspired Jeff Atwood’s post is an excellent read as well.

No parameterless constructor defined for this object.

Posted on by Scott

This error message started showing up during testing of some code changes I made to an application.  It took me awhile to figure out precisely what the problem was because the top of the stack trace referred to this:

System.Activator.CreateInstance[T]()

As looked further down the stack trace, it ultimately pointed out which class was the culprit, so I added an empty public constructor to and redeployed the result.

I found this post rather useful in diagnosing the problem.