Deborah's Developer MindScape

         Tips and Techniques for Web and .NET developers.

February 11, 2014

Why Use Code Behind?

Filed under: C#,VB.NET,Visual Studio @ 2:36 pm

There are many .NET developers across the full range of skill levels that are using code behind for the logic of their C# or VB.NET applications, not just for UI management.

This post looks at the possible reasons for this. It would be great to get your thoughts on this topic. (Use the comments section below so the conversation is visible to everyone.)

NOTE: Depending on your UI technology, it makes sense to put code that manages the UI into the code behind. However, there are many alternate places to put the logic of the application.

From what I have seen, using code behind for all application logic normally stems from one (or a combination) of the following:

  • Quick and Easy
  • Tooling
  • Work Environment: Management
  • Work Environment: Work Space
  • Minimum Viable Product

Quick and Easy

If a developer needs to build a quick application for the support staff to update customer types or view log transactions, that developer wants to spend the least amount of time possible. There are other things that directly affect the customers that are much more important to spend time on.

Using code behind is quick and easy. Just double-click on a UI element in a Visual Studio designer, write code, and run. It’s done!


By their very nature, the Visual Studio designers are set up for code behind. And many Visual Studio demonstrations show off the cool designer tooling.

New .NET developers often learn to program using these designers with code behind. And even as they progress with their knowledge and tackle more complex applications, they never get out of the "double-click and write code" habit.

Work Environment: Management

Maybe the manager is not technical or has not kept up with current software development life cycle (SDLC) techniques. Or maybe the manager has seen one too many Visual Studio "double-click and write code" demonstrations and has seen how "fast" developers can write code.

In either case, they may only be focused on getting features out quickly. If so, developers may feel that code behind is all they can do in the time allocated.

Work Environment: Work Space

Do the developers work in an office with constant interruptions? Do they get a "ping" every time they get a new email, Facebook post, or tweet? Do they have to provide immediate customer support? Do they work at home in the family room with the kids asking for homework help and the significant other watching TV?

Developing an application using only code behind often requires much less concentration. Just double-click to write the code, double-click to open the code … and the code is all there.

Building applications that use components, base classes, inversion of control, services, patterns, and so on require significantly more thinking. And as such, are very challenging to work with in an interrupt-drive environment.

See this post for some interesting information on software developer interruptions.

Minimum Viable Product

Minimum viable product is a agile strategy that focuses on getting the minimum set of software features in place to allow the product to be deployed and nothing more. The customers can then provide feedback and the software can be refactored and adjusted as necessary.

Depending on the selected technologies, using code behind for all of the application logic may be the quickest way to a minimum viable product. Refactoring to components, interfaces, and other technologies come later.

Are there other reasons? Your thoughts?


  1.   Taner Yiğit — February 14, 2014 @ 5:06 am    Reply

    Totally agree with you. Maybe you should write a post about the outcomes.

  2.   DeborahK — February 17, 2014 @ 10:59 am    Reply

    Hi Taner – Thanks for your comment. Yep, that’s the plan!

  3.   Nick — February 19, 2014 @ 10:57 am    Reply

    I’ve also seen a legacy reason: developers using it because all the other company projects use it and the motivation to learn and change isn’t there or there’s a concern over the risk.

  4.   DeborahK — February 19, 2014 @ 11:43 am    Reply

    Thanks for your comments Nick. Yes, that makes sense. It could be listed as “We’ve always done it that way”.

  5.   Jon — March 17, 2014 @ 3:02 pm    Reply

    Another source that I’ve seen is one-off programs, frequently ones that programmers use to help themselves. Those programs have a tendency to grow legs when the programmer is out on vacation or stores the executable in a shared folder.

    Once it’s out in the wild, there is no reigning it in – and this likely means that the program needs to have lots of additional changes.

RSS feed for comments on this post. TrackBack URI

Leave a comment

© 2020 Deborah's Developer MindScape   Provided by WPMU DEV -The WordPress Experts   Hosted by Microsoft MVPs