Places To Go
News and Reviews....
People To See
Places To Go
Sunday, February 27, 2011
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...
Tuesday, February 15, 2011
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.
Thursday, December 30, 2010
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.
Monday, December 20, 2010
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
Friday, December 17, 2010
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...
Wednesday, June 02, 2010
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...
Wednesday, December 09, 2009
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.
Saturday, November 28, 2009
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.
Monday, November 16, 2009
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.
Thursday, November 12, 2009
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...
Monday, September 28, 2009
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!
Tuesday, July 28, 2009
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.
Wednesday, April 22, 2009
My favorite interviewers Carl Franklin and Richard Campbell invited me to appear again on .Net Rocks
recently. We talked at length about the circumstances that we often see that cause technical projects in particular to fail.
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
Monday, April 13, 2009
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.
Friday, March 27, 2009
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...
Thursday, September 18, 2008
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...
Tuesday, March 11, 2008
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 ;)
Monday, May 21, 2007
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
Monday, November 06, 2006
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.
Thursday, October 05, 2006
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...
Monday, June 19, 2006
When you are working on commercial software or even just industrial strength business software you have to balance things. Time to market is everything and while you must have usable, quality code, you have to get it done.
One of the things that is hardest to balance is performance tuning, it is often best to put the lion's share on hold until version 1.x or even 2.0.
Most software companies to not invest heavily in performance tuning in the first version of a product since it usually requires alot of work and often customer reactions will force you to make changes that might invalidate the tuning anyways.
You should certainly consider doing serious performance tuning if the feedback from QA is that your software is too slow under load to give to a customer, but that is just common sense.