RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Keep Software Simple

Pay attention to the true goal of software to avoid over-engineering your software solutions.


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.

“The best thing about programmers is they like to program. The worst thing about programmers is they like to program.”

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.

Editor's Note: This article was first published in the May/June, 2009 issue of CoDe Magazine, and is reprinted here by permission.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date