I often run into issues related to object initialization in C# class objects that have properties that are other objects.  Here is an example to clarify the situation.

public class CarProperties {
   public string Make { get; set; }
   public string Model { get; set; }
   public bool IsFast { get; set; }
}

public class CarMaster {
  public CarProperties CarInfo { get; set; }
}

There are issues with this simple scenario. On the CarMaster object, CarInfo must, at some point somewhere, be initialized with "new CarProperties()". The question is... when?!

I don't know of any developer alive that has never received a null reference exception. It happens in most languages. In .NET it usually sounds like this... "Object reference not set to an instance of an object."

So, to avoid, the error we might initialize the object in the parent class constructor to make ourselves happy...

public class CarMaster {
  public CarProperties CarInfo { get; set; }
  public CarMaster() {
      this.CarInfo = new CarProperties();
  }
}

Alrighty, now we can access CarInfo to our heart's delight. But, this can cause problems in business logic and interface code. You might have this...

   CarMaster mainCar = Repository.GetMainCar(22);
   labelModel.Text = mainCar.CarInfo.Model;

This is risky code from a reliability stand point. The BIG question is... How can we be sure that CarInfo is not null? Well, we can't, and we should never expect that always will have a value. Making assumptions like that is dangerous.

This issue has caused so many problems, and I have done my share of evil in this area. I now strive to make a practice of setting child properties to a default null value, and always expecting the worse in the receiving code that uses other objects.

My role as a developer is stretching more into the project management world as well as the coding world.

We have a small team.  Every piece of what we do needs to be operating in the most efficient and effective way possible.  This ranges from clean code, good architecture, thoughtful design, clear project goals, developer motivation, collaboration with owners/experts/managers/etc.

I know there is a lot of talk about Agile, Kanban, Extreme Programming, and more.  My perspective is that there is never a one-size-fits-all solution, but the "frameworks" that are out there can be helpful in developing a solution for your company.  

The following is a write-up I did to help communicate project management techniques within my workplace...

-----------------------------------------

The following is also available in a prettier Google Doc version.

Software projects involve more than simply writing code. Here are some areas where we could use improvement.

Communication

Every person involved in a project comes from a different perspective. This is important and there is value in those differences, but we do need a means of bridging the gap between different domains. The place to start is to not let the simple things obscure the discussion.

My thoughts: This will always be an area needing improvement. By using visuals and written documents, I hope to facilitate a “common language” amongst all parties involved in a project. This will take time initially, but the value will be great.

Project Management

Project management has been a struggle in software development for many years. Over time, some techniques have developed, but fundamentally it comes down to each individual being aware of all the factors involved and a willingness to boldly confront issues as early as possible.

We are not a big software company, but some concepts can be used in any size team. Agile, Extreme Programming (XP), and Kanban are some topics that often come up in software books and blogs.

The Agile Manifesto sounds like nerdy programmers taking their jobs too seriously, but something can be gained from what it offers. Here is the abbreviated manifesto...

My Thoughts: There is no golden rule to managing projects. Every organization must find its own way, but can learn from the failures and successes of others.

Architecture, Design and Programming

In areas of development, the rules of Extreme Programming are a good starting point. There are five categories... planning, managing, design, coding, testing.

Planning

User stories define what the final product needs to do. Some might call this a Functional Specification, and there is a great 4-part article on why and how to write easy-to-read specs...

• Functional Specs - Part 1: Why Bother? - Joel Spolsky
• Functional Specs - Part 2: What’s a Spec?
• Functional Specs - Part 3: But.... How?
• Functional Specs - Part 4: Tips

Plan to make many small releases on a regular interval.

My Thoughts: It is not as difficult, tedious, or annoying as it sounds. It is a critical piece that provides direction and scope for a project. It doesn’t have to be big and wordy document. But it needs to exist in some form, and has to be something that serves the purpose of keeping projects on focused and on track.

Managing

Maintain a sustainable pace.

A stand up meeting each day keeps the team communicating and focused.

Move people around - “Moving people around the code base in combination with pair programming does your cross training for you. Instead of one person who knows everything about a given section of code, everyone on the team knows much of the code in each section.”

My Thoughts: On a small team, everyone needs to be aware of what is going on in areas of the system. We have to be able to fill in and cover each other’s backs when necessary. Cross training and peer programming are even more important.

Design

Simplicity is Key - “a simple design always takes less time than a complex one.”

Choose a System Metaphor - “The most important quality is being able to explain the system design to new people without resorting to dumping huge documents on them. A design should have a structure that helps new people begin contributing quickly.”

Refactor whenever and wherever possible

Refactoring = “A disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior”

Catalog of commong refactoring techniques by Martin Fowler

Refactoring Book - by Martin Fowler

“Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity.” …
please read Refactor Mercilessly

Coding

Customer is always available -

“All phases of a programming project require communication with the customer, preferably face to face, on site.”

“Experts in any field have a tendency to argue. This is natural. Solve this problem by requiring all the customers to be available for occasional group meetings to hash out differences of opinion.”

Pair Programming increases software quality without impacting time to deliver.

Integrate Often - “Developers should be integrating and committing code into the code repository every few hours, when ever possible. In any case never hold onto changes for more than a day.”

Testing

Testing can help find bugs, and, even more importantly, prevent bugs from being introduced with future changes. Testing takes time to create and make a habit of, but it will “offer a pay back far greater than the cost of creation.”

My Thoughts: By constantly seeking to improve each area of Planning, Managing, Designing, Coding and Testing we will find our way to more successful development projects. Every area is important. Simplicity and clean code will speed development and improve our effectiveness.

I was working on an MVC project recently, and wanted to use templates for formatting emails.  Scott Hanselmann recommends MvcMailer in this post.  I gave it try, but it has a couple dependencies on other projects, and I wanted to keep it simple and pragmatic for this small project.  

I ended up using ActionMailer.Net which uses two of its own dlls and no external dependencies.  ActionMailer worked for my needs and uses standard views, either .aspx or Razor view files.

Prior to MVC, in web forms, I built an Email Templater, which allowed me to create a new model for each email view, but I had to point the templater to the correct template file location.  ActionMailer is essentially an extension of the MVC ControllerBase class, so all you need to do is place your view files in the View folder of your site.

For my needs it worked, but it is a very basic email requirement I have, so it is possible I may run into obstacles.  But, so far so good.

I have run into this one several times now, and want to make a note of it.

I sometimes create .NET Http Handlers that need to access session variables.  HttpHandlers are .NET class that implement the IHttpHandler interface.  By default these classes will throw an error if you try to use the Session object at all.

You can easily enable Session access by implementing the IRequiresSessionState interface.

public class VehicleIdCard : IHttpHandler, IRequiresSessionState {

    public void ProcessRequest (HttpContext context) {
          string myVar = context.Session["MySessVar"];
    }

    public bool IsReusable {
        get {
            return false;
        }
    }
}