One thing I feel we (the developer community) do is focus heavily on the more advanced topics. After all, he who speaks on the latest and greatest tools and advanced patterns gets the most attention and praise from fellow developers. Since moving our user group to USF Polytechnic and being forced to contemplate how to best serve those new to our field and get them more interested, it has occurred to me: we have ignored those new to .NET and are doing a bad job reaching out to them.

I would like to encourage everyone in the community (especially MVPs and User Group leaders) to provide more for the people who are the future of our profession. That's not to say that you should abandon advanced topics and the technologies that are of interest to you – but do just a little for those who are not at your experience level yet. It doesn't make you less of a developer or speaker to do 100 and 200 level topics.

In the spirit of the comments above, I'm starting a thread in my blog on basic topics. If you have a blog that covers this type of stuff please let me know and I'll use the RSS feed to integrate it into our site. Joe Healy gave me a great book to get me started – this one is Microsoft .NET: Architecting Applications for the Enterprise (by Dino Esposito and Andrea Saltarello). There are advanced topics in the book, but I'm going to focus on some of the basic topics. I'm not going to tackle the broader architecture issues – just enough to help developers build better applications.

Spaghetti Code

When you start coding, how much thought or time do you put into making sure your application is easily maintained, can meet growth demands, is easy to change, or can be reused? Have you considered why we use interfaces and why having a contract helps us build more flexible software? Hopefully of the course of our discussions at user group meetings and in this blog junior developers start asking those questions.

I have seen many good applications built that serve their purpose well. The user interface is elegant and the end result is what the business or customer requires at the time. To the untrained eye, it is a good application. However, these applications may become future problems for the business. Business requirements change quite frequently and what worked one year in our software might not be desirable the next year. So we must make changes. If our application or database is poorly designed (spaghetti code) it becomes increasingly difficult and expensive to keep up with the moving target. Change is usually never easy; however there are things we can do to make change easier. We see this problem in small, relatively simply systems. Now imagine when we have this problem in very large and complex systems!

When I was new to programming, I thought that following standards (capitalizing public properties, using camel case, etc) was what made good design. I thought that comments made it really good design. What I didn't realize was that although those two things are important, they aren't as important as the principles I am about to discuss (and they aren't really design issues).

Separation of Concerns

Quoting partially from the book, rigidity "is characterized by some resistance to changes" and "is measured in terms of regression". If you make a change to one part of your code, it cascades down to the code that is dependent on it. The way to make your code more flexible is through decoupling – or using modularity and "separation of concerns" or SoC. Soc requires that you dissect your system into unique and ideally non-overlapping features. Each feature represents a concern, or aspect of your system. In practice each concern is expressed in a software module (or class/method in object oriented programming).

The way you achieve SoC is to use something called information hiding, or abstracting the complexities of your code from consumers. These are fancy words, so let's break it down. In simple terms, all we are doing here is exposing to our consumers (other code) only what they need to use our code. Suppose we have written code to allow the operation of an engine. I'm no mechanic, but what I do know about engines is that we need to have air, fuel, and fire (a spark) to make it work. However the operator of that engine (a driver) only needs to know how to start the engine, adjust the speed, and get basic information such as the current speed. We wouldn't want the driver to be responsible for adjusting the air and fuel mixture and certainly not responsible for sending a spark to the right plug at the right time. Our engine simply wouldn't work.

• Engine Class Methods
  • Start Engine
  • Adjust Speed
  • Get Speed
  • Adjust Air Flow
  • Send Spark to Cylinder
  • Adjust Fuel Flow

Based on what we now know, which methods do you think should be made public (available to the consumer) and which do you think should be private (hidden from the consumer)? I'll let you think and discuss this among yourselves.

Exposing all of those methods publicly would enable consumers to make themselves responsible for things they should not be controlling, which could cause problems in our engine. Now that we have hidden the complexity of our engine class from the consumer, let's introduce some spaghetti code to our Engine class:

• Public Engine Methods
  • Start Engine
  • Adjust Speed
  • Get Speed
  • Adjust Mirror

What method doesn't belong? I hope it is obvious that the engine class should not concern itself with adjusting the mirror. By doing this, we have made our code more rigid and resistant to change. Any time we want to change the way our mirror operates, we must make changes to the engine class. We have also made this code less reusable by other code.

Suppose you build another application for a new electric car that needs to reuse the functionality in the engine class to adjust mirrors. The electric car will not need most code from the engine class because it uses the Electric Motor class and operates completely differently. Most likely the developer of the electric motor class would simply re-code the mirror class (or copy and paste). We have just defeated one of the key benefits of object oriented programming. We would now have two different ways to adjust mirrors. And when the business wanted to change how mirrors are adjusted we would need to remember to change it everywhere it is used. This can get really messy!

I wrote this blog entry so that hopefully someone new to programming would understand. Please let me know if anything I said was confusing or could be misleading, or if there is anything that should be added. Better yet, add your own thoughts in comments below.