About
Technical Debates
Technical debates are discussed
endlessly within the blog-o-sphere/twitter-verse, and they range across every
developer community. Each language, framework, tool, and platform inevitably
has at least a few going on at any particular point in time.
Below are a few observations I’ve made
over the years about technical debates in general, as well as some comments
about some of the recent discussions I’ve seen recently about the topic of
ASP.NET Web Forms and ASP.NET MVC in particular.
General Observations About Technical Debates
Below are a few general observations
independent of any specific technical debate:
a) Developers love to passionately
debate and compare languages, frameworks, APIs, and tools. This is true
in every programming community (ASP.NET , Java, PHP, C++, Ruby, Python, etc).
I think you can view these types of religious technical debates in two ways:
- They are sometimes annoying and often a waste
of time.
- They are often a sign of a healthy and active
community (since passion means people care deeply on both sides of a
debate, and is far better than apathy).
Personally I think both points are
true.
b) There is never only “one right way”
to develop something. As an opening interview question I sometimes ask people
to sort an array of numbers in the most efficient way they can. Most
people don’t do well with it. This is usually not because they don’t know
sort algorithms, but rather because they never think to ask the scenarios and
requirements behind it – which is critical to understanding the most efficient
way to do it. How big is the sequence of numbers? How random is the
typical number sequence (is it sometimes already mostly sorted, how big is the
spread of numbers, are the numbers all unique, do duplicates cluster together)?
How parallel is the computer architecture? Can you allocate memory as
part of the sort or must it be constant? Etc. These are important
questions to ask because the most efficient and optimal way to sort an array of
numbers depends on understanding the answers.
Whenever people assert that there is
only “one right way” to a programming problem they are almost always assuming a
fixed set of requirements/scenarios/inputs – which is rarely optimal for every
scenario or every developer. And to state the obvious - most problems in
programming are far more complex than sorting an array of numbers.
c) Great developers using bad
tools/frameworks can make great apps. Bad developers using great
tools/frameworks can make bad apps. Be very careful about making broad
assumptions (good or bad) about the quality of the app you are building based
on the tools/frameworks used.
d) Developers (good and bad) can grow
stronger by stretching themselves and learning new ideas and approaches.
Even if they ultimately don’t use something new directly, the act of learning
it can sharpen them in positive ways.
e) Change is constant in the technology
industry. Change can be scary. Whether you get overwhelmed by
change, though, ultimately comes down to whether you let yourself be
overwhelmed. Don’t stress about having to stop and suddenly learn a bunch
of new things - rarely do you have to. The best approach to avoid being
overwhelmed is to be pragmatic, stay reasonably informed about a broad set of
things at a high-level (not just technologies and tools but also
methodologies), and have the confidence to know that if it is important to
learn a new technology, then your existing development skills will mostly
transition and help. Syntax and APIs are rarely the most important thing
anyway when it comes to development – problem solving, customer
empathy/engagement, and the ability to stay focused and disciplined on a
project are much more valuable.
f) Some guidance I occasionally give
people on my team when working and communicating with others:
- You will rarely win a debate with someone by
telling them that they are stupid - no matter how well intentioned or
eloquent your explanation of their IQ problems might be.
- There will always be someone somewhere in the
world who is smarter than you - don’t always assume that they aren’t in
the room with you.
- People you interact with too often forget the
praise you give them, and too often remember a past insult - so be
judicious in handing them out as they come back to haunt you later.
- People can and do change their minds - be open
to being persuaded in a debate, and neither gloat nor hold it against
someone else if they also change their minds.
g) I always find it somewhat ironic
when I hear people complain about programming abstractions not being
good. Especially when these complaints are published via blogs – whose
content is displayed using HTML, is styled with CSS, made interactive with
JavaScript, transported over the wire using HTTP, and implemented on the server
with apps written in higher-level languages, using object oriented garbage
collected frameworks, running on top of either interpreted or JIT-compiled byte
code runtimes, and which ultimately store the blog content and comments in
relational databases ultimately accessed via SQL query strings. All of
this running within a VM on a hosted server – with the OS within the VM
partitioning memory across kernel and user mode process boundaries, scheduling
work using threads, raising device events using signals, and using an abstract
storage API fo disk persistence. It is worth keeping all of that in mind
the next time you are reading a “ORM vs Stored Procedures” or “server controls
– good/bad?” post. The more interesting debates are about what the best
abstractions are for a particular problem.
h) The history of programming debates
is one long infinite loop – with most programming ideas having been solved
multiple times before. And for what it’s worth – many of the problems we
debate today were long ago solved with LISP and Smalltalk. Ironically, despite
pioneering a number of things quite elegantly, these two languages tend not be
used much anymore. Go figure.
a) Web Forms and MVC are two approaches
for building ASP.NET apps. They are both good choices. Each can be the “best
choice” for a particular solution depending on the requirements of the
application and the background of the team members involved. You can build
great apps with either. You can build bad apps with either. You are not a
good or bad developer depending on what you choose. You can be absolutely great
or worthless using both.
b) The ASP.NET and Visual Studio teams
are investing heavily in both Web Forms and MVC. Neither is going
away. Both have major releases coming in the months ahead. ASP.NET
4 includes major updates to Web Forms (clean ClientIDs and CSS based markup
output, smaller ViewState, URL Routing, new data and charting controls, new
dynamic data features, new SEO APIs, new VS designer and project improvements,
etc, etc). ASP.NET 4 will also ship with ASP.NET MVC 2 which also includes
major updates (strongly typed helpers, model validation, areas, better
scaffolding, Async support, more helper APIs, etc, etc). Don’t angst
about either being a dead-end or something you have to change to. I
suspect that long after we are all dead and gone there will be servers
somewhere on the Internet still running both ASP.NET Web Forms and ASP.NET MVC
based apps.
c) Web Forms and MVC share far more
code/infrastructure/APIs than anyone on either side of any debate about them
ever mentions - Authentication, Authorization, Membership, Roles, URL Routing,
Caching, Session State, Profiles, Configuration, Compilation, .aspx pages,
.master files, .ascx files, Global.asax, Request/Response/Cookie APIs, Health
Monitoring, Process Model, Tracing, Deployment, AJAX, etc, etc, etc. All
of that common stuff you learn is equally valid regardless of how you construct
your UI. Going forward we’ll continue to invest heavily in building core ASP.NET features that work for both Web Forms and MVC (like the URL Routing, Deployment,
Output Caching, and DataAnnotations for Validation features we are adding with
ASP.NET 4).
d) I often find debates around
programming model appropriateness and abstractions a little silly. Both Web
Forms and MVC are programming web framework abstractions, built on top of a
broader framework abstraction, programmed with higher level programming
languages, running on top of a execution engine abstraction that itself is
running on top of a giant abstraction called an OS. What you are creating
with each is HTML/CSS/JavaScript (all abstractions persisted as text,
transmitted over HTTP – another higher level protocol abstraction).
The interesting question to debate is
not whether abstractions are good or not – but rather which abstractions
feels most natural to you, and which map best to the
requirements/scenarios/developers of your project.
e) As
part of that we will be posting more end to end tutorials/content (for both Web
Forms and MVC). We will also be providing tutorials and guidance that
will help developers quickly evaluate both the Web Forms and MVC approach,
easily learn the basics about how both work, and quickly determine which one
feels best for them to use. This will make it easy for developers new to ASP.NET, as well as developers who already know either Web Forms or MVC, to
understand and evaluate the two approaches and decide which they want to use.
f) Decide on a project about whether
you want to use Web Forms or MVC and feel good about it. Both can be good
choices. Respect the choices other people make – the choice they have
made is also hopefully a good one that works well for them. Keep in mind
that in all likelihood they know a lot more about their own business/skills
than you do. Likewise you hopefully know a lot more about your own
business/skills than they do.
g) Share ideas and best practices with
others. That is a big part of what blogs, forums, listservs and community
is all about. What makes them work great is when people know that their
ideas aren’t going to be ripped to shreds, and that they will be treated with
respect. Be constructive, not snarky. Teach, don’t lecture. Remember there
is always someone else out there who you can also learn from.
On
ScottGu's Blog 24th jan 2010
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5