As I have been running various organizations I have detected a key trend that I think delivers a critical insight. I find that people who are open to have their perspective changed are able to adapt to our changing technology world much better than those that are not open to changing their mind. Most people listen only to information that supports their current views. This is intellectually lazy and a sure road to obsolescence in any fast moving environment.
I have always been eager to hear views contrary to my own and am excited at the prospect of someone overturning my world view. I do defend my current thinking vigorously so it is not easy to get me to come over to the other side of an issue, but it is possible.
Based on this, the best advice I can offer to anyone wishing to rise to the top of the IT field or any other is to allow others the chance to change your mind. Maybe you think Native Clients are overrated, or the Cloud is a passing fad, but you should actively seek those that challenge those views.
Category Archives: Software Dev
Disciplined Entrepreneurism
Recently I have had two of my most senior employees come to me seperately and suggest new products for the company to build. I encourage this of course, but find I have to help them understand some things about what I call Disciplined Entrepreneurism.
Ultimately when you decide to build a product for general sale you have three choices:
1. Invent something
2. Copy something
3. Enhance something
Each of these has its strengths and weaknesses. For #1 you have to really have a good idea and you have to bear the burden of educating the world they need something they never had before. In path #2 you have to make sure you can do it so much better that you can overtake the current vendors. And with #3 you build an add on to an existing product as part of its ecosystem, so that means your only customers are the people who bought the thing you are enhancing.
None of these is easy and none is a “sure thing”. I find that it is a slow road with luck and hard work playing equal roles in most cases. Misjudging the market is a common mistake, but not doing any market research ahead of time is by far the most common mistake.
Our head developer of our FSM product, Amr (he specifically asked me to mention him when I told him I planned to blog about this), throught that it might be a good idea for us to develop a Facebook Application. My response was to point out that Facebook, iPhone apps and other applications seem like a great way to get rich, but the failure rate is enormous
my research says that it costs tens of thousands of dollars to bring one to market successfully as very, very few make any money at all the average lose money if the idea is good enough then you have a better chance, but everyone thinks they have the killer idea. The costs go way up if you advertise it with some having spent as much as a million dollars. There really are no shortcuts to wealth
You should never just build an application. You should first figure out the odds of it actually making money otherwise you spend your life just writing code and never make any headway.
The key is to jump in before the market gets too saturated and to do some pragmatic thought about the potential of your product idea. Rather than look to Facebook or iPhone apps I think Windows Phone 7 applications is a much better landscape since there is still room for new players to make a mark. Just remember that you have to tamp down your wishful instincts…
Look at Azure Now / Again
If you looked into playing with Azure in the past, but did not jump in then it is time to take another look. Microsoft has added options over the last year that really remove objections to trying it out. If you have an MSDN subscription then you pretty much get a free playground in Azure that is going to waste if you don’t use it and if you don’t there is still the Introductory Special that goes through the end of March that gives you access to the basics of the service at no cost.
To look it over go to the Windows Azure Offers page at Microsoft.com and get going. You might not have a project that fits the Azure model currently, but you will. I am working on a new product for DTS that will have an Azure component and while it is still off in the horizon the time to jump in is before you are behind.
Good Advice – Setup Edition
My friend and collegue Adam Cogan is a big proponent of documenting best practices. In fact his company, SSW puts all kinds of lists of these best practices up on their website.
Recently Adam chimed in on a list we are both on with a link to the best practices (Rules) around setup and I realized that even if you know a topic well you should go back to the well from time to time to ensure you are still on the right path. I think back to the days when coding by stringing together user input to make a SQL statement was accepted as the way to build a login form (before the first SQL Injection attacks). You have to seek out other sources even (maybe especially) on things that you hold yourself to be an expert with. I now find myself reviewing how we do setups at DTS to make them better and finding Adam’s advice to be a very good source of points to contemplate.
SQL Myths – Must Read
Paul Randall has a compiled document with all his blog posts on SQL Myths that I think is a must read if you consider SQL Server part of your core competence. It is probably not very interesting to pure devs, but I would still suggest you take a scan of this so you can avoid making assumptions that are either out of date or just plain wrong.
Find the link to the PDF here: http://www.sqlskills.com/blogs/paul/CommonSQLServerMyths.pdf
Crisis Management
We have a saying in the various companies with which I associate and it is “Any fool can manage success, but it takes talent to manage a crisis”. The leader, project manager, team leader, or whatever you call the person in charge has to not be wishful. This sounds easy, but in my experience it is one of the hardest things to do for any individual. We tend to be hopeful and that is the slippery slope / gateway drug to wishfulness.
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…
In wielding power Apple has hurt itself
I have noticed a very interesting reaction recently to the way Apple has been throwing their weight around controlling who and what can be put in the appstore. Until a month or so ago there was a legion of companies and developers in my own circle, figuring out how they would enter the market and what they would develop, but that has changed dramatically in light of Apples series of what I consider large mistakes if not outright blunders. Pulling the storm trooper card on the guys that got the prototype phone, pulling the rug out from under Mono Touch, going to war with Adobe and also seeming to persecute all those that raise a voice in protest has put an enormous chill on most of those that I know that were looking to build applications for the iPhone and iPad. I own an iPhone and have bought an iPad so I am not a hater, just not a blind supplicant. I do not have any products launched or targeted to the AppStore (and have shelved those plans myself for the reasons many others I talk to are), so I really don’t see how I can be punished for speaking my mind (Sad that I now believe that if Apple had a way of punishing me, I now fully believe they would use it).
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…
Dangerous Interventions
It seems that everytime the government gets involved in high tech, things go wrong. Today I found out that there is a looming intervention that I think could potentially screw up one of the biggest successes in US based high tech, namely processor technology.
If you get time soon check out the petition here.
I would really like to see this kind of meddling prevented.
Usability is King
I have been working on commercial products for a long time and repeatedly have seen companies compete with similar solutions. Often one is the technology leader and innovates while the other plays catch up and only survives by clever marketing. Sometimes the laggard can become the market leader, but typically only if the innovator makes a mistake (the classic example of a market leader losing ground due to a mistake is when New Coke came out).
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.
Contracts 101
For many, many years I have been writing and reviewing contracts between my company and clients. As a result I have some insights into how things can be made to work more simply.
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.