|
I noticed some 3rd party control vendors are reading. I have some input for you. I remember sitting down with Visual Basic 1 or 2 and thinking, "Wow, VBX's are going to change everything!" Then reality set in. 3rd party vendors just weren't able to provide seamless, fully functional components without "hacks galor", which usually meant your program suffered as a consequence of using them. Then OCX's came along, and again here's me thinking, "Yes, this is finally it". BEEEP! Wrong again. COM, for all the great things that it acheived was really just a stopgap measure along the road to fully self describing object nirvana. If that's not .NET, then boy it's really, really close! MFC? Please. I'm still trying to find a use for my stack of Stingray CD's.
I urge all of you who have not sat down and written your own .NET controls yet to do so. It's criminally easy. Want them to show up in the toolbar? Easy. Want them to show all their properties with descriptions? Easy. Want them to generate events, integrate with the IDE, display at design time, do data binding? Easy, easy, easy.
So, on the one hand writing your own controls has suddenly become a reasonable (and fun) thing to do (certainly if you start with some of the great stuff available on CodeProject). On the other hand I've seen some control vendors who really get it and have written fully managed versions of their existing controls, with source code available. I haven't yet seen any "you could only do this in .NET stuff", but there you go.
Having worked with .NET for some time, and having worked for a 3rd party tools vendor (Progress Software/Crescent Software) I still think 3rd party vendors have some major problems to solve. 1. Your pricing models are all screwed up. Some of you charge way to much for stuff for which usually only 10% of the available functionality is going to get used. $1000 is a big ticket item to push through, $100 bucks is a, "Yeah, I'll take 10 of those" deal. 2. If your price is too high, this developer license thing just doesn't work. Perhaps if you break your products up so I can buy just what I need. 3. Work together! You're all producing the same stuff! Fill out your product lines by rebadging stuff from other vendors instead of writing your own. I'm always going to buy the library that has the most features. The first thing I do when I start looking for something is write down what I think I need. Anyone's controls that don't have the feature is O.U.T. How many vendors have a place on their web site to take input on why I rejected your stuff? Nada. 4. Get responsive to customer needs. I'm not kidding - the open source movement for .NET controls is going to be huge. Scratch that - it already is. I my opinion the source code is only important so that I can tell your support people where the program bombed and as extra documentation. I don't want to find your bugs - I want you too!
When all those MFC/WTL/VB6 developers work up the energy to learn .NET you're going to be wondering why nobodies buying UI components anymore. They'll all be up here downloading Carlos' stuff. If you can't do any of this then perhaps it's time to start developing web services to format code and clear credit cards? 
John
|
|
|
|
|
I am creating and selling ActiveX components allowing to create flowchart diagrams. Currently, I am developing .NET versions of these components.
I agree with your opinion about the source code ("I am still trying to find a use for my stack of Stingray CD's"). Often, I have seen companies purchasing the source code of a software and never use it.
I agree also with you that developing under .NET is incredibly easier than for instance with MFC (complicated) or even ATL (more than complicated: ridiculous).
However, I believe that even under .NET, creating a component remains a difficult task. There are allways some very difficult design choices to do (sometimes for details like finding a name for a property: this is important because the property will be used by thousand of developers during several years).
And there are features that remains difficult to implement. For instance, if you implement a graph layout algorithm, the difficulty is almost the same whatever language or environment you use.
Also when designing a component, I prefer the quality to the quantity. The inflation of features is often the result of a poor design. It often causes an inflation of bugs. I think that 3rd Party vendors should resist against the pressure of customers to add features. In my opinion, a good component should be a small component that only accomplishes its task and nothing more.
|
|
|
|
|
All this has been going on in the Borland/Delphi world for several years. It's all new to you in the MS world 
|
|
|
|
|
We have very rigid timeframes for getting apps out. It gets hard to do this when everyone is still learning the guts of .NET. Sometimes I dive into writing my own control to do what I want. If I hit a snag I go off to GOTDOTNET to see if someone has an answer. (after searching MSDN for an hour) But to do something outside my realm (put in a cool, graphic control that I have no artistic ability to create myself) I will use a 3rd party control. The company I am a part of also have purchased an enterprise license with one vendor that gives us some good controls as well. So we will use those controls outright. Other controls....they have to be free and provide source code.
|
|
|
|
|
If our company want's to use a third party piece of component I always recommend the company that ships the source/documentation with the component.
Developing with C++ is like programming by the seat of your pants
|
|
|
|
|
|
the client, usually 
Auch den Schatten will ich lieben weil ich manchmal lieber frier' Rosenstolz [sighist]
|
|
|
|
|
So if a component vendor OEMs another vendors component, does this make it a 4th party component  ???
|
|
|
|
|
This is a general question for everyone who reads this:
What are the general decision factors you use when determining when to use a component or not? (Complexity, ROI, turn-around time, etc.)
And what criteria do you use to choose between similar components? (Price, quality, support, learning curve, etc.)
Troy Marchand
VP Component Development
Dundas Software
|
|
|
|
|
Troy Marchand wrote:
What are the general decision factors you use when determining when to use a component or not? (Complexity, ROI, turn-around time, etc.)
Generally, we will use a component when the required functionality is too expensive to develop in-house compared to the costs of adapting to the third party component. If we develop the component in-house, we get exactly what we want, but this approach is expensive in terms of manhours spent developing the component. If we buy the component, we spend manhours learning how to use it, and adapting our needs to the functionality the component provides. With purchased components, you also have to weigh the risks inherent in support from an outside vendor. If you need additional functionality (or bug fixes) that only the vendor can provide, you are constrained to their abilities and schedule.
And what criteria do you use to choose between similar components? (Price, quality, support, learning curve, etc.)
Add prior history or experience with the vendor and customer needs (some customers may dictate compatibility with 'Company X'). Performance can be an issue in some cases.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote:
Generally, we will use a component when the required functionality is too expensive to develop in-house compared to the costs of adapting to the third party component...
I agree with that whole paragraph.
|
|
|
|
|
One of the problems I have with management where I work is third party software. The management here seems to think that using third party stuff is 'free', except for what you pay to the third party. They never recognize that third party stuff does have a cost associated with it.
"You're using 'XYZ', so why aren't you done?"
"Well, we first had to learn to use 'XYZ', and then we found out it doesn't do 'abc' so we have to emulate it. We also found out that when we 'def' they GPF. We've got a bug report in to them, but they haven't responded yet. In the meantime, we've developed a workaround, but it means 'blah' feature in our product won't work quite the way we planned."
I don't object to third party software at all. I just dislike the notion that it's something for nothing.
And so it goes...
Software Zen: delete this;
|
|
|
|
|
We've got a bug report in to them, but they haven't responded yet.
Don't you mean they haven't responded 'asap'?
|
|
|
|
|
ASAP = As Soon As you Pay for that level of support.
In my experience, the only time you get a bug fix out of someone like this is if you have a separate and distinct contractual relationship with them. If all you've got is a retail relationship, they have neither a need nor an obligation to fix things according to your schedule.
Software Zen: delete this;
|
|
|
|
|
Generally, we will use a component when the required functionality is too expensive to develop in-house compared to the costs of adapting to the third party component. If we develop the component in-house, we get exactly what we want, but this approach is expensive in terms of manhours spent developing the component. If we buy the component, we spend manhours learning how to use it, and adapting our needs to the functionality the component provides. With purchased components, you also have to weigh the risks inherent in support from an outside vendor. If you need additional functionality (or bug fixes) that only the vendor can provide, you are constrained to their abilities and schedule.
Hey, thanks for the answer. This seems to be a common sentiment among developers, and is an area we have been working very hard to address over the past year.
Being a long time developer myself I understand this situation all too well. I personally use the 15 minute rule ... if I cannot get a component to 'basically' work in 15 minutes it is a waste of my time (Now there are exceptions to this rule, such as a component that performs a really complex task that would not be practical to create myself). Developers just don't have the time to play with a control for a week to see if it 'might' work with their project.
I think that one of the biggest problems is that most component companies "do not eat their own dog food!" They build these components, try and sell them to other people, but have not really used them extensively in real-world projects themselves. Trust me, our consulting group gives us loads of feedback and has made us rethink how we write our components. Plus we rotate our developers between the consulting product and support groups, so they can eat what they made!
Troy Marchand
VP Component Development
Dundas Software
|
|
|
|
|
I like the idea of rotating developers between business groups. Unfortunately, given the long development cycles for our products (12-18 months) and the long maintenance intervals (we have applications that are over 10 years old that are still maintained), it isn't feasible to move people about on any kind of regular basis.
Software Zen: delete this;
|
|
|
|
|
I like the idea of rotating developers between business groups. Unfortunately, given the long development cycles for our products (12-18 months) and the long maintenance intervals (we have applications that are over 10 years old that are still maintained), it isn't feasible to move people about on any kind of regular basis.
We generally do not move people around during a development cycle; instead we do it in between. Also we only a small portion of a team would be changed at any one time, to ensure that there are still key developers working on it. Plus any person who is moved would still be made available to help the old team if needed. Here at Dundas all of the groups work very closely together, so that we can get the benefit of each others knowledge.
Troy Marchand
VP Component Development
Dundas Software
|
|
|
|
|
3rd party component dependencies can also be an issue. For example, you probably wouldn't want to use a component that depends on MFC if you are shipping a WTL app! Years ago, we used to use the BitsPerSecond Graph control - but this required all the usual MFC DLLs to be shipped, and the app we wanted to use it with was plain old vanilla Win32/C. In the end we wrote our own graph code.
Consequently I will only consider 3rd party components if they are written in plain C++ - I chose the Dundas Ultimate TCP/IP library for this reason.
Faith. Believing in something you *know* isn't true.
|
|
|
|
|
No kidding. Anything that dynamically links to MFC42.DLL or MSVCRT.DLL is out. Period. Dependencies on different versions of IE can be frustrating too... I can understand being dependent on IE 4.0 or greater, since it comes with Wininet and many other DLLs that are now "standard", but that's about it.
Even a broken clock is right twice a day.
|
|
|
|
|
What about "IE5 or above" ??
Auch den Schatten will ich lieben weil ich manchmal lieber frier' Rosenstolz [sighist]
|
|
|
|
|
I can't remember if 2000 and/or 98 come with IE5. If so, then that's not *too* bad.
Certainly not IE6 or above. 
Even a broken clock is right twice a day.
|
|
|
|
|
W2K & 98 SE yes, 1st ed no
IE5 has far improved DHTML access from the outside, which we need now and then.
Navin wrote:
Even a broken clock is right twice a day.
Which you can't say of most clocks that "work". nonetheless people seem to prefer them
Auch den Schatten will ich lieben weil ich manchmal lieber frier' Rosenstolz [sighist]
|
|
|
|
|
Nine times out of ten it is cheaper and quicker for us to write our own components because nine times out of ten the problems we face are not that difficult.
It is only when we come up against something that will take a solid month or two to figure out and code that we will hunt for a component that does it for us.
Remember that cost of training and implementation with 3rd party components is quite high while with having written your own component the cost is much lower.
Also being in web dev we get the odd client who refuses to allow any 3rd party components on their servers. Even if we are hosting the solution some clients do not want 3rd party components for fear that the component manufacturer will go out of business and they will be left with an unknown component.
All I can say is thank god the .NET Framework has some fundamental components which normally required 3rd party components in ASP (.e.g uploading, image manipulation etc.)
|
|
|
|
|
So... what is the difference between a third-party component vendor going out of business, or you (as the developer) moving on to something else?? Would the availability of source code be the issue?
Plus, now that .NET components run in a secured manner, would you be more willing to use them, since they allow X-Copy deployment?
I don't mean to annoy you with all of these questions, but as a person in a component development business the more I understand what developer's wants and concerns are the better.
Troy
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
