How do you evaluate components?
-
I'm currently planning a new project, and need a good charting library. Flipping through the pile of magazines on my desk and googling a bit found a lot of choices... I'm curious as to how other people go about evaluating something like this. I figure I should at least look at 3-4, but do most of you just install, run the samples, look over the docs and make a decision based on that, or do you spend the time using it for a prototype? I've gotten burned before with the first approach, but the second approach takes time, and when you're working for yourself... I could easily spend a couple of weeks on this one piece of the project if I really tried prototyping with that many different components. And do you immediately toss out packages with seemingly outrageous licensing costs, or do you look just to see if somehow they've got the secret sauce and are worth the extra expense? For example one heavily advertised component costs $3000, and that is NOT a redistribution license, but a developer and a SINGLE production server. Compared against components that are 20% or less of that cost and are redistributable, it had better pretty much write the code for me, or make customers throw money... How do you decide to spend your/your employers money?
It mostly depends on the library, but Identify criteria What, beyond their marketing spin, is important for you? Looking at the features of all contenders often tells me for which to prod the other components. Maybe make a table (it helps me focus, and not being overwhelmed by "feel") Do prototype. It's like "pants down" for the component. I had components that flood the debug log with messages, interfaces that are so much VB-centric that they are nearly unusable from C++, etc. Further, as long as you haven't purchased, they are always helpful :) It shouldn't take to long, one man-day total can tell you a lot already. See if you get started quickly, then try to understand the limits and if you can live with them. Expensive packages Use them as source of information: what can a chart do for you, and can you live without this? An expensive package usually has a marketing guy - send an e-mail and ask what makes them better than the others. Charting If the charts are central to your application, spend a lot of time evaluating. Don't ask me how much time was spent "adjusting" our charting component Source AFAIR the major charting components don't offer source code, which is a pity. It's never a good idea to change the source of a 3rd party component (merge with upgrade is a pain), but it's sometimes the only way to fix bugs.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist -
I'm currently planning a new project, and need a good charting library. Flipping through the pile of magazines on my desk and googling a bit found a lot of choices... I'm curious as to how other people go about evaluating something like this. I figure I should at least look at 3-4, but do most of you just install, run the samples, look over the docs and make a decision based on that, or do you spend the time using it for a prototype? I've gotten burned before with the first approach, but the second approach takes time, and when you're working for yourself... I could easily spend a couple of weeks on this one piece of the project if I really tried prototyping with that many different components. And do you immediately toss out packages with seemingly outrageous licensing costs, or do you look just to see if somehow they've got the secret sauce and are worth the extra expense? For example one heavily advertised component costs $3000, and that is NOT a redistribution license, but a developer and a SINGLE production server. Compared against components that are 20% or less of that cost and are redistributable, it had better pretty much write the code for me, or make customers throw money... How do you decide to spend your/your employers money?
Our products are priced relatively inexpensively so when I evaluate components I don't even consider ones with any licensing costs based on royalties. I wouldn't in any case even if we were selling licenses for thousands of dollars each because I don't want a third party that tightly involved in our business. (I looked at a really nice set of asp.net ajax components and found out later that they don't even state a royalty cost but there is one - "email us for to discuss royalties", ugh! Apparently they aren't after the developer market that makes and sells software to others.) Royalties are something to be avoided at all costs unless it's an in-house project. On the other hand the base price per developer when there are no royalties is not something to be too scared of, there is wild pricing, the component market is particularly volatile unless it's a very widely competetive market for a particular component, but I've found that pricing is completely unrelated to the usefulness and quality of the component so as long as it's affordable it should be looked at. In terms of evaluation you absolutely have to create a sample project and test it out from start to and including deployment testing. We bought a popular reporting .net component a long time ago, were promised that it would do a certain thing we needed for one particular report but made the mistake of believing that and found out 1 week before release as we were finishing up the stock reports that it wasn't going to work and after a mad scramble found a better solution that was cheaper. What I do is first and foremost is try to write a list of every feature it should have and how it should hook into my application and deploy, then do some research and build a list of the most likely candidates and at this stage weed out any with royalties or out of our budget, then for each one look over the samples first to see if it's close, then go onto their message board if they have one and read through the support questions and comments of others to get a feel for the company and the problems with the component that people are having, how long it takes them to answer questions, how lively the board is (which tells you how widely used it is or if it's difficult to use etc), then download and test it with a sample project that replicates all the conditions on my initial checklist. Yes it takes time and coming from a very small shop I know it feels like wasted time, but in the long run it is anything but.
-
It mostly depends on the library, but Identify criteria What, beyond their marketing spin, is important for you? Looking at the features of all contenders often tells me for which to prod the other components. Maybe make a table (it helps me focus, and not being overwhelmed by "feel") Do prototype. It's like "pants down" for the component. I had components that flood the debug log with messages, interfaces that are so much VB-centric that they are nearly unusable from C++, etc. Further, as long as you haven't purchased, they are always helpful :) It shouldn't take to long, one man-day total can tell you a lot already. See if you get started quickly, then try to understand the limits and if you can live with them. Expensive packages Use them as source of information: what can a chart do for you, and can you live without this? An expensive package usually has a marketing guy - send an e-mail and ask what makes them better than the others. Charting If the charts are central to your application, spend a lot of time evaluating. Don't ask me how much time was spent "adjusting" our charting component Source AFAIR the major charting components don't offer source code, which is a pity. It's never a good idea to change the source of a 3rd party component (merge with upgrade is a pain), but it's sometimes the only way to fix bugs.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighistpeterchen wrote:
AFAIR the major charting components don't offer source code, which is a pity.
Infragistics offers source code with all their components at no extra cost IIRC. Also DevExpress which we use for the reporting component offers source code at a not too exhorbitant extra cost. Although to be honest I have no interest in the source code, it kind of defeats the purpose of buying a component if you ever have to frig around with the code and try to build it IMNSHO.
-
It mostly depends on the library, but Identify criteria What, beyond their marketing spin, is important for you? Looking at the features of all contenders often tells me for which to prod the other components. Maybe make a table (it helps me focus, and not being overwhelmed by "feel") Do prototype. It's like "pants down" for the component. I had components that flood the debug log with messages, interfaces that are so much VB-centric that they are nearly unusable from C++, etc. Further, as long as you haven't purchased, they are always helpful :) It shouldn't take to long, one man-day total can tell you a lot already. See if you get started quickly, then try to understand the limits and if you can live with them. Expensive packages Use them as source of information: what can a chart do for you, and can you live without this? An expensive package usually has a marketing guy - send an e-mail and ask what makes them better than the others. Charting If the charts are central to your application, spend a lot of time evaluating. Don't ask me how much time was spent "adjusting" our charting component Source AFAIR the major charting components don't offer source code, which is a pity. It's never a good idea to change the source of a 3rd party component (merge with upgrade is a pain), but it's sometimes the only way to fix bugs.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighistWhat I'm going to be working on is a dashboard application, and the more options the better as far as charting, however it does have a limited resale market, so price does matter. The part that is going to be painful for prototyping is in exposing options to the end user. Seeing if the high dollar components can actually tell me why they're worth all that is a good idea. Only problem is trying to shake the sales calls afterwards....
-
Our products are priced relatively inexpensively so when I evaluate components I don't even consider ones with any licensing costs based on royalties. I wouldn't in any case even if we were selling licenses for thousands of dollars each because I don't want a third party that tightly involved in our business. (I looked at a really nice set of asp.net ajax components and found out later that they don't even state a royalty cost but there is one - "email us for to discuss royalties", ugh! Apparently they aren't after the developer market that makes and sells software to others.) Royalties are something to be avoided at all costs unless it's an in-house project. On the other hand the base price per developer when there are no royalties is not something to be too scared of, there is wild pricing, the component market is particularly volatile unless it's a very widely competetive market for a particular component, but I've found that pricing is completely unrelated to the usefulness and quality of the component so as long as it's affordable it should be looked at. In terms of evaluation you absolutely have to create a sample project and test it out from start to and including deployment testing. We bought a popular reporting .net component a long time ago, were promised that it would do a certain thing we needed for one particular report but made the mistake of believing that and found out 1 week before release as we were finishing up the stock reports that it wasn't going to work and after a mad scramble found a better solution that was cheaper. What I do is first and foremost is try to write a list of every feature it should have and how it should hook into my application and deploy, then do some research and build a list of the most likely candidates and at this stage weed out any with royalties or out of our budget, then for each one look over the samples first to see if it's close, then go onto their message board if they have one and read through the support questions and comments of others to get a feel for the company and the problems with the component that people are having, how long it takes them to answer questions, how lively the board is (which tells you how widely used it is or if it's difficult to use etc), then download and test it with a sample project that replicates all the conditions on my initial checklist. Yes it takes time and coming from a very small shop I know it feels like wasted time, but in the long run it is anything but.
Good sound advice. I worked for a company not long ago that had a third party toolkit provider that tried to hold them hostage after an app was widely deployed. They had negotiated an unlimited redistribution agreement for X number of years, and when that initial contract was up the price went supernova. When they wouldn't get reasonable (they did no support for us, it was purely a money grab) engineering was told to rewrite anything that used their stuff, as they couldn't reach terms. Not something I'd like to be involved in on my own dime... I pretty much see myself prototyping the entire app and writing a proxy class to wrap the graph controls, so I can keep it abstracted away. And you're right, better to spend the time up front than be cursing the control I choose two weeks before delivery... What reporting component did you end up with? We're currently experimenting with SQL Server Reporting Services after having given up on Crystal. We've also got a rather insane home grown system that uses Excel to generate reports...
-
Good sound advice. I worked for a company not long ago that had a third party toolkit provider that tried to hold them hostage after an app was widely deployed. They had negotiated an unlimited redistribution agreement for X number of years, and when that initial contract was up the price went supernova. When they wouldn't get reasonable (they did no support for us, it was purely a money grab) engineering was told to rewrite anything that used their stuff, as they couldn't reach terms. Not something I'd like to be involved in on my own dime... I pretty much see myself prototyping the entire app and writing a proxy class to wrap the graph controls, so I can keep it abstracted away. And you're right, better to spend the time up front than be cursing the control I choose two weeks before delivery... What reporting component did you end up with? We're currently experimenting with SQL Server Reporting Services after having given up on Crystal. We've also got a rather insane home grown system that uses Excel to generate reports...
-
I'm currently planning a new project, and need a good charting library. Flipping through the pile of magazines on my desk and googling a bit found a lot of choices... I'm curious as to how other people go about evaluating something like this. I figure I should at least look at 3-4, but do most of you just install, run the samples, look over the docs and make a decision based on that, or do you spend the time using it for a prototype? I've gotten burned before with the first approach, but the second approach takes time, and when you're working for yourself... I could easily spend a couple of weeks on this one piece of the project if I really tried prototyping with that many different components. And do you immediately toss out packages with seemingly outrageous licensing costs, or do you look just to see if somehow they've got the secret sauce and are worth the extra expense? For example one heavily advertised component costs $3000, and that is NOT a redistribution license, but a developer and a SINGLE production server. Compared against components that are 20% or less of that cost and are redistributable, it had better pretty much write the code for me, or make customers throw money... How do you decide to spend your/your employers money?
That's a tough one, and several people have offered advice similar to what I would suggest, which is that in the long run, it pays to prototype. So, I'll offer something that I haven't read anyone else suggest, which isn't directly related to your question, and that is, I always write a wrapper around a third party package, rather than entangling my application specific code to the component specific implementation. Because frankly, even with the planning, testing, and prototyping, I'm still not guaranteed that it's the right component. I also don't want to be locked in to an obsolete product. So I always wrap it, with the idea that I may at some point need to replace the component. So, this is advice for when you get to implementation rather than evaluation. Marc Pensieve Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
-
I'm currently planning a new project, and need a good charting library. Flipping through the pile of magazines on my desk and googling a bit found a lot of choices... I'm curious as to how other people go about evaluating something like this. I figure I should at least look at 3-4, but do most of you just install, run the samples, look over the docs and make a decision based on that, or do you spend the time using it for a prototype? I've gotten burned before with the first approach, but the second approach takes time, and when you're working for yourself... I could easily spend a couple of weeks on this one piece of the project if I really tried prototyping with that many different components. And do you immediately toss out packages with seemingly outrageous licensing costs, or do you look just to see if somehow they've got the secret sauce and are worth the extra expense? For example one heavily advertised component costs $3000, and that is NOT a redistribution license, but a developer and a SINGLE production server. Compared against components that are 20% or less of that cost and are redistributable, it had better pretty much write the code for me, or make customers throw money... How do you decide to spend your/your employers money?
I agree totally with John Cardinal. I also must be able to evalute the software and write code to it. On more than one occasion I have preferred one set of components over another only to completely change my mind when using those components for real world code. When testing, contact support. If you find a bug, report it and see how long it takes to respond and HOW they respond. All other things being equal, this could be a major deciding point. Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Oh we were forced to use Crystal for years, yuck. Now that we're in the .net world we use XtraReports from DevExpress.
-
I'm currently planning a new project, and need a good charting library. Flipping through the pile of magazines on my desk and googling a bit found a lot of choices... I'm curious as to how other people go about evaluating something like this. I figure I should at least look at 3-4, but do most of you just install, run the samples, look over the docs and make a decision based on that, or do you spend the time using it for a prototype? I've gotten burned before with the first approach, but the second approach takes time, and when you're working for yourself... I could easily spend a couple of weeks on this one piece of the project if I really tried prototyping with that many different components. And do you immediately toss out packages with seemingly outrageous licensing costs, or do you look just to see if somehow they've got the secret sauce and are worth the extra expense? For example one heavily advertised component costs $3000, and that is NOT a redistribution license, but a developer and a SINGLE production server. Compared against components that are 20% or less of that cost and are redistributable, it had better pretty much write the code for me, or make customers throw money... How do you decide to spend your/your employers money?
Mark Tutt wrote:
I'm currently planning a new project, and need a good charting library. Flipping through the pile of magazines on my desk and googling a bit found a lot of choices...
Money is not always an issue where I work, in fact I tend to be so spend thrift they tease me on my big toys (computers) but they are still a fraction of the other groups and everyone knows it. I start with "need." "Want" is a plus, but not a requirement, it has to meet requirements, period. If it doesn't meet the criteria it better be because the technology isn't there yet. Licensing is an issue, we have an unknown number of distribution sites, internal use is fine for almost anything, but if it is a tool/component that goes to the field? it better have low cost per seat or licensing buy-outs. I have given my criteria for any object written or purchased to the others on my team. We have to keep in mind a balance between performance and ease of use. I would love to have both, not always possible so the edge always goes to performance. I will not use a component that slows down our application no matter how easy it is to use. We have several products that are unlimited distribution of output only, developer end costs $10k to $60k, but no costs for distribution of final product to an end user. Money is not the be-all-end-all judge of "worth," content is. Money is irrelevant when you have it, and severely limiting when you don't, so saving money is still important. Even when you have it is better to save it for a rainy day, so to speak. After I have a few choices I always google or ask around, I do my homework, test it, etc. I have been accused of being too hesitant to jump at new technologies and also too eager depending on who you ask. I won't turn away new technology, but I will give it the run-through. _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
I'm currently planning a new project, and need a good charting library. Flipping through the pile of magazines on my desk and googling a bit found a lot of choices... I'm curious as to how other people go about evaluating something like this. I figure I should at least look at 3-4, but do most of you just install, run the samples, look over the docs and make a decision based on that, or do you spend the time using it for a prototype? I've gotten burned before with the first approach, but the second approach takes time, and when you're working for yourself... I could easily spend a couple of weeks on this one piece of the project if I really tried prototyping with that many different components. And do you immediately toss out packages with seemingly outrageous licensing costs, or do you look just to see if somehow they've got the secret sauce and are worth the extra expense? For example one heavily advertised component costs $3000, and that is NOT a redistribution license, but a developer and a SINGLE production server. Compared against components that are 20% or less of that cost and are redistributable, it had better pretty much write the code for me, or make customers throw money... How do you decide to spend your/your employers money?
Remember that most sales people lie and often don't have the tech skills to know what true developers need. My last company spent thousands on a new HR system based on this and that. When I finally got ahold of an actual programmer who now does training for the company he told me the truth. It really burned me. Granted they bought the software before I started at the company. If I am ever in the position again to decide what major software to purchase I'm going to ask at least 10 developers.
-
I'm currently planning a new project, and need a good charting library. Flipping through the pile of magazines on my desk and googling a bit found a lot of choices... I'm curious as to how other people go about evaluating something like this. I figure I should at least look at 3-4, but do most of you just install, run the samples, look over the docs and make a decision based on that, or do you spend the time using it for a prototype? I've gotten burned before with the first approach, but the second approach takes time, and when you're working for yourself... I could easily spend a couple of weeks on this one piece of the project if I really tried prototyping with that many different components. And do you immediately toss out packages with seemingly outrageous licensing costs, or do you look just to see if somehow they've got the secret sauce and are worth the extra expense? For example one heavily advertised component costs $3000, and that is NOT a redistribution license, but a developer and a SINGLE production server. Compared against components that are 20% or less of that cost and are redistributable, it had better pretty much write the code for me, or make customers throw money... How do you decide to spend your/your employers money?
Mark Tutt wrote:
I'm currently planning a new project, and need a good charting library.
If this is a .NET project, then I highly recommend you to check out ZedGraphs. It's free, open source, stable, and looks great. I've been using it for a year with great success. http://zedgraph.org[^]
-
Mark Tutt wrote:
I'm currently planning a new project, and need a good charting library.
If this is a .NET project, then I highly recommend you to check out ZedGraphs. It's free, open source, stable, and looks great. I've been using it for a year with great success. http://zedgraph.org[^]
-
I had that one bookmarked, waiting for 5.0 to come out. Have the forums and community been good about responding to questions?
Mark Tutt wrote:
Have the forums and community been good about responding to questions?
Yes. The developer John Champion actively monitors the forums on SourceForge and his CodeProject article forum. He's also been actively developing this chart library for the past 2 years and has added a lot of great features within that time period. Including some features requested in the SourceForge forums. On top of that, this chart library includes documentation and plenty of code examples in C# and VB.NET for WinForms and WebForms. In my opinion, this chart control is easily commercial level material which the developer has graciously decided to give to us for free. Very impressive stuff.
-
That's a tough one, and several people have offered advice similar to what I would suggest, which is that in the long run, it pays to prototype. So, I'll offer something that I haven't read anyone else suggest, which isn't directly related to your question, and that is, I always write a wrapper around a third party package, rather than entangling my application specific code to the component specific implementation. Because frankly, even with the planning, testing, and prototyping, I'm still not guaranteed that it's the right component. I also don't want to be locked in to an obsolete product. So I always wrap it, with the idea that I may at some point need to replace the component. So, this is advice for when you get to implementation rather than evaluation. Marc Pensieve Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
-
I'm currently planning a new project, and need a good charting library. Flipping through the pile of magazines on my desk and googling a bit found a lot of choices... I'm curious as to how other people go about evaluating something like this. I figure I should at least look at 3-4, but do most of you just install, run the samples, look over the docs and make a decision based on that, or do you spend the time using it for a prototype? I've gotten burned before with the first approach, but the second approach takes time, and when you're working for yourself... I could easily spend a couple of weeks on this one piece of the project if I really tried prototyping with that many different components. And do you immediately toss out packages with seemingly outrageous licensing costs, or do you look just to see if somehow they've got the secret sauce and are worth the extra expense? For example one heavily advertised component costs $3000, and that is NOT a redistribution license, but a developer and a SINGLE production server. Compared against components that are 20% or less of that cost and are redistributable, it had better pretty much write the code for me, or make customers throw money... How do you decide to spend your/your employers money?
The first and foremost to analyse in depth would be the 'own' requirement analysis and understanding of the same with utmost clarity and a concise report for the team to understand. Next, you need to analyse the various available (similar) products in the market. Next, the cost analysis -- from free applications to the ones that cost the sun and the moon. Next, cost - benefit analysis. Next; robustness, support, futuristic etc... Vasudevan Deepak Kumar Personal Homepage namespace LavanyaDeepak
Personal Weblog
The World of Deepak and Lavanya
ViewPoint 24x7 -
peterchen wrote:
AFAIR the major charting components don't offer source code, which is a pity.
Infragistics offers source code with all their components at no extra cost IIRC. Also DevExpress which we use for the reporting component offers source code at a not too exhorbitant extra cost. Although to be honest I have no interest in the source code, it kind of defeats the purpose of buying a component if you ever have to frig around with the code and try to build it IMNSHO.
My POV on source code: work as if you don't have it. It's just the final safety rope before falling into the lava pit.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist