Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Programming with Reason: 1

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.