This morning Richard tweeted "Four things to write this weekend... is it wrong to do them in the order of how much they pay?". This got me thinking about my own task juggling over the years. When I was in college I learned that there are times that you have more to do than can humanly be done. This was in fact a central part of the pressure West Point put on us while we were cadets there. To cope I came to the conclusion that the juggling metaphor is quite apt. The thing to realize is that not all balls (tasks) are created equal. Some are made of rubber and some are made of glass. Rubber balls bounce and you recover even if you let them drop from time to time. Glass balls shatter if you drop them even once. The key is to identify which kind of ball a task represents and there lies the rub.

We see the same decision points when we undertake software development. I try to tell people over and over that security is a task of glass.

For the record, I think Richard has his priorities correct all things being equal...

The reason I say this is that my own biggest screw ups are almost all tracable to some point in the past where I assumed that something would happen more positively than it actually did. This sounds like the classic admonishment against assumption and to some extent it is, but wishful is more of the root cause and assumption the symptom.

As an infantry platoon leader in Iraq many years ago, I learned that you are never done planning for and defending against the things that can go wrong. When you envision contact with the enemy it is easy to expect that things will follow the simplest route and flow like water, but since there are humans involved this is highly unlikely to be the case. You might even get lucky and survive this way once or even twice, but that just means you are more likely to get killed when your luck runs out. I try to run projects the same way. What if the components that should work fine together don't? What if the client changes the deployment server to run a 64 bit OS instead of the 32 bit OS on the test server? What if there is an illness or death in the family of my key developer the week before delivery? You can drive yourself crazy with these things and I am here to say that you should. That is the job.

The first place to start is by making plans and schedules with milestones. If you are collaborating with others it flushes out wide variations in viewpoint quickly. Either I accept your timeline or propose another (assuming I am not totally whacked). If I propose another you might discover that it just won't work early enough to do something about it. I have seen good resources fail to deliver items well within their ability due to time wasted assuming everyone has the same, sane view of what needs to be done by when.

And to top it all off if you follow this advice and try to plan for all possible outcomes, there will still be surprises and things that you did not count on which is good because otherwise we could write a program to replace your part in the show...

There are of couse many, many ways to look at it, but I think I have found the single most important strength not just for technical talent. So take this as advice for your own advancement or as the thing to look for and test for when you are hiring. The key strength is to be able to accept feedback and objectively recognize it for truth when it is true and then have the strength of character to actually try to work to improve as a response.

It sounds easy, but it is not. It is also very much at odds with being an ego maniac (in other words those people can't do it). If someone passes this test then the sky is truly the limit, they will be able to improve, move up the ladders of responsiblity and will likley only be limited by the strength of their intellect.

Try it yourself sometime by asking someone for honest feedback and see if you can act on it. Repeat.

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 quote is, "three things - autonomy, complexity and a connection between effort and reward - are, most pople agree, the three qualities that work has to have if it is to be satisfying." I found myself rereading that passage because it sums up so well my experience in working in technology. I have to add that I also found these qualities in my time as an Infantry Officer in the Army. If you are searching for work try to communicate that you want these things to the person doing your interviews. I want this kind of person working for me, but I find that often some of these qualities turn out to be a wish that many regret once fulfilled.

Lets start with Autonomy. I chose the Army rather than the Navy or Air Force precisely because I wanted to have a hand in my fate. A Navy officer in combat dies based on where the ship is sailed by the captain. Twenty yards one way or another on deck rarely matters when the ship is sinking. You can find the same analogy for the Air Force where you life is hanging by the performance of a piece of high tech gear working against gravity. As an Infantry Officer I could choose my path within hundreds of meters most times and the mistake of stepping on a mine was mine to make. Often people get autonomy and then squander it. Autonomy is a form of trust. Can you work at home in your job? If so it is probably because you either work for yourself or your employer trusts you very much.

Complexity in tasks it welcome, especially to technical people. We like a challenge because there is accomplishment in resolving it. The hazard here is to mistake a job with complexity as a license to behave arrogantly and to feel entitled. If you work for a company and make a fair wage by any objective standard (not just your own) then you are unlikely to ever be considered to be given a share in the company. That is reserved to those who take the risk of starting the company and those who negotiate for that right at the right opportunity (which rarely arises).

A connection between effort and reward is the easiest to understand and represents the point where employers should take the most note. If you have two people working for you of equal ability and one works like a dog while the other skates, your treatment of them will be instructive to both. Praise only goes so far and eventually becomes hollow if there is no material benefit included (even if only occasionally).

I like this book very much and recommend it to anyone who wants to conquer the world, but with one caution. It does not sugar coat what it takes to accomplish outstanding success and that means that your long standing beliefs, some of which are likely comforting, will probably be changed fundamentally. I always preferred hard and useful truth to comforting fables anyways...

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.

The subject of the email was the same as this post (Virus Prevention Advice and Policy) and below is the text:

It is that time again and we are starting to see warnings about worms and viruses passed along by friends and family so I wanted to take this opportunity to remind everyone of how we keep our own network safe and free of these destructive monsters.

Some rules of the road for using company email and company computers:

1. If you did not expect it then don't click on anything in it. This general rule will help you deal correctly with most emails and web pages. If you go to a site expecting to download something be sure that you are on the correct site (many common typos of URLs host malicous copies of the popular site). If your brother sends you a message called, "Kids latest pictures" and it was not something you expected, do not click on links or attachments until you have verified that it was indeed sent by him. Our last major virus here at the company was the result of just such a message being clicked on by an employee who did in fact get pictures from her brother quite often, but this time it was a virus that was sent by her brother's computer instead. It took us 2 days to clean up the mess. A better policy is to only open personal email attachments at home while you are not connected to our network.

2. Be paranoid, but try not to be crazy. If you get an email from yourself that is some form of spam then welcome to the club. We can't stop the spammer in Asia from using your email address to send the world spam and if you use the address long enough it will certainly happen that you and others you know will get spam that looks like you sent it. It will pass, but we can't fix it. See rule #1 as this fact should also make you more cautious of anything you get that you didn't expect even if you converse with the user often.

3. A great many viruses and malware are picked up by browsing the web. Visiting site like Youtube.com and MySpace.com is often a bad idea unless you know exactly what you are doing, why and accept the consequences if the result is 2 days of lost time to the company.

4. There is a reason you can't install things on your computer. We limit what the average user can install on their computer so that if a mistake is made, it is less likely to have a lasting effect on our network. In most cases, if it isn't already installed on your computer you don't need it. There are exceptions, but be sure you have a cogent argument for why you need Software X on your work PC. We also use specific version of MS Office products as a hedge against system outages. We do pay attention to the newest versions and will upgrade when the time is right, but no sooner. If there are business reasons why you need a specific version of something please let me know and we can make a business decision.

5. Keep up the good work. We have an amazing track record here for having staff that do the right thing. Most companies get hit by a virus once a quarter or more and we are typcially only seeing an event every other year. This is in spite of the fact that we do not block sites or regularly check browsing logs to police what people are doing. My only caution on this point is that while we all enjoy this open environment it is dependent on our continued vigilence.

If you have any questions please feel free to contact me or anyone else on the technical staff and we will be happy to help you navigate the mean streets of the Internet.

Thanks Patrick

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

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