Welcome to a new column about computers, programming, and the philosophy of programming. We'll explore meandering thoughts and views of technology and where it's headed with a developer's perspective on things. Or at least we'll explore whatever it is I feel like writing about at the time. Regardless, I hope you find this column's content stimulating and thought-provoking. I chose the column name because software development requires a clear goal, careful thought, and proper reasoning, regardless of the programming language, methodology, platform, or other technologies you choose to work with. In that sense, the word reason truly has two meanings to developers: thought and purpose. Whether you spend enough time architecting and designing your software, documenting your decisions, or commenting your code, there's one thing every successful software project has in common: reason.

Simple and Elegant

Let's begin our philosophical journey with a discussion on simplicity. The best software designs are often the simplest, even when solving the most complex problems. This can be a challenge when building distributed software systems, but simplicity should still be the goal. In fact, much innovation in the software space is the result of trying to simplify something otherwise complex. For instance, the web makes it easier to navigate the intricacies of the Internet. I recall the days before the web, manually navigating newsgroups and directory trees via anonymous FTP. Web services extended this simplicity to inter application communication, an otherwise complex topic.

However, it seems that complexity still finds its way into our lives, either as a technology consumer or as a software engineer. I've always tried to avoid this complexity, but I've seen others look at it almost as a selling point. I disagree. In fact, I think complexity is a sign of weakness.

In my opinion, if a software package is hard to install, configure, or to otherwise get up and running, I avoid it. I'm not being arrogant, I'm speaking from experience; I've used plenty of overly complex systems, and I've certainly built my share as well. I admit it. That's why I take such a strong view against complexity. Therefore, I strive for simplicity.

Eric's First Rule: Simplicity equals elegance.

I find that simple software design often ensures success, but it also helps to maintain the sanity of those who use that software. How much time have you spent wrestling to get a web server, application server, or database server up and running, and configured properly, for example? It's no accident that the main goal of Java EE 6 was to simplify Java EE development and deployment. Simplicity is also why thousands of developers have moved to other languages and environments such as Ruby to build web applications.

But when you need to connect more than one computer together, and arrange to have software communicate and coordinate activities between them, a certain level of complexity is unavoidable. For instance, a network stack consists of many low-level software components coordinating bits of data transmitted by fluctuations of electricity over a wire and though a network interface card. There's very little simple about that, even at a high level. But computer science offers solutions to help here as well.