Most likely you work with a team of people and this should be taken into consideration as well. Some ways to test/evaluate technology maturity:
Is your team and management receptive to using new technology at all? This might be your biggest barrier. If you get the sense that they aren't receptive, you can try big formal presentations to convince them... or just go try it out (see below).
Do some Googling around for problems people have with it. If you don't find much, then this is what you'll run into when you have problems
Find some new small project with very low risk (e.g. something just you or a couple people would use), apply new technology in skunkworks fashion to see how it pans out.
Try to find the most mature of the immature. For instance if you're thinking about a NoSQL type of data store. All of the NoSQL stuff is immature when you compare against RDBMS like Oracle that has been around for decades, so look at the most mature solution for these that has support organizations, either professionally or via support groups.
Easiest project to start is to re-write an existing piece of software. You already have your requirements: make it just like that. Just pick a small piece of the software to re-write in the new technology, preferably something you can hammer at with unit/load testing to see how it stands up. I'm not advocating to re-write an entire application to prove it out, but a small measurable chunk.
Only use one "new" technology at a time. The more new things you use, the greater chance of there being a serious problem.
Make sure there is an advantage to using it. If that cool, new technology does not give you some advantage, why are you using it?
Plan for the learning curve. There will be aspects of the new technology that you do not know about. You, and your team, will have to spend more time learning about them then you think you will.
If possible try the new technology on a small less important project first. Your companies accounting system is not the best place to experiment.
Have a back up plan. New technologies don't always turn out to be worth it. Know when you are in a "coffin corner" and it is time to bail out.
There's a difference between "field tested" and "out-of-date." Developers (myself included) generally prefer bleeding edge stuff. To some extent, you have to keep your development staff happy and interested in their jobs.
But I've never had a customer unhappy with field tested technology. They are generally unaware or unconcerned about the technology that is used in producing a product. Their number one priority is how it works in their daily interactions with it.
When starting a new project, two questions come to mind in evaluating if I should move to a new platform:
1) What benefits do I get from going to the new platform. If it offers me a dramatically reduced development time or significant performance increases for the users, I will consider a semi-bleeding edge technology.
2) What risks are associated with the new platform. Is it likely that there are some scenarios that I will encounter that aren't quite worked out in the new platform? Is it likely that support for this new platform will fizzle out and I'll be left holding the bag on supporting a deprecated environment? Are there support channels in place that I can use if I get stuck at a critical juncture of my project?
Like everything, it's a cost/benefit analysis. Generally speaking, while I always learn and train on new technologies, I won't build something for a client using a technology (environment, library, server platform, etc) that hasn't been widely adopted by a large number of developers for at least 6-12 months.
这取决于上下文。每个组织都必须做出自己的决定。关于这个主题的经典文献是 Geoffrey A. Moore 的跨越鸿沟。
That depends on the context. Each organisation has to make its own decisions. The classic literature on this topic is Crossing the Chasm by Geoffrey A. Moore.
If the company/community developing the product is known for good products then I'm very happy to put a safe bet on their new products.
For example I would be quite happy to develop on Rails 3 or Ruby 1.9, as I am quite sure they will be fine when finalized.
However I wouldn't write much code in superNewLang untill I was convinced that they had a great, well supported product, or they had a feature I couldn't live without.
I will tend to get the most trusted product, that suits all my needs.
发布评论
评论（6）
您很可能与一群人一起工作，这一点也应该考虑在内。测试/评估技术成熟度的一些方法：
您的团队和管理层是否愿意使用新技术？这可能是你最大的障碍。如果您感觉他们不接受，您可以尝试大型正式演示来说服他们...或者直接尝试一下（见下文）。
用谷歌搜索一下人们遇到的问题。如果你没有找到太多，那么这就是你遇到问题时会遇到的问题
找到一些风险非常低的新的小项目（例如只有你或几个人会使用的东西），应用新技术 。
尝试在不成熟的事物中找出最成熟的事物。例如，如果您正在考虑 NoSQL 类型的数据存储。当您与已经存在了数十年的 Oracle 等 RDBMS 进行比较时，所有 NoSQL 的东西都是不成熟的，因此请寻找那些拥有专业支持组织或通过支持小组提供支持的最成熟的解决方案。
最简单的项目启动是重写现有的软件。您已经有了自己的要求：就像那样。只需选择软件的一小部分，用新技术重新编写，最好是可以通过单元/负载测试来锤炼的东西，看看它的表现如何。我并不主张重写整个应用程序来证明这一点，而是主张重写一小部分可衡量的应用程序。
Most likely you work with a team of people and this should be taken into consideration as well. Some ways to test/evaluate technology maturity:
Is your team and management receptive to using new technology at all? This might be your biggest barrier. If you get the sense that they aren't receptive, you can try big formal presentations to convince them... or just go try it out (see below).
Do some Googling around for problems people have with it. If you don't find much, then this is what you'll run into when you have problems
Find some new small project with very low risk (e.g. something just you or a couple people would use), apply new technology in skunkworks fashion to see how it pans out.
Try to find the most mature of the immature. For instance if you're thinking about a NoSQL type of data store. All of the NoSQL stuff is immature when you compare against RDBMS like Oracle that has been around for decades, so look at the most mature solution for these that has support organizations, either professionally or via support groups.
Easiest project to start is to re-write an existing piece of software. You already have your requirements: make it just like that. Just pick a small piece of the software to re-write in the new technology, preferably something you can hammer at with unit/load testing to see how it stands up. I'm not advocating to re-write an entire application to prove it out, but a small measurable chunk.
一些经验法则。
一次只使用一种“新”技术。你使用的新东西越多，出现严重问题的可能性就越大。
确保使用它有优势。如果这项很酷的新技术不能给你带来一些优势，你为什么要使用它？
规划学习曲线。新技术的某些方面是您不了解的。您和您的团队将不得不花费比您想象的更多的时间来了解它们。
如果可能的话，首先在一个不太重要的小项目上尝试新技术。您公司的会计系统不是试验的最佳场所。
有一个备份计划。新技术并不总是值得的。知道你什么时候处于“棺材角”，是时候跳出来了。
A few rules of thumb.
Only use one "new" technology at a time. The more new things you use, the greater chance of there being a serious problem.
Make sure there is an advantage to using it. If that cool, new technology does not give you some advantage, why are you using it?
Plan for the learning curve. There will be aspects of the new technology that you do not know about. You, and your team, will have to spend more time learning about them then you think you will.
If possible try the new technology on a small less important project first. Your companies accounting system is not the best place to experiment.
Have a back up plan. New technologies don't always turn out to be worth it. Know when you are in a "coffin corner" and it is time to bail out.
“经过现场测试”和“过时”之间是有区别的。开发人员（包括我自己）通常更喜欢前沿的东西。在某种程度上，您必须让您的开发人员对他们的工作感到满意和感兴趣。
但我从未遇到过对经过现场测试的技术不满意的客户。他们通常不知道或不关心生产产品所使用的技术。他们的首要任务是它在日常互动中的运作方式。
当开始一个新项目时，在评估我是否应该迁移到新平台时，我会想到两个问题：
1）迁移到新平台能给我带来什么好处。如果它为我提供了显着减少的开发时间或显着提高用户的性能，我将考虑半前沿技术。
2) 新平台有哪些风险。我是否可能会遇到一些在新平台中尚未解决的场景？对这个新平台的支持是否有可能会失败，而我将独自承担支持已弃用环境的责任？如果我遇到项目的关键时刻，是否有可以使用的支持渠道？
与所有事情一样，这是成本/收益分析。一般来说，虽然我总是学习和培训新技术，但我不会使用尚未被大量开发人员广泛采用的技术（环境、库、服务器平台等）为客户构建一些东西。至少6-12个月。
There's a difference between "field tested" and "out-of-date." Developers (myself included) generally prefer bleeding edge stuff. To some extent, you have to keep your development staff happy and interested in their jobs.
But I've never had a customer unhappy with field tested technology. They are generally unaware or unconcerned about the technology that is used in producing a product. Their number one priority is how it works in their daily interactions with it.
When starting a new project, two questions come to mind in evaluating if I should move to a new platform:
1) What benefits do I get from going to the new platform. If it offers me a dramatically reduced development time or significant performance increases for the users, I will consider a semi-bleeding edge technology.
2) What risks are associated with the new platform. Is it likely that there are some scenarios that I will encounter that aren't quite worked out in the new platform? Is it likely that support for this new platform will fizzle out and I'll be left holding the bag on supporting a deprecated environment? Are there support channels in place that I can use if I get stuck at a critical juncture of my project?
Like everything, it's a cost/benefit analysis. Generally speaking, while I always learn and train on new technologies, I won't build something for a client using a technology (environment, library, server platform, etc) that hasn't been widely adopted by a large number of developers for at least 6-12 months.
这取决于上下文。每个组织都必须做出自己的决定。关于这个主题的经典文献是 Geoffrey A. Moore 的跨越鸿沟。
That depends on the context. Each organisation has to make its own decisions. The classic literature on this topic is Crossing the Chasm by Geoffrey A. Moore.
如果开发该产品的公司/社区以优质产品而闻名，那么我很高兴对他们的新产品进行安全押注。
例如，我很乐意在 Rails 3 或 Ruby 1.9 上进行开发，因为我非常确定它们在最终确定后会很好。
然而，我不会在 superNewLang 中编写太多代码，直到我确信他们有一个很棒的、支持良好的产品，或者他们有一个我离不开的功能。
我倾向于购买最值得信赖的、满足我所有需求的产品。
If the company/community developing the product is known for good products then I'm very happy to put a safe bet on their new products.
For example I would be quite happy to develop on Rails 3 or Ruby 1.9, as I am quite sure they will be fine when finalized.
However I wouldn't write much code in superNewLang untill I was convinced that they had a great, well supported product, or they had a feature I couldn't live without.
I will tend to get the most trusted product, that suits all my needs.