Month: June 2007

Unlocking Value at Microsoft

Posted on by Scott

I came across this article, via a post from Mini-Microsoft. I wouldn’t necessarily expect a software product manager to be able to write code. I would expect them to be more technology-savvy than this guy appears to be. Whether he was trying to be funny or not, this will certainly add more fuel to the fire for the legion of MBA-haters that already exist.

While I’m not a Microsoft employee, I have my doubts that he’ll be successful in his role without a better understanding of the technology. As someone who has a computer science degree and an MBA, I’ve found that the combination gives me an advantage in explaining technology choices in business terms. The other thing working against him is his product. The vast majority of individuals and corporations that own copies of Office only use a fraction of the functionality available in the older versions of the suite. Getting any company to pay more for a newer version of something that already meets their needs sounds like an impossible task to me.

VSS Shadow Folders

Posted on by Scott

We still use Visual SourceSafe at my job for version control.  I inherited the administrative duties (for one VSS database and a TFS installation) after one of my colleagues left to join a startup.  We found a legitimate need for its “shadow folders” functionality not long ago, and finally implemented them this morning.  I came across this page when figuring out the particulars.

Guiding principles for developers

Posted on by Scott

This list comes courtesy of Patrick Cauldwell, an architect at Corillian Corp.  I’m definitely in favor of most of their list, especially test-driven development, continuous integration, and buy vs. build.  I’m not so sure about the Windows authentication point simply because it takes so much effort to get developers access to our databases at work.

Slimming down the FxCop rule set

Posted on by Scott

I asked a group of consultants currently working in my office for advice on which FxCop rules were actually applicable to our environment.  One particularly useful piece of advice was to consider whether or not unknown people or applications would be using what I’d written.  It allowed me to disable the following rules:

  • Mark assemblies with CLSCompliant.  Since there won’t be any third-party users of the assemblies I ran FxCop on, that rule can go away.
  • Mark assemblies with ComVisible.  The same argument as above applies to this rule.
  • Assemblies should have valid strong names.  Once we get certificates, we would reactivate this rule.

I’ll revisit the list periodically to make changes as I improve my understanding.

Safari on Windows

Posted on by Scott

I’m trying it out on my laptop at work to see how I like it (I’m all Mac at home now). In regular use, the speed advantage Safari is supposed to have over Firefox isn’t really noticeable. Most sites I visit render correctly, except for the occasional message in Yahoo! Mail. It has the sort of problems I’d expect rendering ASP.NET web controls, but so does any browser that isn’t IE.

At least for now, I wouldn’t ditch Firefox for it. I might use it more on my Macs though.

Use code coverage

Posted on by Scott

Eric Sink wrote this post in favor of code coverage.  I wasn’t terribly familiar with the concept before two years ago, and my current job is the first one where I’ve seen such tools used seriously.

The best applications our organization puts out (correctness, performance, ease of maintenance) are the ones that have unit tests.  The application I have the most confidence in though, is the one that has code coverage.

I’m trying to develop that habit for the code I write, so I can be a better example to the team I manage.

Requirements

Posted on by Scott

Eric Sink’s post on requirements is the best and most concise treatment of the subject I’ve read yet.  The document vs. database treatment of requirements and his comparison of traceability to a compiler are inspired.  He even touches briefly on the shortcomings of bug-tracking systems as requirements management systems.

I haven’t read the book he recommends in his post (Software Requirements, by Karl Wiegers), but I have no doubt that it’s good.  The book on requirements that I can vouch for is Exploring Requirements: Quality Before Design.  It has tons of great advice on the process of gathering requirements.
If you analyze, design, build, and/or test software, read Eric Sink’s post.  If you manage technology projects, you should definitely read it.  Highly, highly recommended.