<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/2.5.1" -->
<rss version="0.92">
<channel>
	<title>Code Simplicity</title>
	<link>http://www.codesimplicity.com</link>
	<description></description>
	<lastBuildDate>Tue, 01 Jul 2008 21:14:53 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>FOSSCoach 2008</title>
		<description>If you're going to be in Portland, Oregon or attending OSCON and you want to hear me talk, I've proposed a session for FOSSCoach called Code Simplicity: Software Design In Open Source Projects.

Registration for FOSSCoach is free, but is limited to 100 people, so sign up if you want to ...</description>
		<link>http://www.codesimplicity.com/archives/33</link>
			</item>
	<item>
		<title>The Never-Shipping Product</title>
		<description>When you work as a professional programmer, you almost always know somebody (or are somebody) who's going through one of the most common development horror stories in the book:

"We started working on this project five years ago, and the technology we were using/making was modern then, but it's obsolete now. ...</description>
		<link>http://www.codesimplicity.com/archives/30</link>
			</item>
	<item>
		<title>Specific Solutions</title>
		<description>  So, I'm a huge Kyle XY fan, and I was entertaining myself this morning by watching the various "behind the scenes" clips that they have on the website. Of course, before each clip was an ad--the same ad every time--for The Sims. No matter how silly the ad ...</description>
		<link>http://www.codesimplicity.com/archives/28</link>
			</item>
	<item>
		<title>Complexity and the Wrong Solution</title>
		<description>  Often, if something is getting very complex, that means that there is an error somewhere far below the level that things are getting complex on.

  For example, it's very difficult to make a car move if it has square wheels. You're going to be spending lots and ...</description>
		<link>http://www.codesimplicity.com/archives/27</link>
			</item>
	<item>
		<title>Truncated Posts in RSS?</title>
		<description>  Hey everybody. So, some of my posts are rather long, and so I truncate them with a (Read More...) link that takes you to the full post. That link also shows up in the RSS, as a (more...) link.

  For the frontpage of codesimplicity.com, I think that's ...</description>
		<link>http://www.codesimplicity.com/archives/26</link>
			</item>
	<item>
		<title>Instant Gratification = Instant Failure</title>
		<description>The broadest problem that I see in the software industry is that companies are unwilling to engage in strategies that only show results in the long term. Or, more specifically, that organizations are unaware that there is any such thing as a long-term strategy.

In the US, it's probably a symptom ...</description>
		<link>http://www.codesimplicity.com/archives/25</link>
			</item>
	<item>
		<title>If It Ain&#8217;t Broken&#8230;</title>
		<description>Okay, so remember our third law? (You can't break things if you don't change them.) Well, that has a very important related rule, that every engineer on Earth knows, but sometimes forgets:


Never “fix” anything unless it's a problem, and you have evidence showing that the problem really exists.


Of course, most ...</description>
		<link>http://www.codesimplicity.com/archives/24</link>
			</item>
	<item>
		<title>The Fourth Law of Software Design: Complexity vs. Ease of Maintenance</title>
		<description>Okay, so if we never change our software, we can entirely avoid defects. But change is inevitable! Particularly if we're going to add new features. And after all, one of our goals was to make software easy to maintain, and to maintain software, it has to be changed here and ...</description>
		<link>http://www.codesimplicity.com/archives/23</link>
			</item>
	<item>
		<title>The Third Law of Software Design</title>
		<description>So now we know that there is more future time than present time and that software will change as time goes on.

Our next law is, once again, axiomatic, and needs no derivation:


It is impossible to introduce new defects in your software if you do not change anything about it.


This is ...</description>
		<link>http://www.codesimplicity.com/archives/19</link>
			</item>
	<item>
		<title>The Second Law of Software Design</title>
		<description>Now that we know that the future is important, our second law answers the question, "What's going to happen in the future?" To any programmer who's worked for any amount of time, this law will be obviously true once you see it, but it's still good to derive and prove ...</description>
		<link>http://www.codesimplicity.com/archives/18</link>
			</item>
	<item>
		<title>The Goals of Software Design</title>
		<description>Now that we know what software design is and the purpose of software, the next step is to define the goals of this science of software design.  

From the purpose of software, we know that when we write software, we're trying to help people. So, one of the goals ...</description>
		<link>http://www.codesimplicity.com/archives/22</link>
			</item>
	<item>
		<title>The Purpose of Software</title>
		<description>Whenever you engage in some activity, it's a good idea to have some idea of what the purpose of that activity is. What is the end goal, and why are you doing it? For example, when I sleep, the goal is to be rested. When I talk, the purpose is ...</description>
		<link>http://www.codesimplicity.com/archives/21</link>
			</item>
	<item>
		<title>What Is Software Design?</title>
		<description>On my last blog, one of the commenters very correctly pointed out that I hadn't actually told you what I meant by "software design." And, in fact, looking around the web a bit, I'm finding that what I mean by "software design" isn't fully covered by most current definitions.

For the ...</description>
		<link>http://www.codesimplicity.com/archives/20</link>
			</item>
	<item>
		<title>The Primary Law of Software Design</title>
		<description>Ideally, any science should have, as its base, a series of unbreakable laws from which others are derived. What is a law? Well, in the field of science, it's something that:


  Is universally true, without exception.
  Predicts phenomena that, when looked for, will be found to exist in ...</description>
		<link>http://www.codesimplicity.com/archives/17</link>
			</item>
	<item>
		<title>There Is No Science Of Software</title>
		<description>What we think of today as being "computers" started out in the minds of mathematicians as purely abstract devices--thoughts about how to solve math problems using machines instead of the mind.

These mathematicians are the people we would consider the modern founders of "computer science." Computer Science is actually the mathematical ...</description>
		<link>http://www.codesimplicity.com/archives/16</link>
			</item>
	<item>
		<title>Simplicity and Strictness</title>
		<description>As a general rule, the stricter your application is, the simpler it is to write.

For example, imagine a program that accepts only the numbers 1 and 2 as input and rejects everything else. Even a tiny variation in the input, like adding a space before or after "1" would cause ...</description>
		<link>http://www.codesimplicity.com/archives/15</link>
			</item>
	<item>
		<title>When Is Backwards-Compatibility Not Worth It?</title>
		<description>This title might seem a bit like a contradiction to my last post! Well, you really shouldn't break your API, if you can help it. But sometimes, maintaining backwards compatibility for any area of your application can lead to a point of diminishing returns. This applies to everything about a ...</description>
		<link>http://www.codesimplicity.com/archives/14</link>
			</item>
	<item>
		<title>Ways To Create Complexity: Break Your API</title>
		<description>An API is a sort of a promise--"You can always interact with our program this way, safely and exactly like we said." When you release a new version of your product that doesn't support the API from your old version, you're breaking that promise.

Above and beyond any vague philosophical or ...</description>
		<link>http://www.codesimplicity.com/archives/13</link>
			</item>
	<item>
		<title>What Is Overengineering?</title>
		<description>Software developers throw around this word, "overengineering," quite a bit. "That code was overengineered." "This is an overengineered solution." Strangely enough, though, it's hard to find an actual definition for the word online! People are always giving examples of overengineered code, but rarely do they say what the word actually ...</description>
		<link>http://www.codesimplicity.com/archives/12</link>
			</item>
	<item>
		<title>How Simple Do You Have To Be?</title>
		<description>Sometimes, when you're working on a project, there's a question of, "How simple do we really have to be?" "How much do we have to simplify this thing?" "Is it simple enough?"

Well, of course, simplicity is relative. But even so, you can still be more or less simple. From the ...</description>
		<link>http://www.codesimplicity.com/archives/8</link>
			</item>
	<item>
		<title>Complexity Is a Prison</title>
		<description>Sometimes, I think, people are worried that if they make their code too simple, then either:


  Somehow they're not demonstrating how intelligent they are, or how valuable they are, to their managers, or
  The project will become so simple to work on that anybody can just steal their ...</description>
		<link>http://www.codesimplicity.com/archives/11</link>
			</item>
	<item>
		<title>Purpose and Simplicity</title>
		<description>A fast way to get complicated is to violate the purpose of what you're doing.

For example, what's the purpose of a web page? To give and receive information. Mostly to give information, and then some websites also take information, such as when you're buying something.

How many complicated web pages have ...</description>
		<link>http://www.codesimplicity.com/archives/7</link>
			</item>
	<item>
		<title>Simplicity Is Relative</title>
		<description>Defining "simple" really depends on your target audience. What is simple to me might not be simple to my mother, or my friends. Also, when I create something, it's always relatively "simple" to me, because I understand it inside and out. But to somebody who's never seen it before, it ...</description>
		<link>http://www.codesimplicity.com/archives/9</link>
			</item>
	<item>
		<title>Designing Too Far Into The Future</title>
		<description>There is only a certain amount of the future you can know. You can know with some certainty that you'll be breathing in the next few minutes. You can know with some certainty that if you go out to your car and push the gas pedal, the car will probably ...</description>
		<link>http://www.codesimplicity.com/archives/6</link>
			</item>
	<item>
		<title>What&#8217;s Wrong With Computers</title>
		<description>  Note: This is a "classic" article from my old blog, but with some new revisions. This article was where I started with the idea of simplicity in computing, and I've been going on that idea ever since.

	Computers have created a major societal change. The reason is that you ...</description>
		<link>http://www.codesimplicity.com/archives/4</link>
			</item>
	<item>
		<title>Welcome to Code Simplicity!</title>
		<description>Welcome to Code Simplicity!

There are a lot of technical blogs in the world. There are a lot of technical people in the world. It's a technical world.

Unfortunately, it's also becoming more and more a complex world.

The focus of Code Simplicity is to discuss simplicity and simple things in the world ...</description>
		<link>http://www.codesimplicity.com/archives/3</link>
			</item>
</channel>
</rss>
