Is Whidbey the beginning of the end for the developer ?

Hi Everyone

I have just been getting up to speed on the forthcoming ASP.Net 2.0
(Whidbey) that Microsoft is releasing some time this year.

It all looks great but I was a bit concerned that it aims to reduce
the amount of code that needs to be written by the developer by 70%.

The new GridView control will be "far simpler to use, requires less
code, and provides far more power than the DataGrid Control".

After working extremely hard to get my Computer Science degree and
investing my own hard earnt money heavily in MSDN subscriptions and
programming books etc just to keep my skills up to date, I began to
wonder if it had all been worthwhile now that the forthcoming ASP.Net
2.0 (Whidbey) seems to be abstracting much of the techniques that I
had learnt to "hand code".

For instance, I was particularly pleased with my implementation of
Roles Based Forms Authentication that I had mastered in C# but now I
understand that it will all be wasted now that this functionality will
be covered by the new Membership classes.

I fully understand that by definition, IT is a constantly evolving
industry but it does make me worry that the very systems that we use
to improve business efficiency could one day make the role of the
qualified developer redundant.

The way things are going, the office junior will be able to do all the
stuff that the highly qualified and trained developer once did and the
developers will be ignored because the higher wages that they rightly
attract will no longer be justified.

Maybe this is what Microsoft are working towards or maybe I'm just a
Luddite.

Please accept my appologies for the cross-posting but it's just
something that I feel very stongly about and is of equal importance to
each group.

Scott
Sat Jan 01 11:16:16 CST 2005

I think to some degree your concerns are justified, but remember that there
will always be a need to customize out of the box solutions. This is where
and why there will always be a need for developers.


"Fresh Air Rider" <Fresh_Air_Rider@Hotmail.com> wrote in message
news:556722cb.0501010857.1eb38850@posting.google.com...
> Hi Everyone
>
> I have just been getting up to speed on the forthcoming ASP.Net 2.0
> (Whidbey) that Microsoft is releasing some time this year.
>
> It all looks great but I was a bit concerned that it aims to reduce
> the amount of code that needs to be written by the developer by 70%.
>
> The new GridView control will be "far simpler to use, requires less
> code, and provides far more power than the DataGrid Control".
>
> After working extremely hard to get my Computer Science degree and
> investing my own hard earnt money heavily in MSDN subscriptions and
> programming books etc just to keep my skills up to date, I began to
> wonder if it had all been worthwhile now that the forthcoming ASP.Net
> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
> had learnt to "hand code".
>
> For instance, I was particularly pleased with my implementation of
> Roles Based Forms Authentication that I had mastered in C# but now I
> understand that it will all be wasted now that this functionality will
> be covered by the new Membership classes.
>
> I fully understand that by definition, IT is a constantly evolving
> industry but it does make me worry that the very systems that we use
> to improve business efficiency could one day make the role of the
> qualified developer redundant.
>
> The way things are going, the office junior will be able to do all the
> stuff that the highly qualified and trained developer once did and the
> developers will be ignored because the higher wages that they rightly
> attract will no longer be justified.
>
> Maybe this is what Microsoft are working towards or maybe I'm just a
> Luddite.
>
> Please accept my appologies for the cross-posting but it's just
> something that I feel very stongly about and is of equal importance to
> each group.

Frans
Sat Jan 01 12:13:10 CST 2005

Fresh Air Rider wrote:
> I have just been getting up to speed on the forthcoming ASP.Net 2.0
> (Whidbey) that Microsoft is releasing some time this year.
>
> It all looks great but I was a bit concerned that it aims to reduce
> the amount of code that needs to be written by the developer by 70%.
>
> The new GridView control will be "far simpler to use, requires less
> code, and provides far more power than the DataGrid Control".
>
> After working extremely hard to get my Computer Science degree and
> investing my own hard earnt money heavily in MSDN subscriptions and
> programming books etc just to keep my skills up to date, I began to
> wonder if it had all been worthwhile now that the forthcoming ASP.Net
> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
> had learnt to "hand code".

Programming is not 'typing code' but working out algorithms and create
programs which represent these algorithms in executable form. How that
is done, is up to the tools you use. So this will not change, the tools
you use will change, over time.

Do not feel offended, but I don't think you need a CS degree to write
ASP.NET gui's as it's fairly straightforward once you know the tricks
and pitfalls.

What is way more important is the layer stack right below the GUI: the
BL layer and the BL facade layer (or gui facade, depending on which way
you look at it). The vast majority of your application's code is in
there, or better: the vast majority of interesting code is in there.

> For instance, I was particularly pleased with my implementation of
> Roles Based Forms Authentication that I had mastered in C# but now I
> understand that it will all be wasted now that this functionality will
> be covered by the new Membership classes.

As with everything MS gives out: the more it is detailed and towards
'end user stuff' (i.e. the farther you get away from a 'framework'), the
more the following rule is applicable: "The Microsoft Way or Your Own
Way". Often there are situations in which the MS provided controls don't
work very well and you need own code or customize the provided controls.

Don't be fooled by the slick demos with drag-n-drop 'RAD'
'programming': professional software is often written in total different
ways than the demos show you. This is for a reason: demos are meant to
sell stuff, not to teach you best practises.

> I fully understand that by definition, IT is a constantly evolving
> industry but it does make me worry that the very systems that we use
> to improve business efficiency could one day make the role of the
> qualified developer redundant.

this will never be the case. Programming is not related to typing, but
to thinking.

> The way things are going, the office junior will be able to do all the
> stuff that the highly qualified and trained developer once did and the
> developers will be ignored because the higher wages that they rightly
> attract will no longer be justified.

no, the office monkey will do the dull gui-stuff while you will be
doing business logic components and the controller layers below the GUI,
which are not created by drag-n-drop clicketyclick.

Frans.

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Cor
Sat Jan 01 12:33:33 CST 2005

Hi,

I have seen that this message is posted yesterday in

Microsoft.dotnet.general
Microsoft.dotnet.languages.csharp

To make you attent on it, not in the newsgroup
Microsoft.dotnet.languages.vb

However that is a very unknown little newsgroup, so sending to that has no
sense, while the answers will probably be the same as the answers you got
in the other newsgroups

Just my thought,

Cor

Scott
Sat Jan 01 12:46:06 CST 2005

Just a quick comment:

You mention several times that the business logic is where the work gets
done and that there is no RAD clickety-click for that code. I think what
you missed from the OP was that in Whidbey, there IS RAD for the business
and data layers. In Whidbey, the RAD and drag & drop is greatly improved
for the backend of an application as well as the front.




"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
news:uCO%23c2C8EHA.3076@TK2MSFTNGP15.phx.gbl...
> Fresh Air Rider wrote:
>> I have just been getting up to speed on the forthcoming ASP.Net 2.0
>> (Whidbey) that Microsoft is releasing some time this year.
>>
>> It all looks great but I was a bit concerned that it aims to reduce
>> the amount of code that needs to be written by the developer by 70%.
>>
>> The new GridView control will be "far simpler to use, requires less
>> code, and provides far more power than the DataGrid Control".
>>
>> After working extremely hard to get my Computer Science degree and
>> investing my own hard earnt money heavily in MSDN subscriptions and
>> programming books etc just to keep my skills up to date, I began to
>> wonder if it had all been worthwhile now that the forthcoming ASP.Net
>> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
>> had learnt to "hand code".
>
> Programming is not 'typing code' but working out algorithms and create
> programs which represent these algorithms in executable form. How that is
> done, is up to the tools you use. So this will not change, the tools you
> use will change, over time.
>
> Do not feel offended, but I don't think you need a CS degree to write
> ASP.NET gui's as it's fairly straightforward once you know the tricks and
> pitfalls.
>
> What is way more important is the layer stack right below the GUI: the BL
> layer and the BL facade layer (or gui facade, depending on which way you
> look at it). The vast majority of your application's code is in there, or
> better: the vast majority of interesting code is in there.
>
>> For instance, I was particularly pleased with my implementation of
>> Roles Based Forms Authentication that I had mastered in C# but now I
>> understand that it will all be wasted now that this functionality will
>> be covered by the new Membership classes.
>
> As with everything MS gives out: the more it is detailed and towards 'end
> user stuff' (i.e. the farther you get away from a 'framework'), the more
> the following rule is applicable: "The Microsoft Way or Your Own Way".
> Often there are situations in which the MS provided controls don't work
> very well and you need own code or customize the provided controls.
>
> Don't be fooled by the slick demos with drag-n-drop 'RAD' 'programming':
> professional software is often written in total different ways than the
> demos show you. This is for a reason: demos are meant to sell stuff, not
> to teach you best practises.
>
>> I fully understand that by definition, IT is a constantly evolving
>> industry but it does make me worry that the very systems that we use
>> to improve business efficiency could one day make the role of the
>> qualified developer redundant.
>
> this will never be the case. Programming is not related to typing, but to
> thinking.
>
>> The way things are going, the office junior will be able to do all the
>> stuff that the highly qualified and trained developer once did and the
>> developers will be ignored because the higher wages that they rightly
>> attract will no longer be justified.
>
> no, the office monkey will do the dull gui-stuff while you will be doing
> business logic components and the controller layers below the GUI, which
> are not created by drag-n-drop clicketyclick.
>
> Frans.
>
> --
> ------------------------------------------------------------------------
> Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
> My .NET blog: http://weblogs.asp.net/fbouma
> Microsoft MVP (C#)
> ------------------------------------------------------------------------

Cor
Sat Jan 01 12:50:39 CST 2005

Frans,

When you find some things in my message in this thread strange that it comes
from me.
Change Chmpagne in Wine in your formule from yesterday.

:-)

Cor

W
Sat Jan 01 13:07:03 CST 2005

Scott:

I respectfully disagree. I love Whidbey - I'm heavily involved in the beta
and think it's going to be the coolest thing since sliced bread. However it
simply can not build business and data layers without a programmer or
someone putting thought into it and building it correctly.

Anyone can make an Object - but building solid and powerful classes takes
knowledge and understanding -and experience garnered from making mistakes.

How is Whidbey going to make for instance, a Data Access layer that's
remotable - know what channel to send things through based on my network
topology and whether or not I should use Client or Server activated objects?
What if my business objects need send everything via messages instead of to
a database all of a sudden?

Sure, whidbey and VS.nET make things like this pretty straightforward - but
it still entails thought on someone's part and someone needs to make those
decisions and implement them.

The best analogy I can come up with is this: Look at TurboTax or whatever
other tax software you want. It has functionality to handle virtually the
entire US Tax code. My neighbor is a tax attorney and I think he's pulling
about $150.00 hour doing primarily individual and small business accounts
which could - be done with TurboTax. Are there just that many naive people
out there that are willing to pay him $150.00/hr for stuff that a 30.00
software package can do? No. And we both know that there are thousands of
CPA and tax accountants making much more than $30.00 flat fee to handle tax
stuff that could be done by a software package. Why? Because even though
that software is great - many prefer humans for a whole host of reasons -
but the most important ones is that those professionals know the tax code
and it's interpretations and many cases aren't black and white.

The demand for tax professionals is so much greater than the supply in most
places that the advent of Turbo Tax doesn't hurt them one bit. Not one - it
actually helps them b/c they can also use software to speed up the simple
stuff so they can concentrate on the more complex issues.

So it goes with Software developers and Whidbey.

Whidbey is my friend - it will make my life easier and allow me to do things
quicker and easier - but there's plenty of demand for new stuff and it
won't take anything away from us.

--
W.G. Ryan MVP (Windows Embedded)

TiBA Solutions
www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"Scott M." <s-mar@nospam.nospam> wrote in message
news:e9bvzGD8EHA.3012@TK2MSFTNGP09.phx.gbl...
> Just a quick comment:
>
> You mention several times that the business logic is where the work gets
> done and that there is no RAD clickety-click for that code. I think what
> you missed from the OP was that in Whidbey, there IS RAD for the business
> and data layers. In Whidbey, the RAD and drag & drop is greatly improved
> for the backend of an application as well as the front.
>
>
>
>
> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
> news:uCO%23c2C8EHA.3076@TK2MSFTNGP15.phx.gbl...
> > Fresh Air Rider wrote:
> >> I have just been getting up to speed on the forthcoming ASP.Net 2.0
> >> (Whidbey) that Microsoft is releasing some time this year.
> >>
> >> It all looks great but I was a bit concerned that it aims to reduce
> >> the amount of code that needs to be written by the developer by 70%.
> >>
> >> The new GridView control will be "far simpler to use, requires less
> >> code, and provides far more power than the DataGrid Control".
> >>
> >> After working extremely hard to get my Computer Science degree and
> >> investing my own hard earnt money heavily in MSDN subscriptions and
> >> programming books etc just to keep my skills up to date, I began to
> >> wonder if it had all been worthwhile now that the forthcoming ASP.Net
> >> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
> >> had learnt to "hand code".
> >
> > Programming is not 'typing code' but working out algorithms and create
> > programs which represent these algorithms in executable form. How that
is
> > done, is up to the tools you use. So this will not change, the tools you
> > use will change, over time.
> >
> > Do not feel offended, but I don't think you need a CS degree to write
> > ASP.NET gui's as it's fairly straightforward once you know the tricks
and
> > pitfalls.
> >
> > What is way more important is the layer stack right below the GUI: the
BL
> > layer and the BL facade layer (or gui facade, depending on which way you
> > look at it). The vast majority of your application's code is in there,
or
> > better: the vast majority of interesting code is in there.
> >
> >> For instance, I was particularly pleased with my implementation of
> >> Roles Based Forms Authentication that I had mastered in C# but now I
> >> understand that it will all be wasted now that this functionality will
> >> be covered by the new Membership classes.
> >
> > As with everything MS gives out: the more it is detailed and towards
'end
> > user stuff' (i.e. the farther you get away from a 'framework'), the more
> > the following rule is applicable: "The Microsoft Way or Your Own Way".
> > Often there are situations in which the MS provided controls don't work
> > very well and you need own code or customize the provided controls.
> >
> > Don't be fooled by the slick demos with drag-n-drop 'RAD' 'programming':
> > professional software is often written in total different ways than the
> > demos show you. This is for a reason: demos are meant to sell stuff, not
> > to teach you best practises.
> >
> >> I fully understand that by definition, IT is a constantly evolving
> >> industry but it does make me worry that the very systems that we use
> >> to improve business efficiency could one day make the role of the
> >> qualified developer redundant.
> >
> > this will never be the case. Programming is not related to typing, but
to
> > thinking.
> >
> >> The way things are going, the office junior will be able to do all the
> >> stuff that the highly qualified and trained developer once did and the
> >> developers will be ignored because the higher wages that they rightly
> >> attract will no longer be justified.
> >
> > no, the office monkey will do the dull gui-stuff while you will be doing
> > business logic components and the controller layers below the GUI, which
> > are not created by drag-n-drop clicketyclick.
> >
> > Frans.
> >
> > --
> > ------------------------------------------------------------------------
> > Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
> > My .NET blog: http://weblogs.asp.net/fbouma
> > Microsoft MVP (C#)
> > ------------------------------------------------------------------------
>
>

Frans
Sat Jan 01 13:18:59 CST 2005

Scott M. wrote:
> Just a quick comment:
>
> You mention several times that the business logic is where the work gets
> done and that there is no RAD clickety-click for that code. I think what
> you missed from the OP was that in Whidbey, there IS RAD for the business
> and data layers. In Whidbey, the RAD and drag & drop is greatly improved
> for the backend of an application as well as the front.

If you think that RAD and drag-n-drop will give you a business logic
layer which can manage for example this action:
- new customer purchases 10 products P.
-> you need to add the new customer
-> you need to manage inventory
-> you need to add the order

and perhaps some other things along the lines, you didn't get the point.
Say the actions have to be controlled, by a transaction, perhaps a COM+
transaction because the orders database is a SAP system.

A rad tool can do that? No way. Dragging some classes together in a
designer perhaps looks like developing these kind of components but it
isn't.

This is the kind of BL you have to write by hand, ALWAYS. There is no
RAD tool for this. Everyone who thinks he can click this together using
whidbey is mistaken. You can probably click together some class-set and
very rough plumbing code but that's it.

And make no mistake: the fact that plumbing code is being generated for
you is a GOOD thing, because writing plumbing code is not what you want,
because you want to write the code which represents the application's
*functionality* !

Frans

>
>
>
>
> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
> news:uCO%23c2C8EHA.3076@TK2MSFTNGP15.phx.gbl...
>
>>Fresh Air Rider wrote:
>>
>>>I have just been getting up to speed on the forthcoming ASP.Net 2.0
>>>(Whidbey) that Microsoft is releasing some time this year.
>>>
>>>It all looks great but I was a bit concerned that it aims to reduce
>>>the amount of code that needs to be written by the developer by 70%.
>>>
>>>The new GridView control will be "far simpler to use, requires less
>>>code, and provides far more power than the DataGrid Control".
>>>
>>>After working extremely hard to get my Computer Science degree and
>>>investing my own hard earnt money heavily in MSDN subscriptions and
>>>programming books etc just to keep my skills up to date, I began to
>>>wonder if it had all been worthwhile now that the forthcoming ASP.Net
>>>2.0 (Whidbey) seems to be abstracting much of the techniques that I
>>>had learnt to "hand code".
>>
>>Programming is not 'typing code' but working out algorithms and create
>>programs which represent these algorithms in executable form. How that is
>>done, is up to the tools you use. So this will not change, the tools you
>>use will change, over time.
>>
>>Do not feel offended, but I don't think you need a CS degree to write
>>ASP.NET gui's as it's fairly straightforward once you know the tricks and
>>pitfalls.
>>
>>What is way more important is the layer stack right below the GUI: the BL
>>layer and the BL facade layer (or gui facade, depending on which way you
>>look at it). The vast majority of your application's code is in there, or
>>better: the vast majority of interesting code is in there.
>>
>>
>>>For instance, I was particularly pleased with my implementation of
>>>Roles Based Forms Authentication that I had mastered in C# but now I
>>>understand that it will all be wasted now that this functionality will
>>>be covered by the new Membership classes.
>>
>>As with everything MS gives out: the more it is detailed and towards 'end
>>user stuff' (i.e. the farther you get away from a 'framework'), the more
>>the following rule is applicable: "The Microsoft Way or Your Own Way".
>>Often there are situations in which the MS provided controls don't work
>>very well and you need own code or customize the provided controls.
>>
>>Don't be fooled by the slick demos with drag-n-drop 'RAD' 'programming':
>>professional software is often written in total different ways than the
>>demos show you. This is for a reason: demos are meant to sell stuff, not
>>to teach you best practises.
>>
>>
>>>I fully understand that by definition, IT is a constantly evolving
>>>industry but it does make me worry that the very systems that we use
>>>to improve business efficiency could one day make the role of the
>>>qualified developer redundant.
>>
>>this will never be the case. Programming is not related to typing, but to
>>thinking.
>>
>>
>>>The way things are going, the office junior will be able to do all the
>>>stuff that the highly qualified and trained developer once did and the
>>>developers will be ignored because the higher wages that they rightly
>>>attract will no longer be justified.
>>
>>no, the office monkey will do the dull gui-stuff while you will be doing
>>business logic components and the controller layers below the GUI, which
>>are not created by drag-n-drop clicketyclick.
>>
>>Frans.
>>
>>--
>>------------------------------------------------------------------------
>>Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
>>My .NET blog: http://weblogs.asp.net/fbouma
>>Microsoft MVP (C#)
>>------------------------------------------------------------------------
>
>
>


--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Scott
Sat Jan 01 17:32:29 CST 2005

You misunderstood me. I didn't say that the RAD in Whidbey would replace
the need for developers. In fact, I said the opposite (read my first post
in this thread).

My point was that Frans implied and flat out stated that in Whidbey, there
is no RAD in the business and data layers. My "quick comment" was just to
point out that there, in fact, is. It certainly will need additional code
added to it to make it truly functional, but there is RAD in the back-end.

"W.G. Ryan eMVP" <WilliamRyan@NoSpam.gmail.com> wrote in message
news:eWxsJSD8EHA.1300@TK2MSFTNGP14.phx.gbl...
> Scott:
>
> I respectfully disagree. I love Whidbey - I'm heavily involved in the
> beta
> and think it's going to be the coolest thing since sliced bread. However
> it
> simply can not build business and data layers without a programmer or
> someone putting thought into it and building it correctly.
>
> Anyone can make an Object - but building solid and powerful classes takes
> knowledge and understanding -and experience garnered from making mistakes.
>
> How is Whidbey going to make for instance, a Data Access layer that's
> remotable - know what channel to send things through based on my network
> topology and whether or not I should use Client or Server activated
> objects?
> What if my business objects need send everything via messages instead of
> to
> a database all of a sudden?
>
> Sure, whidbey and VS.nET make things like this pretty straightforward -
> but
> it still entails thought on someone's part and someone needs to make those
> decisions and implement them.
>
> The best analogy I can come up with is this: Look at TurboTax or whatever
> other tax software you want. It has functionality to handle virtually the
> entire US Tax code. My neighbor is a tax attorney and I think he's
> pulling
> about $150.00 hour doing primarily individual and small business accounts
> which could - be done with TurboTax. Are there just that many naive
> people
> out there that are willing to pay him $150.00/hr for stuff that a 30.00
> software package can do? No. And we both know that there are thousands
> of
> CPA and tax accountants making much more than $30.00 flat fee to handle
> tax
> stuff that could be done by a software package. Why? Because even though
> that software is great - many prefer humans for a whole host of reasons -
> but the most important ones is that those professionals know the tax code
> and it's interpretations and many cases aren't black and white.
>
> The demand for tax professionals is so much greater than the supply in
> most
> places that the advent of Turbo Tax doesn't hurt them one bit. Not one -
> it
> actually helps them b/c they can also use software to speed up the simple
> stuff so they can concentrate on the more complex issues.
>
> So it goes with Software developers and Whidbey.
>
> Whidbey is my friend - it will make my life easier and allow me to do
> things
> quicker and easier - but there's plenty of demand for new stuff and it
> won't take anything away from us.
>
> --
> W.G. Ryan MVP (Windows Embedded)
>
> TiBA Solutions
> www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
> "Scott M." <s-mar@nospam.nospam> wrote in message
> news:e9bvzGD8EHA.3012@TK2MSFTNGP09.phx.gbl...
>> Just a quick comment:
>>
>> You mention several times that the business logic is where the work gets
>> done and that there is no RAD clickety-click for that code. I think what
>> you missed from the OP was that in Whidbey, there IS RAD for the business
>> and data layers. In Whidbey, the RAD and drag & drop is greatly improved
>> for the backend of an application as well as the front.
>>
>>
>>
>>
>> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
>> news:uCO%23c2C8EHA.3076@TK2MSFTNGP15.phx.gbl...
>> > Fresh Air Rider wrote:
>> >> I have just been getting up to speed on the forthcoming ASP.Net 2.0
>> >> (Whidbey) that Microsoft is releasing some time this year.
>> >>
>> >> It all looks great but I was a bit concerned that it aims to reduce
>> >> the amount of code that needs to be written by the developer by 70%.
>> >>
>> >> The new GridView control will be "far simpler to use, requires less
>> >> code, and provides far more power than the DataGrid Control".
>> >>
>> >> After working extremely hard to get my Computer Science degree and
>> >> investing my own hard earnt money heavily in MSDN subscriptions and
>> >> programming books etc just to keep my skills up to date, I began to
>> >> wonder if it had all been worthwhile now that the forthcoming ASP.Net
>> >> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
>> >> had learnt to "hand code".
>> >
>> > Programming is not 'typing code' but working out algorithms and create
>> > programs which represent these algorithms in executable form. How that
> is
>> > done, is up to the tools you use. So this will not change, the tools
>> > you
>> > use will change, over time.
>> >
>> > Do not feel offended, but I don't think you need a CS degree to write
>> > ASP.NET gui's as it's fairly straightforward once you know the tricks
> and
>> > pitfalls.
>> >
>> > What is way more important is the layer stack right below the GUI: the
> BL
>> > layer and the BL facade layer (or gui facade, depending on which way
>> > you
>> > look at it). The vast majority of your application's code is in there,
> or
>> > better: the vast majority of interesting code is in there.
>> >
>> >> For instance, I was particularly pleased with my implementation of
>> >> Roles Based Forms Authentication that I had mastered in C# but now I
>> >> understand that it will all be wasted now that this functionality will
>> >> be covered by the new Membership classes.
>> >
>> > As with everything MS gives out: the more it is detailed and towards
> 'end
>> > user stuff' (i.e. the farther you get away from a 'framework'), the
>> > more
>> > the following rule is applicable: "The Microsoft Way or Your Own Way".
>> > Often there are situations in which the MS provided controls don't work
>> > very well and you need own code or customize the provided controls.
>> >
>> > Don't be fooled by the slick demos with drag-n-drop 'RAD'
>> > 'programming':
>> > professional software is often written in total different ways than the
>> > demos show you. This is for a reason: demos are meant to sell stuff,
>> > not
>> > to teach you best practises.
>> >
>> >> I fully understand that by definition, IT is a constantly evolving
>> >> industry but it does make me worry that the very systems that we use
>> >> to improve business efficiency could one day make the role of the
>> >> qualified developer redundant.
>> >
>> > this will never be the case. Programming is not related to typing, but
> to
>> > thinking.
>> >
>> >> The way things are going, the office junior will be able to do all the
>> >> stuff that the highly qualified and trained developer once did and the
>> >> developers will be ignored because the higher wages that they rightly
>> >> attract will no longer be justified.
>> >
>> > no, the office monkey will do the dull gui-stuff while you will be
>> > doing
>> > business logic components and the controller layers below the GUI,
>> > which
>> > are not created by drag-n-drop clicketyclick.
>> >
>> > Frans.
>> >
>> > --
>> > ------------------------------------------------------------------------
>> > Get LLBLGen Pro, productive O/R mapping for .NET:
>> > http://www.llblgen.com
>> > My .NET blog: http://weblogs.asp.net/fbouma
>> > Microsoft MVP (C#)
>> > ------------------------------------------------------------------------
>>
>>
>
>

Scott
Sat Jan 01 17:33:55 CST 2005

>>You can probably click together some class-set and very rough plumbing
>>code but that's it.

And, that's all I was trying to point out. Your comments made it sound as
if you were saying that there is no RAD at all in the BL and DL. There is.







"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
news:uURSQbD8EHA.2568@TK2MSFTNGP11.phx.gbl...
> Scott M. wrote:
>> Just a quick comment:
>>
>> You mention several times that the business logic is where the work gets
>> done and that there is no RAD clickety-click for that code. I think what
>> you missed from the OP was that in Whidbey, there IS RAD for the business
>> and data layers. In Whidbey, the RAD and drag & drop is greatly improved
>> for the backend of an application as well as the front.
>
> If you think that RAD and drag-n-drop will give you a business logic layer
> which can manage for example this action:
> - new customer purchases 10 products P.
> -> you need to add the new customer
> -> you need to manage inventory
> -> you need to add the order
>
> and perhaps some other things along the lines, you didn't get the point.
> Say the actions have to be controlled, by a transaction, perhaps a COM+
> transaction because the orders database is a SAP system.
>
> A rad tool can do that? No way. Dragging some classes together in a
> designer perhaps looks like developing these kind of components but it
> isn't.
>
> This is the kind of BL you have to write by hand, ALWAYS. There is no RAD
> tool for this. Everyone who thinks he can click this together using
> whidbey is mistaken. You can probably click together some class-set and
> very rough plumbing code but that's it.
>
> And make no mistake: the fact that plumbing code is being generated for
> you is a GOOD thing, because writing plumbing code is not what you want,
> because you want to write the code which represents the application's
> *functionality* !
>
> Frans
>
>>
>>
>>
>>
>> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
>> news:uCO%23c2C8EHA.3076@TK2MSFTNGP15.phx.gbl...
>>
>>>Fresh Air Rider wrote:
>>>
>>>>I have just been getting up to speed on the forthcoming ASP.Net 2.0
>>>>(Whidbey) that Microsoft is releasing some time this year.
>>>>
>>>>It all looks great but I was a bit concerned that it aims to reduce
>>>>the amount of code that needs to be written by the developer by 70%.
>>>>
>>>>The new GridView control will be "far simpler to use, requires less
>>>>code, and provides far more power than the DataGrid Control".
>>>>
>>>>After working extremely hard to get my Computer Science degree and
>>>>investing my own hard earnt money heavily in MSDN subscriptions and
>>>>programming books etc just to keep my skills up to date, I began to
>>>>wonder if it had all been worthwhile now that the forthcoming ASP.Net
>>>>2.0 (Whidbey) seems to be abstracting much of the techniques that I
>>>>had learnt to "hand code".
>>>
>>>Programming is not 'typing code' but working out algorithms and create
>>>programs which represent these algorithms in executable form. How that is
>>>done, is up to the tools you use. So this will not change, the tools you
>>>use will change, over time.
>>>
>>>Do not feel offended, but I don't think you need a CS degree to write
>>>ASP.NET gui's as it's fairly straightforward once you know the tricks and
>>>pitfalls.
>>>
>>>What is way more important is the layer stack right below the GUI: the BL
>>>layer and the BL facade layer (or gui facade, depending on which way you
>>>look at it). The vast majority of your application's code is in there, or
>>>better: the vast majority of interesting code is in there.
>>>
>>>
>>>>For instance, I was particularly pleased with my implementation of
>>>>Roles Based Forms Authentication that I had mastered in C# but now I
>>>>understand that it will all be wasted now that this functionality will
>>>>be covered by the new Membership classes.
>>>
>>>As with everything MS gives out: the more it is detailed and towards 'end
>>>user stuff' (i.e. the farther you get away from a 'framework'), the more
>>>the following rule is applicable: "The Microsoft Way or Your Own Way".
>>>Often there are situations in which the MS provided controls don't work
>>>very well and you need own code or customize the provided controls.
>>>
>>>Don't be fooled by the slick demos with drag-n-drop 'RAD' 'programming':
>>>professional software is often written in total different ways than the
>>>demos show you. This is for a reason: demos are meant to sell stuff, not
>>>to teach you best practises.
>>>
>>>
>>>>I fully understand that by definition, IT is a constantly evolving
>>>>industry but it does make me worry that the very systems that we use
>>>>to improve business efficiency could one day make the role of the
>>>>qualified developer redundant.
>>>
>>>this will never be the case. Programming is not related to typing, but to
>>>thinking.
>>>
>>>
>>>>The way things are going, the office junior will be able to do all the
>>>>stuff that the highly qualified and trained developer once did and the
>>>>developers will be ignored because the higher wages that they rightly
>>>>attract will no longer be justified.
>>>
>>>no, the office monkey will do the dull gui-stuff while you will be doing
>>>business logic components and the controller layers below the GUI, which
>>>are not created by drag-n-drop clicketyclick.
>>>
>>>Frans.
>>>
>>>--
>>>------------------------------------------------------------------------
>>>Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
>>>My .NET blog: http://weblogs.asp.net/fbouma
>>>Microsoft MVP (C#)
>>>------------------------------------------------------------------------
>>
>>
>>
>
>
> --
> ------------------------------------------------------------------------
> Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
> My .NET blog: http://weblogs.asp.net/fbouma
> Microsoft MVP (C#)
> ------------------------------------------------------------------------

Cor
Sun Jan 02 03:53:05 CST 2005

Hi,

This discussion is as old as there has been programs.

In the sixties was told that after the begin of the seventies there would
be no programmers more needed because all could be done by end users by
design tools.

Luckily it is mostly stated by non programmers who don't understand what
programs are

Just my thought,

Cor

Joakim
Sun Jan 02 06:59:44 CST 2005

Frans Bouma [C# MVP] wrote:
> Scott M. wrote:
>
>> Just a quick comment:
>>
>> You mention several times that the business logic is where the work
>> gets done and that there is no RAD clickety-click for that code. I
>> think what you missed from the OP was that in Whidbey, there IS RAD
>> for the business and data layers. In Whidbey, the RAD and drag & drop
>> is greatly improved for the backend of an application as well as the
>> front.
>
>
> If you think that RAD and drag-n-drop will give you a business logic
> layer which can manage for example this action:
> - new customer purchases 10 products P.
> -> you need to add the new customer
> -> you need to manage inventory
> -> you need to add the order
>
> and perhaps some other things along the lines, you didn't get the point.
> Say the actions have to be controlled, by a transaction, perhaps a COM+
> transaction because the orders database is a SAP system.
>
> A rad tool can do that? No way. Dragging some classes together in a
> designer perhaps looks like developing these kind of components but it
> isn't.
>
> This is the kind of BL you have to write by hand, ALWAYS. There is
> no RAD tool for this. Everyone who thinks he can click this together
> using whidbey is mistaken. You can probably click together some
> class-set and very rough plumbing code but that's it.
>

And this is a problem, one we ought to have solved by now. Around the
globe developers are writing almost identical BL code as if it is the
first time that problem is solved.

Software Factories [1][2] is an attempt to address this by synthezising
patterns in common problem domains such as CRM, e-commerce etc.

I agree that we will never be able to create our applications using drag
and drop, but we ought to be able to consider a lot of the code we
manually write today as plumbing.

/Joakim

[1] http://msdn.microsoft.com/architecture/overview/softwarefactories/
[2] http://www.softwarefactories.com/

NoSpamMgbworld
Mon Jan 03 12:53:03 CST 2005

The guy who picks his nose in the mail room, but knows how to drag and drop
reall well will find he has a new job. He will ultimately mess up
applications really badly and "experts" will be brought in (some will truly
be advanced coders, while others will be vagabonds with very good poker
faces). Either way, Joe Nosepicker will still have a job as he works for much
less than "true developers".

The run of the mill developer will find his job gone to Joe Nosepicker. He
will be back out on the street with a "will code for food sign" and will
eventually find a lower paying job dragging and dropping, hate life and
ultimately retire to pcik up rat droppings in Botswana. He will spend the
rest of his days lamenting "if I only spent the time to actually learn .NET,
I would be a high paid consultant today instead of a rat pooper scooper."

When nosepicker screws up, the developer with advanced skills will be pulled
in as a very highly paid consultant who is paid to fix Joe's screw ups.

The moral to our story: Spend a bit of time on the side learning to be the
shark. If not, you may end up as shark bait.

******************

I have heard "the end of the developer" story for years. Each time a new
technology comes out, the end of the developer is heralded again by the
doomsayers. As of last count, I have been through at least 4 mythical
Armageddons with Chicken Little standing next to me: "The sky is falling!
Developers are no longer needed!" After introducing him to the Colonel, I go
on learning and find that I can find work through the lean years of the
nosepicker.

The box gets bigger with every new technology, but code generators are not
likely to replace a human mind any time soon.


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************


"Fresh Air Rider" wrote:

> Hi Everyone
>
> I have just been getting up to speed on the forthcoming ASP.Net 2.0
> (Whidbey) that Microsoft is releasing some time this year.
>
> It all looks great but I was a bit concerned that it aims to reduce
> the amount of code that needs to be written by the developer by 70%.
>
> The new GridView control will be "far simpler to use, requires less
> code, and provides far more power than the DataGrid Control".
>
> After working extremely hard to get my Computer Science degree and
> investing my own hard earnt money heavily in MSDN subscriptions and
> programming books etc just to keep my skills up to date, I began to
> wonder if it had all been worthwhile now that the forthcoming ASP.Net
> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
> had learnt to "hand code".
>
> For instance, I was particularly pleased with my implementation of
> Roles Based Forms Authentication that I had mastered in C# but now I
> understand that it will all be wasted now that this functionality will
> be covered by the new Membership classes.
>
> I fully understand that by definition, IT is a constantly evolving
> industry but it does make me worry that the very systems that we use
> to improve business efficiency could one day make the role of the
> qualified developer redundant.
>
> The way things are going, the office junior will be able to do all the
> stuff that the highly qualified and trained developer once did and the
> developers will be ignored because the higher wages that they rightly
> attract will no longer be justified.
>
> Maybe this is what Microsoft are working towards or maybe I'm just a
> Luddite.
>
> Please accept my appologies for the cross-posting but it's just
> something that I feel very stongly about and is of equal importance to
> each group.
>

NoSpamMgbworld
Mon Jan 03 13:09:03 CST 2005

I would both agree and disagree. Look at what the tool is going to do and
make sure you can fill in the gaps it does not and you have nothing to fear.
The key is looking at development as a career and not a job.

The average coder learns only what is necessary to survive. Many of them
will drown when Visual Studio 2005 comes out, as they will be replaceable.

I fix code from people who drag and drop fairly regularly. When you make a
tool any idiot can use, some of the people using the tool will be idiots.
Others will be ignorant, most likely from time constraints or laziness.

But, I can guarantee you that a lot of people will royally screw up .NET 2.0
applications and people who can fix it will always be in demand.

In addition, it is hard to build a box big enough to hold everyone's
desires. Microsoft, quite intelligently I might add, tries to use the 80-20
rule (or 70-30 rule in this case) to solve the majority of problems with
declarative means rather than programatic means. This leaves the problems
outside of the 20% available for the rest of us to solve. If you knowledge
base sits strictly in the 80%, you will likely take a salary cut or lose your
job altogether.

I have been through all sorts of "emergencies". 9/11 slammed IT in
Nashville. I have friends who spent months without a job. In the same time, I
have had to make some minor salary concessions, but the market has, overall,
been very good to me. Why? I am not content to sit on laurels. I spend a lot
of time investing in my career learning new technologies. Result: I have been
unemployed for about a week and a half (total) in the past 3+ years.

Lesson to learn: If you fear the tools are going to replace you, learn
something the tool cannot automagically do.
---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

"Scott M." wrote:

> I think to some degree your concerns are justified, but remember that there
> will always be a need to customize out of the box solutions. This is where
> and why there will always be a need for developers.
>
>
> "Fresh Air Rider" <Fresh_Air_Rider@Hotmail.com> wrote in message
> news:556722cb.0501010857.1eb38850@posting.google.com...
> > Hi Everyone
> >
> > I have just been getting up to speed on the forthcoming ASP.Net 2.0
> > (Whidbey) that Microsoft is releasing some time this year.
> >
> > It all looks great but I was a bit concerned that it aims to reduce
> > the amount of code that needs to be written by the developer by 70%.
> >
> > The new GridView control will be "far simpler to use, requires less
> > code, and provides far more power than the DataGrid Control".
> >
> > After working extremely hard to get my Computer Science degree and
> > investing my own hard earnt money heavily in MSDN subscriptions and
> > programming books etc just to keep my skills up to date, I began to
> > wonder if it had all been worthwhile now that the forthcoming ASP.Net
> > 2.0 (Whidbey) seems to be abstracting much of the techniques that I
> > had learnt to "hand code".
> >