ScottGu's Blog - About Technical Debates (and ASP.NET Web Forms and<br>ASP.NET MVC debates in particular)

Attention: We have retired the ASP.NET Community Blogs.<br>Learn more >

[In addition to blogging, I am also now using Twitter<br>for quick updates and to share links. Follow me at: twitter.com/scottgu]

Technical debates are discussed endlessly within the<br>blog-o-sphere/twitter-verse, and they range across every<br>developer community. Each language, framework, tool, and<br>platform inevitably has at least a few going on at any<br>particular point in time.

Below are a few observations I’ve made over the years<br>about technical debates in general, as well as some<br>comments about some of the recent discussions I’ve seen<br>recently about the topic of ASP.NET Web Forms and ASP.NET<br>MVC in particular.

General Observations About Technical Debates

Below are a few general observations independent of any<br>specific technical debate:

a) Developers love to passionately debate and compare<br>languages, frameworks, APIs, and tools.  This is true in<br>every programming community (.NET, Java, PHP, C++, Ruby,<br>Python, etc).  I think you can view these types of<br>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<br>(since passion means people care deeply on both sides of<br>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<br>something. As an opening interview question I sometimes<br>ask people to sort an array of numbers in the most<br>efficient way they can.  Most people don’t do well with<br>it.  This is usually not because they don’t know sort<br>algorithms, but rather because they never think to ask the<br>scenarios and requirements behind it – which is critical<br>to understanding the most efficient way to do it.  How big<br>is the sequence of numbers? How random is the typical<br>number sequence (is it sometimes already mostly sorted,<br>how big is the spread of numbers, are the numbers all<br>unique, do duplicates cluster together)? How parallel is<br>the computer architecture?  Can you allocate memory as<br>part of the sort or must it be constant?  Etc. These are<br>important questions to ask because the most efficient and<br>optimal way to sort an array of numbers depends on<br>understanding the answers.

Whenever people assert that there is only “one right way”<br>to a programming problem they are almost always assuming a<br>fixed set of requirements/scenarios/inputs – which is<br>rarely optimal for every scenario or every developer.  And<br>to state the obvious - most problems in programming are<br>far more complex than sorting an array of numbers.

c) Great developers using bad tools/frameworks can make<br>great apps. Bad developers using great tools/frameworks<br>can make bad apps. Be very careful about making broad<br>assumptions (good or bad) about the quality of the app you<br>are building based on the tools/frameworks used.

d) Developers (good and bad) can grow stronger by<br>stretching themselves and learning new ideas and<br>approaches.  Even if they ultimately don’t use something<br>new directly, the act of learning it can sharpen them in<br>positive ways.

e) Change is constant in the technology industry.  Change<br>can be scary.  Whether you get overwhelmed by change,<br>though, ultimately comes down to whether you let yourself<br>be overwhelmed.  Don’t stress about having to stop and<br>suddenly learn a bunch of new things - rarely do you have<br>to. The best approach to avoid being overwhelmed is to be<br>pragmatic, stay reasonably informed about a broad set of<br>things at a high-level (not just technologies and tools<br>but also methodologies), and have the confidence to know<br>that if it is important to learn a new technology, then<br>your existing development skills will mostly transition<br>and help.  Syntax and APIs are rarely the most important<br>thing anyway when it comes to development – problem<br>solving, customer empathy/engagement, and the ability to<br>stay focused and disciplined on a project are much more<br>valuable.

f) Some guidance I occasionally give people on my team<br>when working and communicating with others:

You will rarely win a debate with someone by telling<br>them that they are stupid - no matter how well<br>intentioned or eloquent your explanation of their IQ<br>problems might be.

There will always be someone somewhere in the world who<br>is smarter than you - don’t always assume that they<br>aren’t in the room with you.

People you interact with too often forget the praise you<br>give them, and too often remember a past insult -  so be<br>judicious in handing them out as they come back to haunt<br>you later.

People can and do change their minds - be open to being<br>persuaded in a debate, and neither gloat nor hold it<br>against someone else if they also change their minds.

g) I always find it somewhat ironic when I hear people<br>complain about programming abstractions not being good.<br>Especially when these complaints are published via blogs –<br>whose content is...