|
Reflections on the .NET platform
Tech Forum - Dr. Nitin Paranjpe
 As
you know, .NET as a platform is a completely different way of thinking
about and coding applications. Everything has become much more structured,
object-oriented and flexible. However, some things in application
development have not changed—it’s just that the .NET infrastructure
has provided more versatile and thoughtful methodologies to handle
the following age-old requirements:
- Customers needs
- Backend databases
- COM+
- Bandwidth
- Internet Information Service (IIS)
- Operating system
Everyone is learning .NET
nuances with a lot of excitement and enthusiasm. That’s great. But
while doing so we should not lose track of the basics.
The .NET paradox
Here is an interesting paradox.
The .NET platform simplifies Web as well as Windows development.
Tasks take shorter time, reuse is more, code written is less and
so on. Customers are not expected to know details of .NET but they
definitely are aware that .NET makes software development faster.
That means the same project developed on regular COM or ASP should
be costlier than .NET development. But look at the IT companies.
Projects being developed on .NET (which is the current fashion)
are typically charged at a higher rate and customers do not even
ask for a comparative quote on older technologies!
All developers across vendors
are still not as familiar with .NET as they are with older technologies
like COM, ASP, etc. So the first customer-level project will always
involve some R&D, some trial and error, leading to comparatively
less optimal code. Even the technical guidelines and best practices
currently prevailing in .NET today are still maturing and evolving.
So how do we reconcile this paradox? The platform is great but its
current utilisation is driven more by excitement than knowledge.
Where is the real benefit?
The real difference between
earlier development tools and .NET is the cohesiveness and maturity
of the platform. Earlier tools had evolved in bits and pieces to
accommodate user interface enhancements, the Web, XML, interoperability,
reuse and so on. What .NET achieves is a jump rather than incremental
value addition. To justify the utilisation of this technological
jump to customers, we need to show them a substantial elevation
in the business benefits.
Does anyone think of this
while creating a response for RFPs (Request For Proposals)? If the
customer has asked for .NET as the platform—just estimate the effort
and submit the quote. If the customer leaves the platform to you,
push .NET and quote. Where is the incremental business value-add?
Do you really think the customer is bothered about the technicalities
of whether you have a true object-oriented language or whether you
have a common language runtime? Customers want their work done at
a value that is reasonably proportional with the business value
generated. That’s it. If a customer were shown an ASP based page
and told that it was written in ASPX, would they be able to make
out the underlying technology?
The correct approach
Am I criticising unnecessarily?
Am I trying to devalue .NET as a platform? Am I trying to get attention
by making controversial statements? No. Not at all. All that I am
trying to highlight is that a having a great set of features and
a very productive development platform is just a good beginning.
But not the end. The end result should be measured not by developer
excitement and increased demand (and salaries) of .NET developers.
It should be measured by analysing the extent to which additional
business value was generated for customers by utilising new/ improved/
revolutionary features of the .NET platform.
Whether the customer demands
this type of audit or not is immaterial. As an IT vendor or company,
all of us should ask this question to ourselves.
The point is, just by learning
new syntax of .NET and getting enamoured by it or by feeling great
about our newly earned knowledge, no customer is going to benefit.
In this article, I propose
a new approach to learning .NET (or any other topic for that matter),
which I feel should be followed by technologists. The objectives
of this approach are as follows:
- To ensure that the learning of
new features is not limited to just increasing technical knowledge
but is translated into customer-level benefits.
- No technology can be used in isolation.
While learning a new technology, we also need to think about
other ingredients and their impact.
- Think of real life scenarios.
Feature v/s benefit
Learning technical features
is easy. The average techie learns these features very fast. They
however stop at that learning. It is important to understand that
end users are NOT interested in technical features. They want business
value and benefits. Therefore, it is important to continue learning
a particular feature till you can envisage its business value. The
business value may be tangible at the user level or may be transparent
to users. But it has to be known to you while learning. More importantly,
you need to document your perception of the business value that
can be generated out of particular set of features. While you are
learning a new product, you may not have a real project in front
of you. But that should not stop you from thinking ahead and finding
usable scenarios.
Think of the larger picture
All of us have gone through
scenarios where a proof-of-concept pilot based upon some latest
technology worked perfectly, but it failed miserably when the same
process was attempted in production environment. Such results are
due to the fact that we tend to forget all the other pieces of the
puzzle while learning new things. We concentrate on new things and
assume that these will work by themselves. We tend to forget that
although this particular technology may be new, it has to work with
many things that are old and existing. This interaction may or may
not be automatic. We need to ensure that the new piece of the puzzle
integrates with existing infrastructure in the appropriate manner.
I have seen too many examples of this in the classic problem of
data crunching.
All companies need to crunch
data from various sources. All sorts of methods are used here. The
most primitive of these may be getting ASCII files and merging them
manually using Excel. The most automated may be using Data Transformation
Services and other ETL (Extract, Transform and Load) tools. The
funniest part is that most of these processes are automated in a
very inefficient manner, irrespective of the tool used. This type
of paradox occurs because people only think of the tool at hand
and use it without regard to other constraints.
Real life v/s ‘Hello World’
Most developers think that
they know a new feature, syntax, object, property, etc, when they
read about it, try it in some small sample code and get it to work
there. Even most books and Web content try to show small snippets
of things working. I call it the ‘Hello World’ approach! This gives
you the wrong impression that because the syntax has worked without
any errors, you have understood the topic and you know the stuff
well. Reality, unfortunately, is not even remotely near this notion.
When you actually start working on a real-life project and try to
apply the syntax-level knowledge, many complexities and ambiguities
will always come to light. The real world is bound to be more challenging
than ‘Hello World’! What I am proposing is that even while initial
learning is being done, we should always think of real-life scenarios
rather than small test stubs. There is a huge amount of effort and
thinking that needs to go into converting familiarity with syntax
to sturdy production code.
More value add needs to be shown
Moving to .NET may be exciting
for developers. However, customers do not share that excitement
unless they see some value in it. They just want their work to be
done efficiently. Therefore, while propagating .NET to customers,
it is even more imperative to show incremental and substantial business
value, which was simply not possible to provide in earlier versions
of tools. Nobody is going to change their comfort zone in using
earlier products just for lesser development effort. There has to
be more to it than just that. The incremental value-add is entirely
the responsibility of the developers and architects.
The .NET danger
Why am I giving so much
gyan on all these things? How is it related to learning .NET? It’s
like this. Most products that have been introduced in the past have
been incremental updates. The core has been improved in instalments.
It is easy to grasp incremental change because the base does not
change drastically. You only need to look at "What’s new"
and then filter the list to suit your needs. Typically "What’s
new" adds only 10 percent of new functionality. Now consider
.NET. If you ask "What’s new" in .NET, the list will be
so long that you will soon conclude that asking "What’s old"
would lead to a shorter answer.
With .NET everything has
been revamped. There is no incremental upgrade of existing technology.
Some syntactical elements are still retained but they behave and
work very differently from earlier because the underlying platform
itself has been revamped and made much more mature and wholesome.
This means, if you apply the approach you used to learn VB6 from
VB5 to learning .NET, it will lead to disaster. You need to change
the way you used to design and use applications earlier. You also
need to be much more proactive in applying the new technology to
business scenarios. Let us list the areas that have changed in .NET
as a development platform.
- Base architecture
- Data handling
- Legacy code handling
- Object design
- Error handling
- Interoperability
- Security
- User interface design
- Validation
- Business logic implementation.
This list is by no means
complete. But it is enough to show that practically every aspect
of programming has undergone a revolution. Therefore, unless your
method of approaching and utilising new technology undergoes a revolution,
there will be problems.
Sources of information
I am harping so much on
scenario-based learning and mapping features to business benefits.
But there is an inherent bottleneck here. Where do you get content
of this type? If you have observed carefully—all the technical content
is product-specific and syntax-oriented! It is extremely rare to
find scenario-based technology content. Of course you do find some
case study or a sample application at the end of some books. However,
such applications use only a subset of syntax and features covered
in the entire book. As this type of content is not available easily,
we do not have the skill and habit to think in a usage scenario
oriented manner while learning technology.
Scenario-based learning
After so much explanation
and preaching about how you should learn new technology and specifically
.NET, it would be highly unfair if I did not illustrate it with
an example. It would then be just preaching and no practice. But
do not worry. I preach what I practice. In order to illustrate all
the above-mentioned points, I am going to actually reproduce the
learning process here. As you know, learning occurs while you read,
write code, try out various options, read help, discuss and so on.
To represent all these processes in a static article is difficult.
However, I will still attempt to do so.
SQLCONNECTION object
As an example of this new
way of learning, I have chosen the SQLCONNECTION object in ADO.NET.
Why this particular object? Many reasons:
- Data handling is required for practically
every application.
- Connection object is the first
object you use while handling remote data.
- Effective use of database connections
can drastically improve performance and reduce server load.
- Connection object is a fairly compact
object, in terms of number of properties, events and methods.
However it still is adequate to illustrate all the nuances of
scenario-based learning that I want to highlight.
Here’s the deal. All that
you have to do is to read up/ try out/ learn SQLCONNECTION object
yourself. Do it exactly the way you learn technology usually. No
special effort required. If you feel like it, document anything
you feel is important. Otherwise, you can just read up on all that
the object does. I suggest you cover all properties, methods, events
and overrides. Next week I will give you my version of how I went
about learning the SQLCONNECTION object. I will also tell you the
learning as well as the methodology and approach. Till next time
then… Happy learning!
 |
About the Author:Dr
Nitin Paranjape is the Chairman and MD of Maestros (Mediline).
He is a consultant with many organisations, covering appropriate
technology utilisation, business application of relevant technology,
application architecture and audit as well as knowledge transfer.
He has authored more than 650 articles on various technology-related
subjects. He can be contacted at nitin@mediline.co.in |
|
