Some cool controls for Silverlight 1.1 (2.0)

Telerik has a demo up of a control suite for Silverlight 1.1 (2.0). Some of the stuff looks pretty cool. It will be interesting to see what the final release of Silverlight 2.0 contains “out of the box” as well.

Transitions

So, today I am moving on from Whitehill Technologies (now Skywire Software). I do so with many mixed feelings. When I look back on what I have achieved here, many things stand out. Helping to grow the company to the point where it became a meaningful acquisition target I think is a tremendous accomplishment. We have also developed a great deal of very cool software, and more importantly, software for which real people were willing to pay real money. To have accomplished this from Moncton, New Brunswick, Canada, is a great demonstration of what we can achieve in this region, and is something which I hope to repeat in the future.

The most important aspect of the journey, though, is the people. Having spent the better part of 9 years here, I can honestly say that there are very, very few people I have known here with whom I would not eagerly work again. I would also like to think that I have contributed to the growth of many developers (and other staff). When I joined Whitehill, the development team was very young. Most had only a couple of years of experience. It is extremely gratifying to me to see what has grown out of that team – people who have become technical leaders, managers, and all-around leaders. I cannot express the respect I have for what this group has become. I like to think that I contributed in some way to that growth.

Looking back, there are many people who stand out. I miss the early days with Bob, and Bonzo, and the excitement of working with a small, tight team. Then, of course, there was the winter in a construction trailer in the parking lot with 8 other guys, porting Transport to Java.

There are too many people to list all of them here. First and foremost, I want to thank Steve Palmer. Steve has always been the epitome of professionalism, respectfulness, and generally “doing the right thing”, and I consider Steve to have been an important mentor to me. Among the early developers, Shawn Hogan, who had leadership written all over him 8 years ago, has fulfilled that potential and more. Jerome Sabourin, Greg Clouston, Andrew Sharpe, Anita Richard, Rob Stote and too many others to mention. I am very proud of, and have the utmost respect for, all of you.

It has certainly been an interesting ride.

All of you, take care. I look forward to seeing and working with you all some day in the future.

Business life lesson – Don’t let anyone steal your dream : Atlantic Canada’s Small Business Blog – IQI Strategic Management Inc.

This is an interesting post, and fits in well with other things which have been on my mind lately, and with things about which I have posted.

It occurs to me that over the years, I really have let the world steal my dreams. I think we all do this – we get so wrapped up in the day-to-day “operations” of life that we lose track of the grand visions. We also tend to be told that we need to think realistically, and be reasonable, and play it safe. We spend much of our lives being taught what is possible, and even worse, what is impossible. I think that is why so much advancement in science, arts, and other fields comes from the young, because they have not yet learned that what they are trying to do is “impossible”.

One of the nice things about a grand vision is that you spend much less time worrying about whether it is possible of not, and more time just working towards it.

Flying the friendlier skies? Delta gives air etiquette tips – CNN.com

This is kind of ironic, given that the biggest source of “poor etiquette” is the treatment of CUSTOMERS by the airline industry itself.

Getting excited about the future

I have been through a complex time mentally over the last few months, with the changes here at Whitehill (now Skywire), and with my own transition within (and ultimately out of) the organization.

It is now time to face fully forward, and I am doing so right now with more excitement than I have had in a long time.

For the past number of months, I have been looking at a lot of options as to what to do next (as described in a previous post), and while there have been many ideas floating around, I have had a hard time getting truly fired up by any of them. Part of it was just inertia and fear of change. But a big part of it has been my own thinking. I have become extremely conservative (in some ways – not politically) as I have gotten older. So, much of my planning has centred around conservative ideas, or at most conservative approaches to more exciting ideas.

It is, unfortunately, very difficult to get fired up or inspired about playing it safe. That does not mean I am going to go off and do things without due consideration, or take unnecessary or ill-conceived risks. What it does mean is that I am going to follow a path which has been successful for me at previous times in my life – follow the big dream. In addition, have fun doing it. The dream itself is not the main goal, it is the act of chasing the dream and enjoying the path.

I have been searching for great words to express what I want to do next, and have finally found them in a cartoon of all places:

Pinky: “Gee Brain, what do you want to do tonight?”
The Brain: “The same thing we do every night, Pinky—Try to take over the world.”

So, that is what’s next for me – try to take over the world, or at least some interesting piece of it.

Stay tuned – this is going to be fun!

PS – here are the immortal words of Pinky and the Brain in their original form:

Confessions of an airline executive – CNN.com

This is an interesting article. unfortunately it does not address the main outstanding question I have – why does the airline industry (and this includes not just the airlines, but the airport authorities, government agencies and all others involved in this continuously worsening mess) believe that it is acceptable to provide atrocious customer service, disrespect their customers, and generally perform badly in all aspects of their operations, and yet feel they should stay in business. Quite honestly, most business that were run this badly would be dead in months.

As a side note, a couple of weeks ago I had written a post (more of a rant than a post) about my recent experiences flying. I saved it, but did not post it, as I was not online (I was on a plane). Unfortunately it seemed to disappear from my saved drafts. I took this a s I sign that I should not post it! To summarize, though, I was on my 4th trip in two weeks – one to Toronto, and three to other endpoints, but going through Toronto. So, a total of 14 flights. The “on time” performance on these 14 flights was somewhat less than 50% (and this is considering anything within an hour of on time as “on time”). What was disturbing to me was that none of the delays were due to whether, air traffic congestion, or any cause “outside of the airline’s control”. In all cases, the cause airline mismanagement. For example, 2 cases of “the plane is not working”, because the flight segments between Toronto and Moncton are all crappy, old, small planes. Another case, we could not leave Moncton because the incoming plane from Toronto had not arrived. Why? Because no ground crew had been assigned in Toronto to the departure gate, and so they could not load the plane. Yet another case, we sat on the plane for 45 minutes after having landed at Toronto because no ground crew was available at our gate (what, they were not expecting us?).

All of this reflects the fact that this airline (and almost all others with whom I have travelled in the last 5 years) accept that lousy service and disrespect for passengers and their time should be the norm. And they will continue to think this way as long as it costs them more to fix the problem than accept it.

So, how do we make it cost them more to be incompetent? Well, how about every time they are late due to their own incompetence, everyone on the flight gets a partial refund. Say, $50/half hour delay? Make it cost them money, and they will fix the problem.

Of course, this will only partially address the problem, since we still have to deal with airports, security, and other aspects of the experience which are designed without any consideration for the customer.

Fred’s Law #2: Requirements, we need lots of them!

As I have already said, doing away with requirements altogether is a really, really good way to ensure that your project will fail in a spectacular way.

Another really good approach to being bad is to try to capture every possible requirement that anyone might ever want, ever. There are a number of advantages to this approach as compared to the “no requirements approach:

You can create the illusion that you really know what you are doing
You look like you are being extremely diligent
You always look like you are extremely busy
You create huge amounts of documentation to support the illusion that you have been both busy and diligent

Unfortunately, you may never actually get to the end of the requirements gathering process. If you do, you will probably either have missed the window of opportunity on whatever you wanted to build, or you will have produced a set of requirements so convoluted that no one will ever implement them.

On the upside, you will have greatly reduced the risk of the actual development failing, since you probably will never get there. You will save huge amounts of money on developers, as well as computers and tools for them.

So you never actually have a product to sell, or software to use. You will have done your job well, it will not look as though your project actually failed, and it will look great on your resume as you look for a new job.

Share this post :

CANOE — CNEWS – Canada: Kids book removed from schools

This article is interesting to me, but not so much because of parents concerns leading to the book being pull from shelves. I mean, the entire point of religious schools (Catholic or otherwise) is to shelter kids from content they feel is “non-whatever-religion-they-follow”. What I find comical is the last line:

“…by British author Philip Pullman, an admitted atheist.”

An admitted atheist?!?!?!

The writer makes it sound like it is some sort of crime or deviant mental state, like an “admitted axe murderer” or an “admitted child molester”.

Atheism is a valid belief (not a lack of belief, as some would try to imply). Would any journalist worth reading say someone was an “admitted Catholic”? or an “admitted Jew”? Would they get away with saying it?

(December 20, 2009: note that the above link is broken – Canoe.ca does not seem to have maintained the article)

Share this post :

Fred’s Laws #1: Requirements, who needs ’em?

Well, I guess it is fitting to start out Fred’s Laws at the beginning of the process – with requirements.

If you really want to start of on the right foot, and get your project well on its way to a spectacular flame out, this is a fantastic place to start. Remember, the best way to figure out what your software needs to do, how it should do it, and what it should look like, is to get your coders right in there coding. After all, who knows what the user wants better than coders?

This is especially true if you are building something new and innovative, or if you are short on resources or time. Just think of all the time you will save by not having to talk to users up front. And, all those resources you would have wasted talking to users can be redirected to more important things like coding (whether they know how to code or not). Just imagine how far ahead of schedule you will be right from the beginning!

Now, estimation and scheduling may be a challenge without some definition of what you are building, but you probably will not be doing any real estimation or scheduling anyway (see later laws). If you need to have estimates and schedules to show to management, you can always make something up out of thin air (but make sure not to talk to your developers about it!).

(and just think how much time you will save talking to users later on, since you won’t have any!)

To be really specific, make sure you avoid any of the following activities, which are known risk factors which could lead to success:

Set up a system for capturing requirements, using Access, Excel, file cards, or any other tools
Establish a process to review and prioritize requirements, and assess their value versus cost
Define a process for managing changes to requirements
Involve users or user representatives in the creation and/or review of requirements

All in all, avoiding requirements definition should save a great deal of time up front, and allow you to focus on the important work of trying salvage your failing project.

Share this post :

Fred’s Laws (again)

Some time back (late September) I promised a series of posts on what I term “Fred’s Laws”, a set of rules you can follow if you are determined to have your software development project fail miserably.

Back in September, I promised I was going to post a law per day until I ran out of things to say. That lasted, well, zero days :-). For various reasons I felt it prudent to delay posting these for a couple of months.

The laws I am going to post are in no particular order in terms their impact. I am not sure how many of these laws there will be, and I am not even sure that they will not end up being self-contradictory.

(hey, I am doing this like a typical software project!)

I think the laws will fall into a few main categories:

Requirements
Project planning and tracking
Process, methodology, blah, blah, blah
Working with management
Working with marketing
Quality, testing, etc.
Technology and tools

Something to keep in mind here is that I am a big fan of process in software development. Not of big, heavy processes, but of some process. If you are going to go from A to B, you have to follow some process to get there. There is value in having some level of predictability and repeatability in that path. You may vary the path with the circumstances, but you should at least know what path you are improvising around.

Also, I do not believe that there are any rules which you can follow which will guarantee perfection in you software development efforts (at least not if you are building anything interesting). All of the rules, and process, and other magic spells can do is to improve your probability of success, and allow you to see when you are heading down the path of failure, allowing you to make some intelligent decisions along the way.

On the other hands, the are a few rules you can follow which can almost guarantee that your project will fail. Combine a few of them together, and you can make your failure truly spectacular. Stay tuned…

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: