Category Archives: Software Dev

Development, Management, Software Dev

Bugs are in the eyes of the beholder

As I work to build commercial software products I am regularly forced to remember that bug is a relative term. That sounds like a weasely way to explain away a fault in your software, but it really does turn out to be true especially when you have been on the ISV side of the conversation.


Back in August Steven Sinofsky posted a very insider view of how the Windows 7 team triaged bug reports on the Windows 7 Engineering blog. Microsoft products enjoy (a mixed blessing) more previewing eyes and shared opinions than most everyone. The bottom line you have to understand to put these things in perspective is that the creator of the software is on the hook for supporting, maintaining, justifying and profiting from their product. While the customer is always right about what they want, they aren’t always right in their belief of how my product should work.

Case in point. I have worked with and for ISVs for more than a decade now and I have seen time and again the process of a potential or current customer insisting that a feature must be added or a functionality changed. Not always, but often when the ISV has caved and added a feature that they did not feel would add value the negative feedback drowned out the voices that were asking for it.

In software development for commercial use you have to follow the advice of the song lyrics sometimes, namely “If you can’t please everyone, then you’ve got to please yourself”.


Ultimately if your product fails you can’t blame a customer or even a group of them for demanding things that ultimately took you off mission. Each customer complaint or feature request is a gift (as the book title goes), but it is not always one that you should embrace. This also goes for resellers, sales staff, developers and everyone else who is not on the blame line for the acceptance of the product by the market. That responsibility falls on the product owner who is often the business owner and visonary, or in cases like Microsoft a senior manager or executive.


If everyone remembered this we would probably have better software overall…

Software Dev

Product Key Rules

1 Comment

Lately I have been working on developing a new product key system and realized that one of the core rules of the road is not documented anywhere I can find (which is crazy in this day and age when everything is supposed to have already been said).


The rule is pretty simple once you think of it. You should never include the numbers 0 or 1 or the letters L, O or I in a license key that you require users to ever type. The reason is that there is too much chance of confusion that will cause the key to fail. Zero looks like the letter “O”, lower case “L” looks like 1 and upper case “I” in many fonts.

A simple set of rules, but ignored way too often. The only exception and I think it should be used sparingly is when the key is all numberics since that should remove the ambiguity provided you clearly state that the key is all numeric.


Random ramblings perhaps, but it will save you down the road on customer support calls and that means money!

security, Software Dev

ATL Security Vulnerability

2 Comments

Microsoft has just announced that there are security flaws in the Active Template Library (ATL). While many developers will think that this only applies to C programmers and while to some extent they are correct I think it is important to take a lesson from this issue. Micheal Howard has posted a very informative post to the MSDN Security blog that I think is well worth the read for all developers (not just C and C++ programmers).

Too many organizations think that they can ignore code once it has been written, but the price of secure code (like freedom) is constant vigilance.

Management, Software Dev

Who decides the roadmap for commercial software

Most of the people I know feel uniquely qualified to say how a particular commercial software product should work based on their experiences of using it. It doesn’t matter which product you pick, it is always the same. The problem with this is that it is almost impossible for an individual to be objective about whether their use of a product is mainstream or even typical. The consequence is that listening to the advice of all your customers is a good idea, but you have to pick and choose which suggestions you actually implement as part of your roadmap.


Ultimately it is the vendor that decides what they will offer. The customer often gets confused about who is steering the boat. So I respect and completely understand the position that a commercial software vendor has the right to decide that some complained about aspect of the product is “as designed” if they believe it is not important to their plans for the product. The other side of this coin is that it is your customers that decide if you have run the boat onto the rocks or not. And they tend to vote with their feet.


The best course is to always get as much feedback from your user community as possible and pick through that information objectively. One great question is whether the customer would pay more for the product if it had their proposed feature, character or ability. If the answer is no then that should tell you something.

Management, Software Dev, Speaking

NH Code Camp Presentations

4 Comments

I promised to upload my presentations from last month’s New Hampshire Code Camp so here they are…

I delivered the keynote address for the event covering how to survive as a developer in this depressed economy.

NH Code Camp Feb 2009 Keynote.ppt (592.5 KB)

I also got to debut a new session on How to prevent project failure and a follow on called Project Specification for Survival and Profit. The reviews on that second session have caused me to combine them a bit and create what I think is a single, better session that I am going to be presenting at the Boston Code Camp tomorrow.

How to prevent project failure v1.ppt (559.5 KB)

Project Specification for Survival and Profit v1.ppt (464 KB)

Sorry for the delay in posting, lots of travel lately, but that is not unusual for me…

Development, Software Dev

Code Optimization when speed is not the only goal…

9 Comments

I have worked on many software development projects, both commercial and line of business and every single time I talk about optimization to a developer they always jump to the same conclusion. They think I mean speed of execution. I grant that the majority of the time when people talk about optimization that is what they mean, but it is not 100% of the time correct. Often I care more about the maintainability of an application especially if I know it is destined (or doomed) to morph quite a bit over the next year or so. In these case it is often an application that will be used by employees and many of the standard assumptions do not apply.
Take our Intranet for instance. It is only used by employees and our closest contractors. We use it for tracking customers and projects, for forecasting sales and even timesheets. I don’t care if it is 5% slower, I want it to be adaptable since we are an agile company. I don’t mess with the code every week or even every quarter, but the code is written in such a way that I or any other developer on staff can go in and very quickly add a field or add other features very quickly. We didn’t sacrifice security (that would be unacceptable), but we did forgo the multi tier architechure and stored procedures for parameterized queries. This is a sin in many circles, but if the application’s backend is single use (only one application) then there is much less advantage to all the abstraction. I am sure the arguments will flow down on me now, but I see the same drive for complexity without purpose (real advantage I mean) in the Java world where code portability is everything and yet almost no one ever avails themselves of that costly feature.

The next time someone asks you to optimize something ask them if they mean for performance or maintainability and let the funny stares begin…

Development, Software Dev

Technology Reinvented (or Recycled)…

1 Comment

Every few years I find that there are pieces (sometimes big ones) that I have not played with or encounted on a customer project and it tends to freak me out a bit. We have now arrived at that point in the cycle yet again! Expression, SilverLight, WPF and the like are all technologies that you will likely never see me present upon, but in the aftermath of MIX 08 and whole WideOpen Web movement I just have to dive in deeper and see what the implications are for the parts of the technology that I do use daily.
I think this is a key survival trait for me and I encourage everyone to reach down into that free time (you are still sleeping right?) and get a grip. The good news is that great blogs and podcasts are making this much easier then ten years ago. I promise to report what I find here and might even ask a non-rhetorical question or two ;)

Development, Management, Network, Software Dev, Web Hosting

Big boost for ASP.Net scalability

10 Comments

StrangeLoop has finally announced their AppScaler device!

Richard Campbell told me about his involvement in StrangeLoop a while ago and I have been dying to tell people about it, but until now it has been confidential.

Basically the AppScaler takes a web farms major headaches and lifts them into the loadbalancer and out of the way of your developers.  It really is a cool strategy because it gives sites real performance gains over hosting Session State on a state server or in a database along with a whole host of other performance enhancing and bandwidth saving features.

Check out the recent article at NetWorkWorld.com about it.

security, Software Dev

Preventing Software Piracy

3 Comments

Chad Hower is a smart guy and I came across his post on protecting the software you write from pirates right at a time that we were revisting the question ourselves.

On the whole I agree with Chad, while he comes off as against anti-piracy in the beginning of the post, in the end you realize that he is just advocating for a measured response.  I couldn’t agree more.

This is very much the whole, “In order to save the village we had to destroy it lesson” where you get very diminishing returns if you go too far off the deep end in trying to make your code pirate proof.