n the course of my consulting, I have reviewed numerous applications from many companies?and often find areas where the software was just too complex. The reasons for this are varied, but seem to be centered around a few main areas: inappropriate use of design patterns, the ?not invented here? syndrome, and building a Cadillac when a Chevy would do the job. You can solve these issues in many ways. All it takes is a little bit of re-thinking on how you build software. This article offers guidance on some things you can do to simplify your software development process

A business programmer’s number one job should be to make money for the business. Keeping software simple ensures you meet this goal, and keep your job.

When designing a solution to a problem, you should strive to make things as flexible as possible. However, too much flexibility can lead to hard-to-understand code. Instead, consider writing a class that solves the problem in the simplest manner (the Chevy approach). Make your class extensible by letting others inherit from it. Make your methods virtual, so you or someone else can come back later and re-use part of your code, adding additional flexibility and complexity later, if needed (the Cadillac). After all, this is what OOP is all about?the ability to extend and override as new requirements come up in the future. Try to write the minimum code necessary to get the job done. Nothing more. Nothing less.

When designing your classes, use good descriptive names for the class itself, the methods, and the properties. A class that is self-describing is, by definition, simple and easy to use. Try to avoid jargon and abbreviations. Use full, long words to make the point of what the method or property represents clear.

Add comments where your code might be a little obscure. However, if the comments require more lines than the code itself, you might want to explore how you could make the method simpler. Maybe you could refactor the code into another self-describing method, or use more descriptive variable names.

Design Patterns

Yes, there are many design patterns out there. The patterns themselves are great tools. However, you will find many implementations that are too complicated; they’re overkill for most situations. You need to try to find some middle ground that will work for just the solution you need right now. Don’t try to create the most robust solution to a problem that doesn’t exist now, and might never occur. It’s better to take a minimalist approach, use a basic design pattern, and get a product out than to spend way too much time trying to implement a pattern that?in the end?does nothing to solve the immediate business problem.

Don’t Reinvent the Wheel

The best thing about programmers is they like to program. The worst thing about programmers is they like to program. Programming is fun; that’s why we do this job. However, don’t lose sight of the fact that your job is to support the business you work for. Your real job is to create applications that make money for your company. If that means that you need to re-use someone else’s code, then do that. Don’t get hung up on the ?not invented here? syndrome. If you do, then you are not doing your job for your company.

There is no reason for a business application programmer to reinvent every solution. A business programmer’s number one job should be to support the business. Period. Your job is not to just have fun programming. Yes, that would be great, but if the company you work for needs a program to make money, then it is your job to get that program done as quickly and efficiently as possible. If you don’t do this, and your company loses business because of the lack of software, you might just find yourself out of a job!

Put a Wrapper Around Microsoft

Don’t get me wrong. I really like Microsoft, and I love using their tools. However, you need to be careful when you choose to use a new technology, because your decision can lead to code that might not work in the future. Consider what happened between .NET 1.x and 2.0. Many things that Microsoft recommended you use went away. I’ve seen this time and time again with Microsoft in the past. Look at how many data access technologies they have had us use over the last 15 years!

In my seminars I always tell people to “put a wrapper around Microsoft.” That means that, rather than calling their technologies directly, you can build wrapper classes for LINQ to SQL, LINQ to XML, the Entity Framework, the ConfigurationManager class, and other technologies and call their functionality from your custom classes and methods. Wrapping these technologies means that you need to change the code in only one place when Microsoft decides to change the technologies. It ensures that you can keep all of your other application code consistent?it just uses a different technology under the hood.

Team Programming

I am a big fan of code reviews and team programming. If I can’t explain my code to someone else in a minute or two, then I have made the code too complex. Every day, you should review your code with a co-worker to make sure that it is not too complex. If you work alone, then grab a friend, your spouse, or your dog and explain the code to them. Sometimes just talking about your code out loud to someone who does not even understand programming can help you identify potential problems.

Because I teach many seminars and write many articles and books, I know that my code will always be held up to a microscope. I strive very hard to make my code readable and understandable to a wide range of programmers. So as I write code, I always think about how that code looks to someone who is just a beginner. If a beginner can understand my variable names, my method names, and my logic, then I know an experienced programmer will too. Thinking about your code in the same light may help you write simpler, easier-to-understand code.

?Right? Engineering

If you look at two pieces of code, you can immediately differentiate between code written by a beginning programmer and the code written by an experienced programmer. The beginner will probably have under-engineered the code. However, an experienced programmer will most likely have way too much code (over-engineering). Under-engineering code occurs when someone does not put enough thought into solving a problem.

Consider the code in Listing 1 that checks to see if a file exists. You can see that this person did not put enough thought into the reusability of this code, nor the exception handling. Now, if you look at code to solve the same problem written by a programmer who tends to over engineer code, you might use the method in Listing 2.

Yes, the code in Listing 2 is very good and solves almost every conceivable problem that could happen by attempting to check to see if a file exists or not, but is this the code that was needed to solve the business problem? Most likely, the code could have just simply had a single catch block that included the file name and the error message returned from .NET and that would have been sufficient. Someone took too much time to create this over-engineered method and to test it. That time could have been better spent working on the business problem.

Having robust, flexible, reusable software is a great goal. However, that goal doesn’t do any good if you don’t deliver a product that helps your business. Start out by developing software that does just what you need and nothing more. Make that code extensible so you can adapt it to future needs. Use simple design patterns, and write your code as if you were going to present it to a large group of your peers. If you follow these techniques, you should find that your code will be simple and ?right? engineered.