Do you use pre-release software to develop commercial products?

Question

So the question is.. have you used a pre-release product or technology (a Community Technology Preview, Beta or Release Candidate, etc) to develop your own product with?

For example, you might have developed a website using Microsoft's ASP.Net MVC (which just went RTM yesterday) or built software against SQL Server 2008 RC 1..etc

If so..

1. What steps do you (or did you) take to minimise the risk of problems occuring when the pre-release product is properly released?

2. Do you wait a specific timeframe (until a product is a Release Candidate, for example) before working with a product?

3. What would be the main advantages (vs. risk) of working with pre-release technologies?

Answer 1

Unless I really need something, I tend to wait until things have been tested by the wider market before tackling jobs with them. I don't just adopt new stuff for the sake of it. It's down to the number of eyes I want to have seen it before I work with it.

There are enough challenges in designing/developing systems for me without having to trailblaze the infrastructure.

Obviously, if a client is adopting an early technology release then my hand is forced.

Answer 2

As a rule of thumb I never use such unstable components in production software.

If u need quality you should build on strong basis.

I know that many big software companies don't use new components and technologies until they get mature enough - just to stay on the safe side.

It all depends on the risk U are willing to accept.

Answer 3

I don't.

Typically I wait till Service Pack 1 before I begin to use a product for commercial purposes.

I've found that the in the odd occasions where I have broken this rule, it's ended up creating alot of unnecessary stress and pressure on developers to resolve issues.

Answer 4

Practically all successful software projects I've ever been on have been released (erm, published - web sites) with a fair amount of betas in use.

We mainly evaluate the test-coverage of these (mostly open source projects) and the previous track record for not doing stupid things.

Any old beta will do as long as it does what we need ;) But usually we stay off the immediate snapshots after major rewrites.

These days we're test driven, so we know if our stuff works. If the libraries have bugs we stay with an older version or fix the bugs. We can also assess immediately if an update has serious bugs in it, because it will break our own tests. So using "unfinished" software is really not a big deal any more. Access to the latest features is always the reason, sometimes we do it to get important fixes.

Answer 5

it depends upon how much you believe in that software - basically is it going to solve your user's problems more efficiently than your current software does. so when asp.net 2.0 was first previewed, we embraced it immediately (because we thought its a huge improvement over asp.net 1.1)

but not so for asp.net mvc. now if we do decide to adopt preview software below are my answers for your 3 questions:

regarding your first point - the kind of advancements you got these days with IDEs - there is very little risk as far as code breaking with the final version is concerned. and these companies do a very good job about informing well in advance about the changes. greater risk is about - whether that technology is going to be adopted by the masses, would your client be willing to shell out that extra buck for it.

regarding your second point - no, if we feel strongly about a new release, then the moment it is up, we start researching on it to have that extra edge.

regarding your third point -

advantage - if the software is a problem solver at an affordable cost - then you have hit jackpot as an early adopter. you can charge more for those skills as obviously there would be less supply and more demand

risk - if the software is not embraced by the masses - your time and money invested goes down the drain ;-)

Answer 6

Sometimes we need to if it has a bug fix or performance improvements. If the FAE (Field Application Engineer) says it is stable, I'm willing to try it.

Answer 7

For me, it is all about the time it takes to get the product out the door. I am working in Silverlight, for instance. Some of the features that will be available in SL3 are necessary for the next version of our software. If we want to release really quickly after SL3 becomes RTW, then we NEED to be developing against the beta. We can't wait that long.

Answer 8

It depends on the situation. On a previous job, we used ADO.NET Entity Framework while it was still in beta. We tested the beta thoroughly, and we were using automated unit tests and code coverage analysis to make sure we were being thorough. The beta passed our tests.

This turned out to be a good move. It saved us the three-month wait for the final release, and it only took a few hours to fix the breaking changes between the beta and the release versions.

What I would not use is pre-release software I wasn't sure would ever be released, or well supported. That includes open-source software, unless I'm willing to support it myself.

Answer 9

If your product gets shipped, or installs on client machines, be very wary.

For web based systems (including components like Silverlight), it is possible. My previous company deployed systems based on the ASP.NET beta (before it was officially released).

This can be a good alternative in certain cases (a breakthrough technology that you need, for example). However, strong caution point: the more code, the more you will have to change. Beta products have no expected lifespan, support or legacy consideration. Therefore, you should expect to have to replace any code build based on a beta product.

For me, I would almost certainly avoid this unless absolutely necessary. Ask yourself: why are you using a beta version? If it is a very good answer, just consider the risks. Otherwise, run for your car. ;)

Answer 10

Sometimes you have no other choice. For example when the new CTP version of the tool just blows the existing technologies away.

For example:

When Windows Workflow Foundation was released, few alternatives existed. We considered the development cycle timeframe (1 year+) and realised it would be beneficial to take the risk and start researching/developing with the CTp version. Turned out it paid of on that project.

Another example is the new Sync Framework. It came out with SQL CE providers only, although we required SQL EE/STD providers. We prototyped with the CE providers and upgraded when the new EE provider was released.

Our only option would have been to go with SQL server merge replication or similar technology. Ugh!