VS2008 Launch: So who do YOU believe? | The Coffeehouse

irascian
Irascible Ian

From an article on the Visual Studio 2008 launch:

"...it's a lot of stuff to take in all at once.

"There are so many new and upgraded features in VS 2008 that it's hard for enterprise developers to assimilate them all," notes Jennings. "I think it's going to result in more specialization in enterprise-level developers, because no one can be an expert now in all of these different technologies -- WPF, WCF, WF and the new LINQ-related features."

Jay Roxe, Microsoft's group product manager for Visual Studio, sees it differently: "The amount of technology that people need to learn has gone down dramatically because we now have these great designers," he says, adding that Microsoft is releasing a lot of educational content in terms of presentations, demos and white papers. "This will be something that's integrated into all of our launch efforts and will be available from all of our Web sites, and that's when we'll start tying together the various technologies."

Personally I find it very worrying that the group product manager's opinion seems so completely at variance with that of all the developers I work with. I'm definitely with the first guy, so is there anyone here who's drinking the same KoolAid as Jay Roxe and seriously think that "the amount of technology that people need to learn has gone down dramatically". WTF!

In other news has anybody managed to go to the HeroesHappenHere virtual Launch and NOT get user-unfriendly SIlverlight errors when clicking on the "Join in now" button. I've seen a lot of reports that it's broken so went to have a look myself and yup sure enough "Silverlight error message ErrorCode 2202 ErrorType:RuntimeError Message: AG_E_RUNTIME_FINDNAME MethodName txtLoginBackgrounElement4c01".

Oh well, it's only the "biggest launch event Microsoft are going to have this year".

I like Microsoft and the people I've met who work there, and get annoyed constantly trying to defend them left, right and centre. But too often there are times like this where frankly it just seems like they can't organise a you-know-what in a brewery. The "Vista compatible" farce looks like it's going to totally blow up in Microsoft's face given the recently leaked emails and experiences like the launch web site don't instill any kind of confidence at all.

Do you agree, or am I just being too cranky again?

I want to believe Microsoft, I really do, but for pities sake sort your wretched QA out!

EDITED TO ADD: Link to original article here

numedia

I suppose from a product manager's viewpoint, the number of things a user needs to learn has decreased since the quote sited "designers" as the magical element. But in reality, the amount of things that a common developer needs to know these days has dramatically went UP. And who cares if there are designers. While they do help speed some activities up, that's all they generally do: speed some activities up. The programmer still needs to know the how's and why's behind the technology. Using Expression Web is fine, but you will never make good web sites unless you actually know and understand HTML.

ZippyV
Fired Up

I got in yesterday and managed to see a part of the presentation.

I agree that there are way too many new technologies being released as part of .net (and don't forget asp.net). Not only that but in the future we will also see new features with every new version of every technology.
For a couple of these, WCF and WF, I don't see why and when I should use them. It's becoming more difficult to choose the right technology for the right job and that confuses me.

Larsenal
ready to give an answer

I was at the launch event in LA, and I was thinking, "Geez... I haven't even tackled a lot of what they were pushing at the last launch event like this." I agree with ZippyV. We probably just need to start becoming more specialized. Unfortunately, in small shops where you wear all the dev hats, this isn't always possible.

harumscarum
out of memory

Larsenal wrote:
Unfortunately, in small shops where you wear all the dev hats, this isn't always possible.

This is what I see most at a lot of the places I work. It would be hard to adopt some of these new MS techonologies because there would be no one on the customer staff to support it.

cheong

I have a thought that there'll be negative impact by further lowering the bar to programming.

I think that there will be a lot of people who "think" they can code apply for various programming job, but in fact they don't have enough understands behind the scene to work with other programmers.

It'd probably become disastrous for companies that do not require working programmers to conduct technical interview before hiring.

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

cheong wrote:
I have a thought that there'll be negative impact by further lowering the bar to programming.

I think that there will be a lot of people who "think" they can code apply for various programming job, but in fact they don't have enough understands behind the scene to work with other programmers.

It'd probably become disastrous for companies that do not require working programmers to conduct technical interview before hiring.

This isn't any different to how it's always been.

If a company gets a duff employee because their interview procedure didn't ask the right questions, then they have only themselves to blame.

TimP

cheong wrote:
I have a thought that there'll be negative impact by further lowering the bar to programming.

I think this has probably been said in every generation since compilers were first introduced. While I agree to a point, should a VB programmer need to know how looping and conditionals are implemented at the assembly level? Where do you draw the line?

cheong

TimP wrote:

I think this has probably been said in every generation since compilers were first introduced. While I agree to a point, should a VB programmer need to know how looping and conditionals are implemented at the assembly level? Where do you draw the line?

I think they really need to know about the tools/components they are using, like what is it best for, and what they shouldn't use it for. (In this discussion, language itself and structuring like OO are also counted as tools)

I think I've seen one VB applications that contains single form, that has twenty-something tab pages and thousands of controls on it...... Many of the pages would be best moved out to something named "dialog"...

And think about the people who just want their forms be set "topmost" without any apparent reason except "it looks cool"...

Someone who just create objects but never remove reference from it (it'll automatically be freed on most occasions when "out of scope") hits trouble when trying to use some "unmanaged resources"...

The examples continues... While I'd welcome these "safety nets" and convenience be given, they'd also arguably encourage careless style of coding, and that's something not good.

Lowering the bar would allow more "get the work done" type of coders come in, and discourages developing "properly thought" applications. (If "properly thought" types needs 2 days to design and write the application, "get the work done" type would probably need only one. And your boss say that "The junior do things faster than you senior, aren't you shamed?" Would you be pressed to rush? While this probably won't happen at large companies, it occurs pretty frequently in smaller ones. All they want is getting the cash earlier, ease of maintainance is often neglected until customer complains.)

TimP

I agree with that, cheong.

(warning: rant ahead)

My personal pet peeve is people who are so tied to IDEs that they don't know how to perform simple tasks like compiling source code to an object module, linking object modules, debugging a running program with a standalone debugger, or other fundamental software development tasks without an IDE to do it for them. Also people who "rate" languages based on the quality of the IDE. If you're going to say C# is better than Java, don't say it's because Visual Studio is better than NetBeans or Eclipse, that has nothing to do with the merits of the language.

BlackTiger
If you stumbled and fell down, it doesn't mean yet, that you're going in the wrong direction.

Regarding "AG_E_RUNTIME_XXX"... As I said in my post - this is "silverlight hell"...

Site doesn't works with "SL 1.1". It's "SL 1.0" only. Uninstall SL from your PC and install "1.0" "a single one official version on SL".

I think... Number and amount of technologies grown. And it's just impossible to learn them all. Ofcoz, I can "learn" a little bit here, a little bit there, and there, and there... But it's imposible to become a true specialist in ALL technologies... If someody thinks he is "a Specialists" and "knows everything" - he is liar.

irascian
Irascible Ian

BlackTiger wrote:
Regarding "AG_E_RUNTIME_XXX"... As I said in my post - this is "silverlight hell"...

Site doesn't works with "SL 1.1". It's "SL 1.0" only. Uninstall SL from your PC and install "1.0" "a single one official version on SL".

I think... Number and amount of technologies grown. And it's just impossible to learn them all. Ofcoz, I can "learn" a little bit here, a little bit there, and there, and there... But it's imposible to become a true specialist in ALL technologies... If someody thinks he is "a Specialists" and "knows everything" - he is liar.

I only have Silverlight 1.0 installed.

I made a point of NOT installing 1.1 because I don't install ANY alpaha's, beta's or CTPs on my main PC that I use for browsing etc - been burnt way too many times in the past with beta's that leave behind debris that break the RTM or RTW version (I install any alphas betas or CTPs I want to look at in a virtual PC that I can happily trash without affecting my Email, RSS feeds and main apps that are RTM and solid and reliable).

I've just checked in the Vista Control Panel "Programs and Features" and sure enough there's only one "Silverlight" installed (whereas when you install 1.1 I seem to recall you get two entries with 1.1 sort of connected to the main 1.0 install such that you have to uninstall 1.1 before you can uninstall 1.0)

Ian

Dr Herbie
Horses for courses

The 'designers mean you don't have to learn the details' argument is fine for simple coding, but as soon as you step off the beaten track (which never happens in demos given by product managers, I've noticed) you need to know the underlying framework.

WPF can be used much like WinForms in VS2008; drag a button onto the form designer, give it a name, double-click to add a button click handler and add your code.

But as soon as you move away from the 'drag-and-drop' programming model (as soon as you get a 'real world' problem) you need to understand the WPF framework and the 'philosophy' of how it works.

I've decided to learn WPF, WCF and WWF as a mental exercise (to try and reverse the rot I seem to be suffering), but I don't expect to use it for my day job.

Herbie

Yggdrasil
Pour me a cab, 'cause I can't drink no more.

I don't see "lowering the bar" as any different than having Home Improvement videos and household power tools available for me. I know that I can go and get a drill to hang my new shelves on the wall, but I'll still go to a real workman if I want a nightstand made.

Easy designers, simpler IDEs are like Black and Decker - they let a layman get simple tasks done without learning how to operate real machines. This means that a finance department or a small busieness can have a power user build some Excel macros, or an Access DB, or a simple VB.NET app, without having to go through corporate IT or outsource a developer. It'll be an amateur attempt, and any craftsman will shake his head at the ugly drilling and shoddy work and christ-why-is-it-all-skewed-couldn't-he-use-a-level-it's-so-simple?!, but it'll solve the business' need.

And a business has to know that for a billing system they should go to a real software house, just like a home owner should know to call a plumber when his pipe bursts.

EDIT: I lost myself in my analogies and forgot to make my point:

Many of us here, if not most, are professional software developers. We build complex systems. We are craftsmen. We want to know and we need to know how our tools work.
But we are not the whole market for Microsoft's development tools. I don't even know if we're the majority of the market. I think that better market segmentation - different tools for different segments - could be a good idea, but I don't know how to divide it at that point.

irascian
Irascible Ian

TimP wrote:

cheong wrote: I have a thought that there'll be negative impact by further lowering the bar to programming.

I think this has probably been said in every generation since compilers were first introduced. While I agree to a point, should a VB programmer need to know how looping and conditionals are implemented at the assembly level? Where do you draw the line?

Amen to that! I'm not suggesting you let a "hobbyist" lose on an Enterprise application. But it's scary how many of what I'd consider to be the best developers I've worked with "stumbled" into their career from elsewhere through the hobbyist route rather than (like me) through a formal University degree-lead route. So I think lowering the bar can often be a good thing!

Before blowdart says it, yeah University was many, many years ago before many people knew what a University was, let alone a computer Tongue Out

(and when the sort of work you did in 'data processing" would not be considered at all appropriate to what I do now).

blowdart
Peek-a-boo

irascian wrote:

Before blowdart says it, yeah that was many, many years ago before many people knew what a University was, let alone a computer (and when the sort of work you did in 'data processing" would not be considered at all appropriate to what I do now).

You can't do automatic data processing on a sliderule grandpa

Dr Herbie
Horses for courses

irascian wrote:

TimP wrote:

cheong wrote: I have a thought that there'll be negative impact by further lowering the bar to programming.

I think this has probably been said in every generation since compilers were first introduced. While I agree to a point, should a VB programmer need to know how looping and conditionals are implemented at the assembly level? Where do you draw the line?

Amen to that! I'm not suggesting you let a "hobbyist" lose on an Enterprise application. But it's scary how many of what I'd consider to be the best developers I've worked with "stumbled" into their career from elsewhere through the hobbyist route rather than (like me) through a formal University degree-lead route. So I think lowering the bar can often be a good thing!

++

I came to the industry through being a hobbyist (I'm a zoologist, for crying out loud!), but I'm now a senior developer and project lead.

There is a difference, however between lowering the bar to entry (a good thing) and saying "Look, designers mean you don't have to learn so much!"

Herbie

irascian
Irascible Ian

blowdart wrote:

irascian wrote:
Before blowdart says it, yeah that was many, many years ago before many people knew what a University was, let alone a computer (and when the sort of work you did in 'data processing" would not be considered at all appropriate to what I do now).

You can't do automatic data processing on a sliderule grandpa

You know what's REALLY scary about that statement?

That when I did Maths A level we were actually allowed to use slide-rules (and I did!). Calculators weren't allowed in the exam because in those days "calculator" meant a big noisy, metallic thing with a handle and rotary dials!

Excuse me while I just go back to my zimmer frame and cry Sad

eagle

I believe notepad is still an option....

irascian
Irascible Ian

Dr Herbie wrote:

irascian wrote:

TimP wrote:

cheong wrote: I have a thought that there'll be negative impact by further lowering the bar to programming.

I think this has probably been said in every generation since compilers were first introduced. While I agree to a point, should a VB programmer need to know how looping and conditionals are implemented at the assembly level? Where do you draw the line?

Amen to that! I'm not suggesting you let a "hobbyist" lose on an Enterprise application. But it's scary how many of what I'd consider to be the best developers I've worked with "stumbled" into their career from elsewhere through the hobbyist route rather than (like me) through a formal University degree-lead route. So I think lowering the bar can often be a good thing!

++

I came to the industry through being a hobbyist (I'm a zoologist, for crying out loud!), but I'm now a senior developer and project lead.

There is a difference, however between lowering the bar to entry (a good thing) and saying "Look, designers mean you don't have to learn so much!"

Herbie

That's what I find so scary about the way that original quote I highlighted comes across. If someone within Microsoft responsible for Visual Studio at the "group" level really has drunk the KoolAid so much that they believe that statement to be true then they have totally lost touch with reality in my view. And if they're driving what's actually done that's very bad news for all of us.

I think that if I get a chance I'm going to ask ScottGu what he thinks the "average" totally overwhelmed web developer should be concentrating on as a priority: the "Microsoft's going all ALT.NET on me" world (MVC framework etc) or "Shiny new technology stuff world" (Silverlight 2).

I see this morning that they've already renamed Blend 2 to Blend 2.5 even before the follow-on to Blend 1 is out of beta. Madness!

And the Unity IoC (which I think only became available as a CTP a week or so ago) is going RTM in two weeks. Can you believe the sort of quality we can expect from that 'rush to market' approach (oh well, at least there's a refresh planned for April where it and Ent Lib 4.0 are brought together).

cheong

Regarding WPF, how many software companies do you think will embrance it?

While it's true that it can coexist with ordinary WinForms, for those project supervisors it means new thing to learn that has little to gain for them (anything important that can be done on WPF that cannot be done on WinForm?). If the supervisor choose not to learn it, anyone introducing WPF forms/control to the source would seems to be polluting the source base for him/her. (Project leader have to be able to read and review the code, they cannot review something they don't know. Having someone don't know WPF to review code contains WPF is introducing hole in review) If I were them, the only sensible thing to do is to reject any motivation of using WPF in their application (In similar sense that Microsoft does not allow Easter Eggs in their application).

For someone suggest that the supervisor should be replaced, it isn't very sensible to fire an experienced supervisor for not knowing something your company can live without. Argument about WPF is easy to learn is irrelevant because we IT workers have infinite list of technologies to learn already, we don't really want to add something to the list that have little gain for us.

staceyw
Before C# there was darkness...

I think it is and will always be the "last mile" problem. MS has built some great highways with WCF and WPF, but have not finished the last mile. Sure you can go 100mph once you get on the highway, but you will be slugging through snow at 10mph until you get on the highway. The abstractions still need to be comprehended before you go fast. Take WPF, as yet, does not include the standard controls you need like data grid view and others. So you have to stop and find a 3rd party control and use that and spend another couple days, etc, etc. Take WCF. If I don't use it in a month, I am almost back to ground zero. Sure they included a UI tool, but that really does not help much over the xml config file as it looks like a property bag. There is no visual context. That only comes with a lot more work on UI abstractions - which are the very expensive and time consuming last mile. Even if apis are higher level, there still is a lot of knobs to learn how to use. So in general, I think you have to know as much or more.

objectinator
no mind

cheong wrote:

And your boss say that "The junior do things faster than you senior, aren't you shamed?" Would you be pressed to rush? While this probably won't happen at large companies, it occurs pretty frequently in smaller ones. All they want is getting the cash earlier, ease of maintainance is often neglected until customer complains.)

Amen, brother! I've experienced a similar situation like the one you're describing. By bypassing all the "red tape" of properly structured OOP design, for instance, they think they can produce the solution quicker. While they could maybe produce a quicker mock up of what is required, the "red tape" that holds everything together and that allows you to eventually more quickly and easily stick new pieces together is suddenly missing from their quick and dirty solution...what an allegory to the rabbit and tortoise scenario...lol

cheong

objectinator wrote:

Amen, brother! I've experienced a similar situation like the one you're describing. By bypassing all the "red tape" of properly structured OOP design, for instance, they think they can produce the solution quicker. While they could maybe produce a quicker mock up of what is required, the "red tape" that holds everything together and that allows you to eventually more quickly and easily stick new pieces together is suddenly missing from their quick and dirty solution...what an allegory to the rabbit and tortoise scenario...lol

The race would only exist if there's 2 companies/teams building the same product, so you don't usually see there in real life.

Rather than that, I'd say "Destruction (of code structure) always works faster than construction (of code structure) (when coding)". Tongue Out

Try comment out the parts in parenthesis to see how ironic it is... Wink

objectinator
no mind

cheong wrote:

objectinator wrote:
Amen, brother! I've experienced a similar situation like the one you're describing. By bypassing all the "red tape" of properly structured OOP design, for instance, they think they can produce the solution quicker. While they could maybe produce a quicker mock up of what is required, the "red tape" that holds everything together and that allows you to eventually more quickly and easily stick new pieces together is suddenly missing from their quick and dirty solution...what an allegory to the rabbit and tortoise scenario...lol

The race would only exist if there's 2 companies/teams building the same product, so you don't usually see there in real life.

Rather than that, I'd say "Destruction (of code structure) always works faster than construction (of code structure) (when coding)".

Try comment out the parts in parenthesis to see how ironic it is...

Well said. Nuff said. Big Smile