What's "convenient" for the developer is rarely good for the end user
-
The problem with tools that make things like that easier is that too many developers believe that their job is done all that much quicker. Since it only took them a day or two to put a data base record on the screen and hook up some buttons to update and delete it, they think they're done. They don't bother doing capacity testing. They don't check to see what happens when the data base server goes down, or if there are millions of records or thousands of users. Mature, professional developers have been bitten by this phenomenon too many times. They're the ones who try out the new technology, and then start asking lots of pointed questions in the forums. Often they get ridiculed for it, being accused of having a 'dinosaur mentality'. Eventually the Next Big Thing comes along, and the process starts all over again.
Software Zen:
delete this;any "dinosaurs" i see these days i have a great respect for as they obviously figured out how to evolve and survive *really* well :cool:
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
If you were here, you would be covered by digestive ejecta right now.
Software Zen:
delete this;Gary Wheeler wrote:
digestive ejecta
Sounds like a great name for band...
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
John C wrote:
I contend that anything that is billed as making life easier for developers and does anything more than helping them write the code the way they always have should be taken with a 400 pound grain of salt and carefully examined to see if it actually brings any benefit to the END USER of the software (which is the whole point of writing software often forgotten by developers too in love with their tools).
:shrug: Well, sure. I mean, that's just healthy skepticism - taste and see before you chow down... That said, as comfortable and productive as i am with my trusty ol' C++ compiler and thin Win32 wrappers, i can't ignore the benefits that HTML+JS UIs... or even WinForms UIs in some cases... can contribute both to me and my users. IMHO, the biggest benefit to be found is in tools that let you quickly implement and demonstrate features or changes to a user - the best looking paper prototype won't ever come close to flushing out the sorts of subtle usability issues that can only be caught by sitting and watching someone work with your software, and the faster you can identify a rough spot and tweak functionality in response the faster you can create a smooth end-user experience. This has very little to do with LINQ. Just sayin'... I have high hopes for LINQ, and they've little to do with writing code faster. That may well be a nice side-effect, but it's not something that really gets me interested. Nor do i get particularly excited about the potential for building ORMs with LINQ2SQL or ENtityfRAMEWork; that's cool if it works i guess, but ORMs are dull no matter how you slice 'em. LINQ is cool because it brings query language syntax into C#. And C# needs a query language. Needs it the way a fish needs a bicycle - to be precise, the way a fish being chased by a much larger fish needs a turbo-powered aquatic bicycle designed with fish ergonomics in mind and guided by pure aquatic vertebrate fear. The fish doesn't know it needs the bicycle, but that's why the Schwimm Bicycle Company hires so many "technology evangelists". The fish will love 'em once they have 'em. uh, that last paragraph sucked. Lemme try again... LINQ is cool because it brings explicit queries into C#. It brings a me
having played a bit with LINQ i have to heartily disagree with you ... it serves no real purpose imho other than as another layer between my code and the actual data i'm a programmer whose job it is to design and implement systems that can scale to very large numbers and handle lots of data ... efficiently ... so the user doesn't soend 5 minutes waiting for something to happen on the screen ... the more layers we have in between us and the actual "bizness end" of things the worse that gets we are supposed to be able to write queries ... if we can't then we shouldn't be writing systems that require us to write queries because we obviously don't understand the problem domain well enough to do a good job just mho
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
This discussion of Linq got me thinking about other "new" technology and tools and IDE improvements that were supposed to make developers lives easier and in nearly every case it seems they result in mediocre developers being able to generate code faster at the expense of the end user with bloated software or slower software or software with crazy dependencies etc. I contend that anything that is billed as making life easier for developers and does anything more than helping them write the code the way they always have should be taken with a 400 pound grain of salt and carefully examined to see if it actually brings any benefit to the END USER of the software (which is the whole point of writing software often forgotten by developers too in love with their tools).
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
The only part of the IT ecosystem that doesn't follow Moore's law is the developer - so one day, big dumb coding will be the only sensible way to do. We're not there yet (obviously) but technologies such as LINQ are a step in the right direction.
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
-
having played a bit with LINQ i have to heartily disagree with you ... it serves no real purpose imho other than as another layer between my code and the actual data i'm a programmer whose job it is to design and implement systems that can scale to very large numbers and handle lots of data ... efficiently ... so the user doesn't soend 5 minutes waiting for something to happen on the screen ... the more layers we have in between us and the actual "bizness end" of things the worse that gets we are supposed to be able to write queries ... if we can't then we shouldn't be writing systems that require us to write queries because we obviously don't understand the problem domain well enough to do a good job just mho
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
l a u r e n wrote:
having played a bit with LINQ i have to heartily disagree with you ... it serves no real purpose imho other than as another layer between my code and the actual data
You're referring to LINQ to SQL, right? LINQ itself is just a set of C# extension methods (in the System.Linq namespace).
l a u r e n wrote:
i'm a programmer whose job it is to design and implement systems that can scale to very large numbers and handle lots of data ... efficiently ... so the user doesn't soend 5 minutes waiting for something to happen on the screen ... the more layers we have in between us and the actual "bizness end" of things the worse that gets
So... do you embed calls to stored procs right inside your pages/forms? ;P
My latest C# extension method: public static bool In<T>(this T value, params T[] values) { return values.Any(v => v.Equals(value)); } Example: bool valid = answer.In("Yes", "No", "Dunno");
-
having played a bit with LINQ i have to heartily disagree with you ... it serves no real purpose imho other than as another layer between my code and the actual data i'm a programmer whose job it is to design and implement systems that can scale to very large numbers and handle lots of data ... efficiently ... so the user doesn't soend 5 minutes waiting for something to happen on the screen ... the more layers we have in between us and the actual "bizness end" of things the worse that gets we are supposed to be able to write queries ... if we can't then we shouldn't be writing systems that require us to write queries because we obviously don't understand the problem domain well enough to do a good job just mho
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
-
This discussion of Linq got me thinking about other "new" technology and tools and IDE improvements that were supposed to make developers lives easier and in nearly every case it seems they result in mediocre developers being able to generate code faster at the expense of the end user with bloated software or slower software or software with crazy dependencies etc. I contend that anything that is billed as making life easier for developers and does anything more than helping them write the code the way they always have should be taken with a 400 pound grain of salt and carefully examined to see if it actually brings any benefit to the END USER of the software (which is the whole point of writing software often forgotten by developers too in love with their tools).
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
John C wrote:
I contend that anything that is billed as making life easier for developers and does anything more than helping them write the code the way they always have should be taken with a 400 pound grain of salt and carefully examined to see if it actually brings any benefit to the END USER of the software
100% totally agree.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
John C wrote:
I contend that anything that is billed as making life easier for developers and does anything more than helping them write the code the way they always have should be taken with a 400 pound grain of salt and carefully examined to see if it actually brings any benefit to the END USER of the software (which is the whole point of writing software often forgotten by developers too in love with their tools).
:shrug: Well, sure. I mean, that's just healthy skepticism - taste and see before you chow down... That said, as comfortable and productive as i am with my trusty ol' C++ compiler and thin Win32 wrappers, i can't ignore the benefits that HTML+JS UIs... or even WinForms UIs in some cases... can contribute both to me and my users. IMHO, the biggest benefit to be found is in tools that let you quickly implement and demonstrate features or changes to a user - the best looking paper prototype won't ever come close to flushing out the sorts of subtle usability issues that can only be caught by sitting and watching someone work with your software, and the faster you can identify a rough spot and tweak functionality in response the faster you can create a smooth end-user experience. This has very little to do with LINQ. Just sayin'... I have high hopes for LINQ, and they've little to do with writing code faster. That may well be a nice side-effect, but it's not something that really gets me interested. Nor do i get particularly excited about the potential for building ORMs with LINQ2SQL or ENtityfRAMEWork; that's cool if it works i guess, but ORMs are dull no matter how you slice 'em. LINQ is cool because it brings query language syntax into C#. And C# needs a query language. Needs it the way a fish needs a bicycle - to be precise, the way a fish being chased by a much larger fish needs a turbo-powered aquatic bicycle designed with fish ergonomics in mind and guided by pure aquatic vertebrate fear. The fish doesn't know it needs the bicycle, but that's why the Schwimm Bicycle Company hires so many "technology evangelists". The fish will love 'em once they have 'em. uh, that last paragraph sucked. Lemme try again... LINQ is cool because it brings explicit queries into C#. It brings a me
... ...... d(O.O)b Anyway, having had the luxury of .NET doing a lot of the obnoxious work for me (though, I have to say, actually implementing IEnumerable does have some advantages over a for loop when you're making your own classes) and the, erm, "experience" of untangling/deciphering/gutting a lot of horribly bad and inexplicably functional code... it really is a lot like driving on the highway compared to flying a plane. Pretty much anyone can get a driver's license, and every time someone comes up with something to make driving (or some other part of life... like keeping in touch with your #*&$@(*# Aunt Ethel) easier all it will do is give the numpties one more way to cause a big headache for everyone else. The thing is, it *does* make it nice that I can hop in the car and drive to the next town to do a little shopping instead of having to learn how to fly there and file my flight plan and all that junk, especially when the departments I work for want me to pick something up *yesterday*. Similarly, it is nice to be able to throw together a UI in about 5 minutes (ugly as sin, but still, it's there and usable and I can have semi-complex input like a data grid for little fuss) rather than having to handle all the fun things it can take to do "the old way." Especially when our client departments keep changing the calculations on their reports so often we don't have time to worry about rearranging the display because we're too busy re-writing our logic. So, I don't think it's a bad thing to save developers time, because it gives us a bigger percentage of our time to work on the stuff our customers care about (the calculations and data). The real problem that I see with "lowering the bar" is not that it makes it easier for people who shouldn't be coding to code, but that it means the people in charge of hiring coders have to learn how to figure out who knows what they're doing, and who googled up some examples, pasted them together in a monolithic source file, and called it their grand unified program for inventory management at their previous employer. The idiots have always been there, it is just getting so you can't spot them as easily.
-
having played a bit with LINQ i have to heartily disagree with you ... it serves no real purpose imho other than as another layer between my code and the actual data i'm a programmer whose job it is to design and implement systems that can scale to very large numbers and handle lots of data ... efficiently ... so the user doesn't soend 5 minutes waiting for something to happen on the screen ... the more layers we have in between us and the actual "bizness end" of things the worse that gets we are supposed to be able to write queries ... if we can't then we shouldn't be writing systems that require us to write queries because we obviously don't understand the problem domain well enough to do a good job just mho
"mostly watching the human race is like watching dogs watch tv ... they see the pictures move but the meaning escapes them"
l a u r e n wrote:
we are supposed to be able to write queries ... if we can't then we shouldn't be writing systems that require us to write queries because we obviously don't understand the problem domain well enough to do a good job
Right, yeah. I kinda rambled on a bit and missed the point i'd intended to make, which was that, IMHO, a good many programmers have an easier time writing queries than they do writing code to implement queries. So LINQ kicks in and lets them query everything in more or less the same way they're accustom to querying a database.
l a u r e n wrote:
the more layers we have in between us and the actual "bizness end" of things the worse that gets
:shrug: Yeah, abstractions hurt, especially when they appear to change the nature of the system they abstract from - that goes for LINQ or SQL or... just about anything written to .NET or Java... You can't just read a block of code and make a fair guess as to what the CPU will be doing while it runs (or even how many CPUs will be running it...), you need to understand how the abstraction works, where there be dragons and oceans pouring off the edge into nothingness, how the rest of the system is constructed... etc. If you can't live with that, you drop a level. Eventually, you end up writing custom data structures and memory allocators in C. Which is fine, if that's really the level you need.
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
-
Man, you should do marketing! Personally I don't have that strong an opinion on Vista yet... I have a minor negative bias because some noob removed the up button in windows explorer (may his testies burn in hell eternally).
Wout
-
... ...... d(O.O)b Anyway, having had the luxury of .NET doing a lot of the obnoxious work for me (though, I have to say, actually implementing IEnumerable does have some advantages over a for loop when you're making your own classes) and the, erm, "experience" of untangling/deciphering/gutting a lot of horribly bad and inexplicably functional code... it really is a lot like driving on the highway compared to flying a plane. Pretty much anyone can get a driver's license, and every time someone comes up with something to make driving (or some other part of life... like keeping in touch with your #*&$@(*# Aunt Ethel) easier all it will do is give the numpties one more way to cause a big headache for everyone else. The thing is, it *does* make it nice that I can hop in the car and drive to the next town to do a little shopping instead of having to learn how to fly there and file my flight plan and all that junk, especially when the departments I work for want me to pick something up *yesterday*. Similarly, it is nice to be able to throw together a UI in about 5 minutes (ugly as sin, but still, it's there and usable and I can have semi-complex input like a data grid for little fuss) rather than having to handle all the fun things it can take to do "the old way." Especially when our client departments keep changing the calculations on their reports so often we don't have time to worry about rearranging the display because we're too busy re-writing our logic. So, I don't think it's a bad thing to save developers time, because it gives us a bigger percentage of our time to work on the stuff our customers care about (the calculations and data). The real problem that I see with "lowering the bar" is not that it makes it easier for people who shouldn't be coding to code, but that it means the people in charge of hiring coders have to learn how to figure out who knows what they're doing, and who googled up some examples, pasted them together in a monolithic source file, and called it their grand unified program for inventory management at their previous employer. The idiots have always been there, it is just getting so you can't spot them as easily.
Thelly wrote:
The idiots have always been there, it is just getting so you can't spot them as easily.
Naw, it's still easy. Ask 'em to describe, in detail, the difference between C and Pascal calling conventions. If they don't know, then they suck. :-\
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
-
Man, you should do marketing! Personally I don't have that strong an opinion on Vista yet... I have a minor negative bias because some noob removed the up button in windows explorer (may his testies burn in hell eternally).
Wout
I know what you mean about the up button, that annoyed me as well, I used to use it heavily, until I realized the breadcrumb thing works even better. I'm not shilling for Microsoft, I'm only going by my personal experience. :)
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
-
Wrong. I really like Vista, it's the best windows operating system to date. I know this because I've been using it as my only o.s. for development on my computer since it was released and I've taken the time to learn about all the new improvements in it and most importantly I've tested it on identical hardware and it runs all my apps I need much faster than XP. I really like the fact that it's the first windows OS to actually use *all* the resources on my computer and not waste them as prior windows o.s. did by leaving lot's of ram unused etc.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
John C wrote:
it's the best windows operating system to date.
I second that. Give it sufficient memory and it rocks. Follow the established design rules and the UAC won't bother you much. And it is both faster and more robust than XP. My XP system is on an extended holiday now. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Fixturized forever. :confused:
-
... ...... d(O.O)b Anyway, having had the luxury of .NET doing a lot of the obnoxious work for me (though, I have to say, actually implementing IEnumerable does have some advantages over a for loop when you're making your own classes) and the, erm, "experience" of untangling/deciphering/gutting a lot of horribly bad and inexplicably functional code... it really is a lot like driving on the highway compared to flying a plane. Pretty much anyone can get a driver's license, and every time someone comes up with something to make driving (or some other part of life... like keeping in touch with your #*&$@(*# Aunt Ethel) easier all it will do is give the numpties one more way to cause a big headache for everyone else. The thing is, it *does* make it nice that I can hop in the car and drive to the next town to do a little shopping instead of having to learn how to fly there and file my flight plan and all that junk, especially when the departments I work for want me to pick something up *yesterday*. Similarly, it is nice to be able to throw together a UI in about 5 minutes (ugly as sin, but still, it's there and usable and I can have semi-complex input like a data grid for little fuss) rather than having to handle all the fun things it can take to do "the old way." Especially when our client departments keep changing the calculations on their reports so often we don't have time to worry about rearranging the display because we're too busy re-writing our logic. So, I don't think it's a bad thing to save developers time, because it gives us a bigger percentage of our time to work on the stuff our customers care about (the calculations and data). The real problem that I see with "lowering the bar" is not that it makes it easier for people who shouldn't be coding to code, but that it means the people in charge of hiring coders have to learn how to figure out who knows what they're doing, and who googled up some examples, pasted them together in a monolithic source file, and called it their grand unified program for inventory management at their previous employer. The idiots have always been there, it is just getting so you can't spot them as easily.
Thelly wrote:
the people in charge of hiring coders have to learn how to figure out who knows what they're doing, and who googled up some examples, pasted them together in a monolithic source file, and called it their grand unified program for inventory management at their previous employer.
this has always been true for anyone hiring anyone. that is the point of a hiring process, to figure out who knows what they are doing and who is faking it.
----------------------------------------------------------- "When I first saw it, I just thought that you really, really enjoyed programming in java." - Leslie Sanford
-
The only part of the IT ecosystem that doesn't follow Moore's law is the developer - so one day, big dumb coding will be the only sensible way to do. We're not there yet (obviously) but technologies such as LINQ are a step in the right direction.
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
No cubicle farm software factory ever put out a package of software that could hold a candle to something out of a small shop with top notch developers who understand the whole business and technical process from top to bottom. Nearly every aid and tool and convenience thing to come out in recent years has been aimed squarely at the cubicle farm, that's not a good thing in my opinion.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
-
John C wrote:
I contend that anything that is billed as making life easier for developers and does anything more than helping them write the code the way they always have should be taken with a 400 pound grain of salt and carefully examined to see if it actually brings any benefit to the END USER of the software (which is the whole point of writing software often forgotten by developers too in love with their tools).
:shrug: Well, sure. I mean, that's just healthy skepticism - taste and see before you chow down... That said, as comfortable and productive as i am with my trusty ol' C++ compiler and thin Win32 wrappers, i can't ignore the benefits that HTML+JS UIs... or even WinForms UIs in some cases... can contribute both to me and my users. IMHO, the biggest benefit to be found is in tools that let you quickly implement and demonstrate features or changes to a user - the best looking paper prototype won't ever come close to flushing out the sorts of subtle usability issues that can only be caught by sitting and watching someone work with your software, and the faster you can identify a rough spot and tweak functionality in response the faster you can create a smooth end-user experience. This has very little to do with LINQ. Just sayin'... I have high hopes for LINQ, and they've little to do with writing code faster. That may well be a nice side-effect, but it's not something that really gets me interested. Nor do i get particularly excited about the potential for building ORMs with LINQ2SQL or ENtityfRAMEWork; that's cool if it works i guess, but ORMs are dull no matter how you slice 'em. LINQ is cool because it brings query language syntax into C#. And C# needs a query language. Needs it the way a fish needs a bicycle - to be precise, the way a fish being chased by a much larger fish needs a turbo-powered aquatic bicycle designed with fish ergonomics in mind and guided by pure aquatic vertebrate fear. The fish doesn't know it needs the bicycle, but that's why the Schwimm Bicycle Company hires so many "technology evangelists". The fish will love 'em once they have 'em. uh, that last paragraph sucked. Lemme try again... LINQ is cool because it brings explicit queries into C#. It brings a me
Shog9 wrote:
uh, that last paragraph sucked. Lemme try again...
My first thought was to ask what you were smoking. ;P
-
Shog9 wrote:
uh, that last paragraph sucked. Lemme try again...
My first thought was to ask what you were smoking. ;P
-
This discussion of Linq got me thinking about other "new" technology and tools and IDE improvements that were supposed to make developers lives easier and in nearly every case it seems they result in mediocre developers being able to generate code faster at the expense of the end user with bloated software or slower software or software with crazy dependencies etc. I contend that anything that is billed as making life easier for developers and does anything more than helping them write the code the way they always have should be taken with a 400 pound grain of salt and carefully examined to see if it actually brings any benefit to the END USER of the software (which is the whole point of writing software often forgotten by developers too in love with their tools).
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
Absolutely. That should be the eventual benchmark for introducing anything in the build environment. Sometimes it's hard to measure, but it should always be attempted. In our case, LINQ did bring signficant benefit to our end users, but only if time is a factor. It allowed us to quickly work with our data and present things to the user in useful ways. If we had to hand code much of the object querying, they would have missed out on a number of really handy features due to time constaints. So for us - it was a win. If we had to rely on it for the core of our data processing - then I would say it would have been a failure. Other useful things for us DevExpress - this was by far our biggest win in terms of features and time. Reflector - Without this, there are a couple of vital features I simply would not have been able to implement, or wasted two weeks trying. WPF - This was a big loser for us. We threw it out very early on in the prototyping process. It would have delayed our release significantly, and would not have brought any significantly useful functionality for our users. The one part that may have benefited - a diagram with icons and arrows, was easier and quicker to develop with GDI+ with our current skillset. Adding WPF also made our application load about 10 seconds slower on our target PC running XP. Insert Sad Smiley here. SpreadsheetGear - Wow. This was an amazing product. We tried to embed Excel instances in our application and it was a dismal failure as soon as we wanted to show two spreadsheets at once. SpreasheetGear to the rescue! We've got a whole mish mash of good and bad results, but it's always the result for the end user that counts. If we can get a working product to them 3 months sooner because of a combination of language changes and libraries, it's a big win for us, and a big win for customers. If in that three months we can spend adding even more useful functionality, then its a super bonus win.
-
Absolutely. That should be the eventual benchmark for introducing anything in the build environment. Sometimes it's hard to measure, but it should always be attempted. In our case, LINQ did bring signficant benefit to our end users, but only if time is a factor. It allowed us to quickly work with our data and present things to the user in useful ways. If we had to hand code much of the object querying, they would have missed out on a number of really handy features due to time constaints. So for us - it was a win. If we had to rely on it for the core of our data processing - then I would say it would have been a failure. Other useful things for us DevExpress - this was by far our biggest win in terms of features and time. Reflector - Without this, there are a couple of vital features I simply would not have been able to implement, or wasted two weeks trying. WPF - This was a big loser for us. We threw it out very early on in the prototyping process. It would have delayed our release significantly, and would not have brought any significantly useful functionality for our users. The one part that may have benefited - a diagram with icons and arrows, was easier and quicker to develop with GDI+ with our current skillset. Adding WPF also made our application load about 10 seconds slower on our target PC running XP. Insert Sad Smiley here. SpreadsheetGear - Wow. This was an amazing product. We tried to embed Excel instances in our application and it was a dismal failure as soon as we wanted to show two spreadsheets at once. SpreasheetGear to the rescue! We've got a whole mish mash of good and bad results, but it's always the result for the end user that counts. If we can get a working product to them 3 months sooner because of a combination of language changes and libraries, it's a big win for us, and a big win for customers. If in that three months we can spend adding even more useful functionality, then its a super bonus win.
To Phil's response about WPF, he is correct. My organization tried it and the learning curve was too steep. So, we decided to go with Infragistics, which has a set of forms controls that could easily look like WPF controls. It is an expensive package (about $1500 US per developer), but we get our UIs up and running much faster. Go to Infragistics.com and look up NetAdvantage for .NET.
-
Absolutely. That should be the eventual benchmark for introducing anything in the build environment. Sometimes it's hard to measure, but it should always be attempted. In our case, LINQ did bring signficant benefit to our end users, but only if time is a factor. It allowed us to quickly work with our data and present things to the user in useful ways. If we had to hand code much of the object querying, they would have missed out on a number of really handy features due to time constaints. So for us - it was a win. If we had to rely on it for the core of our data processing - then I would say it would have been a failure. Other useful things for us DevExpress - this was by far our biggest win in terms of features and time. Reflector - Without this, there are a couple of vital features I simply would not have been able to implement, or wasted two weeks trying. WPF - This was a big loser for us. We threw it out very early on in the prototyping process. It would have delayed our release significantly, and would not have brought any significantly useful functionality for our users. The one part that may have benefited - a diagram with icons and arrows, was easier and quicker to develop with GDI+ with our current skillset. Adding WPF also made our application load about 10 seconds slower on our target PC running XP. Insert Sad Smiley here. SpreadsheetGear - Wow. This was an amazing product. We tried to embed Excel instances in our application and it was a dismal failure as soon as we wanted to show two spreadsheets at once. SpreasheetGear to the rescue! We've got a whole mish mash of good and bad results, but it's always the result for the end user that counts. If we can get a working product to them 3 months sooner because of a combination of language changes and libraries, it's a big win for us, and a big win for customers. If in that three months we can spend adding even more useful functionality, then its a super bonus win.
I like your thinking and agree with it entirely. We too place a heavy value on anything we can buy or incorporate and don't need to write from scratch. Time to market is very important to us because it get's things into our customer's hands much more quickly and frees up our time to work on the stuff that's really important and matters to the end user (like their feature requests etc). Many years ago just starting out we had to write a lot of the "plumbing" type stuff like a custom web server we wrote from scratch, now there is so much out there it really frees up the developer to be creative and write much better software for the end user that can focus on their tasks they need to accomplish and react quickly when changes need to be made to improve upon it.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson