Is Whidbey the beginning of the end for the developer ?

[Fresh Air Rider]

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 M.]

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.

 

[Frans Bouma [C# MVP]]

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.

--

 

[Cor Ligthert]

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 M.]

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.

 

[Cor Ligthert]

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.G. Ryan eMVP]

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.

 

[Frans Bouma [C# MVP]]

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


--

 

[Scott M.]

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.

 

[Scott M.]

You can probably click together some class-set and very rough plumbing
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.

 

[Cor Ligthert]

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 Karlsson]

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/

 

[Guest]

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!
***************************

 

[Guest]

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!
***************************

 

[Guest]

I think software factories are a great step. It is better to use the human
mind to figure out problems rather than have people spend time coding the
solution they find. The more of the rote (and even some not so rote) that you
remove from the plate, the more time there is to correctly solve the business
problem.

I love code generation. I have even use tools as strange as Excel to write
repetitive code rather quickly (=CONCATENATE() is very useful).

For the developer, however, making sure that his mind is knowledgeable to
fill in the gaps the tool leaves is paramount. Those with the proper skills
are not replaced by a person with a good mouse skills.


---

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

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

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/

 

[Scott M.]

And also remember that while MS's drag and drop solutions may work, they
tend to write bloated code. Many developers find it easier, in the end,
just writing the functionality from scratch. Myself, I sometimes use the
drag and drop as a starting point and then go back and customize it (and
take lots of it out).

 

[William \(Bill\) Vaughn]

Ha. My mom called me up in 1975 telling me that I needed to find another
career because the new computers could program themselves. Drag and drop
solutions bring development tools to the masses which is good and bad. Over
the years we've seen more and more people without training self-prescribe
their own computer solutions. This has resulted in millions of companies
hip-deep in code written by (what I call) paradevelopers. Some of this code
is just fine. Some is not so good and some is absolutely terrible. IT
departments all over the world are struggling with these "programs" which
are used to manage everything from perfectly benign "junk" data to the most
critical customer or company private information. Can we blame the tools?
Not any more that we can blame the inventor of the chainsaw or socket
wrench. Making it easier for people to do hard stuff more easily is how
money is made. Will drag-and-drop tools like Visual Studio make our jobs
unnecessary? Ah, no... there will always be a need for developers to clean
up after the kids.
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

 

[Bruce Wood]

I have been working in the programming business for 20 years. Just
after I had graduated, I had the same concerns that you do: I had heard
that reports would be so easy to write that managers would be doing it.
SQL was going to make data analysis so easy that clerks could do it.
Programmers were going to be obsolete.

In fact, what happened is what has happened over and over again for the
last 20 years: today's problems because formalized and companies like
Microsoft build drag-and-drop tools to solve those problems so that
anyone can do it. However, far from reducing the workload, this causes
customers (usually business people) to simply raise their expectations.
I'll give you an example from one job I had.

When I arrived on the scene at company B, it took them a week to write,
test, and put a report in production. After a lot of work on re-usable
code and refactoring, we got it down to a half a day. Instead of laying
off most of the team, what happened was that the business users started
dragging out old projects that they had been told were "impossible",
but which were now within reach because of our improving software
technology. By the time I left we were finishing up a project that our
database vendor had told us "couldn't be done," and we were churning
out those tedious reports in a couple of hours.

The problems you're solving today will be drag-and-drop tomorrow, but
all that will happen is that the world will invent new uses for
computers that will require all of your skill to design and implement
solutions. I'm doing things today that I wouldn't even have understood
20 years ago, and the stuff I was doing 20 years ago, like writing
linked list routines and hash table routines now come bundled with
every respectable modern language.

The only bad thing about all of this is that every stitch of code I
write more than 5 years ago is now gone, replaced by newer, better
stuff. This isn't architecture: you don't get to show your kids your
work, particularly not since just as the problems you'll be solving 20
years from now are today's "impossible" problems, the solutions you
were so proud of 20 years ago are today's trivialities.

The belief that programmers will shortly become obsolete is founded in
the mistaken idea that the current problem set is closed, and that all
there is to do is formalize solutions to current problems and we're
done. Or, put another way, that we have already discovered all of the
things for which we could use computers. The now-infamous comment that
the world would need only six or seven computers was based on the same
line of thinking, and it's short-sighted thinking.

I doubt that they heydays of 1998 and 1999 will return, but then I
doubt you'll go hungry.

 

[User]

I have been working in the programming business for 20 years. Just
after I had graduated, I had the same concerns that you do: I had heard
that reports would be so easy to write that managers would be doing it.
SQL was going to make data analysis so easy that clerks could do it.
Programmers were going to be obsolete.

In fact, what happened is what has happened over and over again for the
last 20 years: today's problems because formalized and companies like
Microsoft build drag-and-drop tools to solve those problems so that
anyone can do it. However, far from reducing the workload, this causes
customers (usually business people) to simply raise their expectations.
I'll give you an example from one job I had.

When I arrived on the scene at company B, it took them a week to write,
test, and put a report in production. After a lot of work on re-usable
code and refactoring, we got it down to a half a day. Instead of laying
off most of the team, what happened was that the business users started
dragging out old projects that they had been told were "impossible",
but which were now within reach because of our improving software
technology. By the time I left we were finishing up a project that our
database vendor had told us "couldn't be done," and we were churning
out those tedious reports in a couple of hours.

The problems you're solving today will be drag-and-drop tomorrow, but
all that will happen is that the world will invent new uses for
computers that will require all of your skill to design and implement
solutions. I'm doing things today that I wouldn't even have understood
20 years ago, and the stuff I was doing 20 years ago, like writing
linked list routines and hash table routines now come bundled with
every respectable modern language.

The only bad thing about all of this is that every stitch of code I
write more than 5 years ago is now gone, replaced by newer, better
stuff. This isn't architecture: you don't get to show your kids your
work, particularly not since just as the problems you'll be solving 20
years from now are today's "impossible" problems, the solutions you
were so proud of 20 years ago are today's trivialities.

The belief that programmers will shortly become obsolete is founded in
the mistaken idea that the current problem set is closed, and that all
there is to do is formalize solutions to current problems and we're
done. Or, put another way, that we have already discovered all of the
things for which we could use computers. The now-infamous comment that
the world would need only six or seven computers was based on the same
line of thinking, and it's short-sighted thinking.

I doubt that they heydays of 1998 and 1999 will return, but then I
doubt you'll go hungry.

Some of the "reports" and "programming" of old have become user
spreadsheets.
40 years ago, there was IBM and the seven dwarfs, and how many viable OS's?
A more pertinent question is will there be decent numbers of decent paying
jobs for developers in the developed world.

 

[Rob Labbe \(Lowney\)]

For developers, perhaps things may be tight. For architects, analysts,
etc....

There will always be room for people that can go in to a business, evaluate
their systems and design a new systems to help the business succeed. You'll
never see that role shipped overseas.

Besides, that is the role that pays well anyhow.

--
Rob Labbé, MCP, MCAD, MCSD, MCT
Lead Architect/Trainer
Fidelis

Blog: http://spaces.msn.com/members/roblabbe