What's "convenient" for the developer is rarely good for the end user
-
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
-
I work for one of those "big companies". Unfortunately, the developers don't have a lot of choice in the matter. I've been here long enough that I've seen us swing to both sides more than once. At the moment, we're in "don't let the developers talk to the customer" mode, which sucks. Problem reports are often third or fourth hand, by which time "button A doesn't work" becomes "the product tried to format the Internet, and keeps refusing to open the pod bay doors".
Software Zen:
delete this;I dont think the statement is necessarily true. I've seen cases when developers made more informed decisions than customers did, and far more informed then ones coming from the management/marketing area. Although it is clear that this is not the right decisional chain, developers can help a lot in the process. They are forced to think for the inner details of the product, which more than often are not covered in project documentation and sometimes happen to contravene with that. For those projects that are not specified with mathematical precision, the developers must be part of the decisional chain, and if they do their job right, what's convenient for them, on long term, is convenient for the customer and viceversa.
Alex C. D.
-
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
Hm... I have divided feelings about your statement. 1.Language sugar (and "cool new stuff")can taste sour, but even the best tools in hands of inexperienced (immature, unskilled...) can do more damage than harm. 2. Job needs to be done, so if the "RAD tax" isn't too high, why not? 3. It's all marketing, something needs to be sold. I'll always chose to work with someone who is too eager to apply "cool new stuff" than with someone who rants about stuff being deprecated since .Net 1.1 (I had to mention it... I worked with person who was lousy company, short fused, always complaining, had no clue what is hidden under the hood and firmly believed to be solid programmer). I believe the true problem is that green programmers are too early thrown in the pot and people rarely read books (excluding Learn X in 21 days and their kind).
Excuse me for my bad grammar, feel free to warn me. Deka
modified on Wednesday, July 30, 2008 4:43 AM
-
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"
<Rodney_Dangerfield_with_a_pocket_protector> Finally, I get some respect... </Rodney_Dangerfield_with_a_pocket_protector>
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
A lot of them already sound like it, so the name would be redundant ... :laugh:
Software Zen:
delete this; -
I dont think the statement is necessarily true. I've seen cases when developers made more informed decisions than customers did, and far more informed then ones coming from the management/marketing area. Although it is clear that this is not the right decisional chain, developers can help a lot in the process. They are forced to think for the inner details of the product, which more than often are not covered in project documentation and sometimes happen to contravene with that. For those projects that are not specified with mathematical precision, the developers must be part of the decisional chain, and if they do their job right, what's convenient for them, on long term, is convenient for the customer and viceversa.
Alex C. D.
In my particular case, I think direct contact with the customer helps rather than hinders in some areas, especially usability. Customers often have specific features in mind when they make requests. After those requests have been filtered through sales, marketing, and engineering management, they often bear little resemblance to the customer's original idea. By the time we implement the feature (which is yet another layer of interpretation), the customer's need often isn't met.
Software Zen:
delete this; -
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:
Luc Pattyn wrote:
Follow the established design rules and the UAC won't bother you much.
Pray tell, what "established design rules?" And whose blog was I supposed to read to get this set of design guidelines? I find the UAC to be a complete PITA, and even more annoying when you try to disable it. I finally figured out the 3 or 4 settings to change to minimize the number of confirmation dialogs I see while retaining the ability to bump my privileges when necessary. Unfortunately, I figured it out accidentally and haven't seen it documented anywhere (correctly), so I have been unable to reproduce the result. :-(
Grim MCDBA, MCSD, MCP+SB SELECT * FROM users WHERE clue IS NOT NULL (0 row(s) affected)
-
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
Realizing that your post is mostly satirical....
Shog9 wrote:
most developers suck at writing code to query their own data
I think this is the key point of your whole diatribe. That being said, I completely fail to understand why anyone could possibly believe that a developer who can't design decent relational data models or write decent SQL code would be any more capable of designing decent domain entity models or writing decent LINQ code.
Grim MCDBA, MCSD, MCP+SB SELECT * FROM users WHERE clue IS NOT NULL (0 row(s) affected)
-
Gary Wheeler wrote:
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'.
You're sooo behind the times! In fact you're dangerously close to sounding like a Neo-Luddite! That was all soooo 1990s, now we're into Web 2.0 and we no longer ask questions. All you need to do is just throw some code against the cloud, hope pray assume it sticks, and then move on to something else! It's all about allowing the user to collaborate with rich socially interactive applications that create content mash-ups and real time distributed intelligence with synergistic use-flows.
¡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
I use some of the neat new stuff, and others I don’t screw with others. I've worked both areas; where I never had contact with the customer and where I worked closely with the customer. When you can work with the customer and they do learn to respect and value your opinion, the end product can become one that they will not like but use successfully. Also have found that maintenance on a collaborated system like this is so much easier.
One day soon, I suppose I should come up with one! Something like: There are times I really miss the old DOS programming days.