Joshua Arnold

I recently retweeted a comment from Brad Wilson about how much damage WebForms has done to the typical developer’s knowledge of the web. I thought he had summarized it quite while and I wasn’t going to offer my thoughts on the matter but it’s been on my mind for quite a while and I feel like it’s time for me to weigh-in on this situation. It turns out that I have quite a bit to say.

Before I begin, I will note that I have been working with WebForms since the early days and have truly appreciated the rapid rate in which the platform allows you to develop certain applications (or pieces of applications).

The individual adoption of ASP.NET MVC is no easy thing, so it should come as no surprise that an organizational adoption of ASP.NET MVC is not a walk in the park. The WebForms platform does a great job at providing a set of Rapid Application Development tools to get your job done quickly and somewhat easily…depending on the task and the team you’re working with. When you begin running into rendering problems or third-party integration problems, a deeper understanding of the toolset is required and unfortunately most entry and junior-level developers just don’t have it.

Individual Adoption

The transition probably isn’t the same from one person to the next, but I can make some generalizations based on my personal experiences introducing the change and helping through various online communities. These generalizations have been mostly made by helping people transition as they tackle more real-life applications using MVC. As with any new technology, I strongly recommend the “Hello, World!” approach but not everybody agrees with me.

I wanna go fast!

The initial introduction to the concepts seems to go over quite well. You’re not sure if they understand it or just want to get their hands dirty by playing with it. They’re not sure if they understand it either…but it’s a new technology and they’re excited to get their hands dirty.

Where’d my magic go?

The first question is asked: “How do I access my <some control ID> control? It’s not showing up in intellisense.” Be careful here, you’re about to tell them everything they know about the web is a lie!  You carefully deliver the bad news and show them some examples of posting information.

So…I have to reinvent the wheel?

This is a question that I get a lot and it’s taken me a while to understand how to respond to it. Now, it may be different with every person but I’ve found that this question gets asked for a few reasons that all seem to boil down to this: the purpose of the ASP.NET MVC framework has not been properly explained and a proper comparison between MVC and WebForms has not been made. It should be clear that MVC is an alternative to WebForms (not a replacement) and that the entire development approach is different.

“But I could do this in like 5 minutes in WebForms!”

Sure, that might be true. In fact, your organization might not be suited for MVC development and this might be the right time for you to realize that. However, if you’re like me then you know that while the ramp up time might be a little rocky, it’s going to benefit you in the long run. So you explain the differences one more time and kindly ask them to just “give it a shot.”

Where’d my magic go? (Again)

“OK, so then how would I access my <some control ID> control?”

Even though you’ve explained it quite a few times by now, you’re bound to be asked again. In fact, don’t be too surprised if this continues to happen for quite some time.

As with the adoption of anything, you need a roadmap. You need clear goals and a vision to follow. The road is rocky at first and you’re going to need that vision to keep you moving.

Organizational Adoption

The damage has moved far past just affecting developers. I think an interesting shift in management’s understanding of .NET has happened in the past year or two. As management gets more technically savvy and buzzwords come and go, it’s more important than ever that management understands the goals of the roadmap you’ve set out. If you’re about to pitch using a new development approach that requires intense training and ramp up time then you’d be better be prepared for battle.

Sounds simple…right?

Let’s take a look at an application that is ideal for WebForms development. We need an application for internal-use only that will take in some input through a couple of data entry screens, run some basic calculations, and display the data in some sort of table. Sounds simple, right? It sure is. It’s so simple that I can write the steps out as follows:

1. Figure out what data needs to be entered and throw together a database
2. Create some pages and drag over some textboxes
3. Wire up the code and give it a test run
4. Drag over a grid view and wire it up

That’s all there is to it. There was no real need for design, no complex requirements, or any real thought needed to make this work. You’re happy because it took you about an hour and management is happy is also because it took you about an hour. There’s no need to discuss the details on what’s actually happening under the hood because it gets the job done and does it quite well.

Can’t you just drag and drop something?

We can create simple applications very quickly and effectively. This is where we have been for a long time and management has caught on to that. They’ve undoubtedly heard the term “control” get thrown around on more than one occasion and probably understood it to mean something quite different than what it really is. You see, WebForms does such a damn good job at simplifying things that you can’t blame them for thinking that a control is more powerful than it really is. Just think about the wide variety of controls that we have at our finger tips:

1. Simple textboxes
2. Login controls
3. Grid controls
4. Reporting controls
5. etc.

What’s my point?

We’ve created it all: the good, the bad, and the ugly. We’ve built application after application and have done our best to incorporate testing as part of our daily routine but it hasn’t been easy. We’ve developed frameworks to help us test faster, but our budgets haven’t been fond of creating and/or maintaining those tests. ASP.NET MVC provides a brand new way of approaching development. We can finally incorporate Test Driven Development at the presentation-logic level and begin giving a higher level of transparency into the stability of our applications. It’s pretty clear why a lot of us are excited about this.

The pushback that we will be experiencing will come from two levels: developers and management. You will be dealing with real issues when developers pushback if they’re responding the way that I’ve mentioned here. MVC is so different than the world that WebForms created so it’s important to understand the sociological aspect of this situation. Management might not want to invest in testing, but I think it’s pretty easy to combat that one. It’s just important to think about it before making your pitch.

Technorati Tags: asp.net, asp.net mvc, career, change management, technology

I recall a time when I had ambitions to be the person that had the final say in everything. I think we all have this dream at some point in our lives. “If only I were calling the shots, we wouldn’t be in this position.” I’m sure the majority of you can relate to this statement in some way.

Perhaps you’re the exception to the rule. You tend to make the right decisions without consulting anybody. Well, kudos to you. You’re among some ridiculously small percentage of people that are able to do so. If you’re like the rest of us, you’ve made some pretty bad decisions because you failed to consult the people that they would impact. You didn’t do it just once, either. Chances are it’s taken you several tries to get this right.

Decisions are often made by individuals that are disconnected from low-level operations. In a well orchestrated organization, the information required to make educated decisions is readily available. However, more often than not these decisions end up being made without any foresight into how they impact others in your organization. It’s almost like they’re made in some sort of black box.

As I progressed through my career and began creating my own black boxes, I quickly re-discovered the importance of a team mentality. Teams and hierarchies ultimately boil down to pay scale and organization charts but that doesn’t mean that you can’t operate with each other’s best interest in mind. At the end of the day, you are a team and you depend on each other, right?

Maybe it’s insecurity of their qualifications or just pure paranoia, but too many managers have this irrational fear that prevents them from giving team members any significant responsibilities. On more than one occasion, I’ve found it invaluable to train a member of my team that I trust as a representative and can consult with when making important decisions that impact the team. On other occasions, I consult the team as a whole. Don’t make the mistake of forgetting that people can be innovative and tend to have ideas for solving their day-to-day problems. If someone spends five hours a day doing the same repetitive task, chances are they have some ideas on how to be more efficient…without you dictating it to them.

My point is that titles may indicate where the decision is ultimately made, but they shouldn’t indicate the only people involved in making the decision.

The Split

It’s a common characteristic of dysfunctional workplaces to feel a sense of disorientation, lack of vision, and a rush “to get things done.” Perhaps it’s in the rush of things that a split occurs. You may not feel it right away, but you’ll begin to feel the consequences quicker than you’re ready for them. This split is one of focus, vision, and community. One moment you’re operating as a team and the next you’re in a war of departments. What once was a synergistic and low maintenance operation is now a bureaucratic nightmare. How did this happen?

I’ve been here on far too many occasions. I’ve experienced it as the person “in the trenches”, I’ve experienced it as the manager pulling his hair out, and I’ve seen it happen to too many smart but unsuspecting victims. Ideally this is where I would outline the steps you can take to solve this problem immediately. Unfortunately, it’s not quite that simple.

We’re all so unique and have our own idiosyncrasies and this makes it difficult to standardize…well, anything. What I can do is give you some tips to help prepare your team to fight this split and identify warning signs.

Creating Intrinsic Motivation

Before the project takes off, take the time to sit down with your team and ensure that they can work with each other. Identify the strengths and weaknesses of your team. This should be Management 101 but the lack of focus on team building is a tragedy and it spans across too many industries.
The following is a checklist of things you should do in every project kickoff meeting:

1. Identify the strengths and weaknesses of your team
2. Identify the hidden strengths of each member
3. Identify the goals of each member and create plans for reaching those goals
4. Create opportunities for growth and create plans for evaluating them

For more information, see my post: The Kickoff – Starting a project the right way.

Understanding Success

Whether you’re working on a small project or you’re dealing with an on-going product, your team needs a clear understanding of what it means to succeed. As a manager or an executive, it’s easy to assume that the success is purely financial and this should be implied. What you need to remember is that your team typically consists of individuals that do not see a significant financial gain when a project or product is successfully released.

The simple fact is this: you need the team to succeed. This is no secret and you’d be naïve to think that your team doesn’t know this. To you, the success of the project/product is dependent upon the each member of the team successfully delivering quality tasks that are on time and within budget. To each member of the team, this is part of their job description.

Unifying the vision
By creating opportunities for growth, this gives each member of your team the freedom to learn and have some standards to have their growth measured against. This freedom is characteristic of any learning organization and it is characteristic of a good leader. When the members of your team have the freedom to grow and are encouraged to do so, they’re more prone to work at their full potential and not fall victim to social loafing.

Watch for bad apples

Nobody’s perfect and no single strategy is a silver bullet. You’ll likely come across team members that insist that you’re simply pulling some form of mind-game and creating the illusion of growth. Others will insist that personal growth isn’t enough and that they want the assurance of financial growth.

Perhaps you’re in a position to offer financial growth. The question then is do the members of your team deserve it? Are there things that they need to work on before they can be considered for a promotion? If you’re working at a company that had adopted a more transparent approach, then perhaps sharing this information could be useful.

The simple fact is that everybody can grow and improve in certain areas. If there’s a chance for immediate compensation for such growth, then that’s great and your team should be more than grateful. You goal, however, should be to focus on the importance of personal growth.

Process yields product
It doesn’t have to just be about the product or the process. You can have your cake and eat it too if you’re smart. You focus on the process of how your team achieves success and you spend time refining this process. What you need to understand is that strategic focus on process yields the product.

If you’re not careful, you’ll find yourself three months down the road with nothing to show.