I think this is an example of Absolute Power Corrupts Absolutely. If you grip power too tightly you lose it and unless the groupies really do outnumber the rest of us this is a dangerous way for Apple to do business. How can we trust developing on a platform where the rules seem to change on a whim and which is controlled by those whose friends are treated no better than enemies...

When it comes to software products the rule is pretty simple, mistakes in usability are the ones that cost marketshare fastest. Customers are pretty tolerant of technical issues and bugs since all sofware has them, but if the user feels stupid when trying to use your product, they will switch very quickly to an alternative.

Bottom line is that mistakes of ususability are more costly in a competitive market than almost anything else, design wisely.

First up, this is not legal advice, just me sharing some experiences. You should always run your contracts by your lawyer to ensure you aren't painting yourself into a corner you did not intend.

Second, I have always tried to standardize contracts as much as possible and educate prospective clients up front as to what our process was for setting up contracts. Often the client will have their own ideas and their own contracts, but life is much better if you get the majority of clients to use your system rather than having to make a project out of every deal. I find that the more reasonable my process and contracts the more likely the client will accept my contracts rather than insist on using their own.

Third, you must always remember that contracts are to govern the relationship between you and the customer when things to wrong. They almost never come up when the project comes off to mutual satisfaction. They are insurance if done well and they are a death sentence if they are done badly in cases where the project goes off the rails.

Fourth, contracts are not personal, they are just part of business. If you are doing business with someone you like and trust then there is a temptation to skip on the contractual completeness or correctness. THIS IS A MISTAKE! Always think in terms of what would happen if the project went sideways and the person you had to deal with was not the one with whom you set things up. This has happened to me on a regular basis and the only defense is to have solid contracts.

I hope to post more information like this in the future.

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...

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!

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.

Initial feedback has been quite positive so if you happen to listen to it I hope you like it as well. This particular episode is found here

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.

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...

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.

Having been involved in many software projects, some commercial, some consulting, some disasterous, I have noticed some trends that I would like to share.

If you are commissioning (read paying or betting your job) a development project, you have to avoid being wishful.  If you just trust that the developers you hired are professionals and will keep you out of trouble it might actually happen that way, but you are playing Russian Roulette.  Even some of the best developers get overtaxed or lazy or stupid or all of these things at once.  If you don't get very explicit in what you want you will pay for it. 

To avoid some of this I recommend that you:
 - Specify the system in as much detail as possible
 - Provide statements relative to how the system will be used and the intent of the project
 - Emphasis should be placed on what YOU define to be acceptable.  Define terms up front such as "commercial quality" and "easy to use"

The less you leave up to the imagination the better.  Also insist on frequent demos throughout the process with opt out options if things are just too off track.

Always remember that consulting is based on who takes the risk.  In a fixed bid engagement the developer takes most of the risk and therefore the price is uplifted accordingly.  In a time and materials engagement it is the buyer who takes all the risk and often it is the buyer who must ensure things are proceeding according to plan.

In the end it is the specification that will decide if the developers did their job or not...