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


Keep Software Simple : Page 2

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


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.

“…write the minimum code necessary to get the job done. Nothing more. Nothing less.”

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.

“If I can't explain my code to someone else in a minute or two, then I have made the code too complex.”

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.

Paul D. Sheriff is President of PDSA, Inc., which provides .NET consulting, products, and services, including an SDLC document and architectural framework. Paul is a Microsoft Regional Director for Southern California. His .NET books include "ASP.NET Developer's Jumpstart" (Addison-Wesley) and several eBooks listed on PDSA's Web site.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date