http://www.codesimplicity.com Fri, 08 Jan 2010 17:24:38 +0000 http://backend.userland.com/rss092 en So today I was playing around with a little equation that may in fact explain nearly all of the principles of software design. I don't know that it's actually mathematically solvable in terms of numbers, but it does demonstrate the factors present in software development decisions and how they ... http://www.codesimplicity.com/post/the-equation-of-software-design/ So, there's a lot of talk on the Internet about privacy. Some people say that privacy is only desired by those who have something to hide. Some people insist that privacy is a human right that should never be violated without consent. There's only one problem with this whole debate: what ... http://www.codesimplicity.com/post/privacy-simplified/ A long time ago, I wrote an essay called "Why Computers Suck" (it was given the title "Computers" and "What's Wrong With Computers" in two later revisions, and the original title never saw the light of day). The article was fairly long, but it basically came down to ... http://www.codesimplicity.com/post/why-programmers-suck/ Before all the laws of software, before the purpose of software, before the science of software design itself, there is a singular fact that determines the success or failure of a software developer. This fact makes the difference between the senior engineer who can seem to pick up new languages ... http://www.codesimplicity.com/post/the-singular-secret-of-the-rockstar-programmer/ The attitude that every engineer should have, in every field of engineering, is: I can solve this problem the right way. Whatever the problem is, there's always a right way to solve it. The right way can be known, and it can be implemented. The only valid reason ever to not implement ... http://www.codesimplicity.com/post/the-engineer-attitude/ So, after my last post, a few people asked, "Okay, but how do you figure out what sucks?" Well, some of it's really obvious. You press a button and the program takes 10 minutes to respond. That sucks pretty bad. You get 100 complaints a week about the UI of a ... http://www.codesimplicity.com/post/how-we-figured-out-what-sucked/ When I started working on Bugzilla in 2004, it was a difficult time for the whole project. There were tremendous problems with the code, we hadn't gotten a major release out in two years, and a lot of the main developers had left to go do paid work. But eventually, thanks ... http://www.codesimplicity.com/post/suck-less/ In a user interface, similar things should look the same. But different things should look different. Why do over 75% of Facebook's users think that the new Facebook UI is bad? Because it makes different things look similar to each other. Nobody can tell if they're updating their status or writing ... http://www.codesimplicity.com/post/consistency-does-not-mean-uniformity/ One of the best ways to keep an app simple is, of course, to limit how many features you implement. Twitter, for example, has very few features, but is enormously successful. The limited number of features of Twitter make it really easy to keep the application simple, which lets the ... http://www.codesimplicity.com/post/features-simplicity-and-the-purpose-of-software/ In my previous post, I said that there are three major parts to any computer program: Structure, Action, and Results. Also, a program has Input, which could be considered a fourth part of the program, although usually it's not the programmer who's creating the input, but the user. So we ... http://www.codesimplicity.com/post/isar-clarified/ There's a very popular model for designing software that we've all heard of if we're web developers, and probably most desktop developers have heard of too: our old friend MVC. This works well because it reflects the basic nature of a computer program: a series of actions taken on a ... http://www.codesimplicity.com/post/structure-action-and-results/ A big part of writing secure software (probably the biggest part) is simplicity. When we think about software security, the first question that we ask is, "How many different ways could this program possibly be attacked?" That is, how many "ways in" are there? It's a bit like asking "How many ... http://www.codesimplicity.com/post/simplicity-and-security/ What is a computer? You'd think that would be a fairly simple question. After all, I'm using one to type this up, I ought to know what it is, right? I mean obviously, it's a...computer! I mean, it's got a keyboard, and a monitor, and there's that box down there... But ... http://www.codesimplicity.com/post/what-is-a-computer/ So, as a little digression from our normal content, I felt like writing a list of the top 10 reasons to work on open-source software...but being a born Californian, I felt I had to pay a little respect to my roots. So here we have the top 10 reasons to ... http://www.codesimplicity.com/post/top-10-reasons-to-work-on-open-source-in-a-california-accent/ There's a strange sort of social disease going around in technology circles today, and it all centers around this word "innovation." Everybody wants to "innovate." The news talks about "who's being the most innovative." Marketing for companies insists that they are "innovating." Except actually, it's not innovation that leads to success. It's ... http://www.codesimplicity.com/post/success-comes-from-execution-not-innovation/ So, you might have heard that Google released a web browser. One of the features of this web browser is its JavaScript engine, called v8, which is designed for performance. Designing for performance is something that Google does often. Now, designing for performance usually leads to complexity. So, being a major supporter ... http://www.codesimplicity.com/post/designing-for-perfomance-and-the-future-of-computing/ I don't know if this has become clear to everybody yet, but you really need to design from the start. You need to be working on simplicity and the other Laws of Software Design from the very beginning of your project. My policy on projects that I control is that we ... http://www.codesimplicity.com/post/design-from-the-start/ I have come up with an analogy that should make the basic principles of software design understandable to everybody. The great thing about this analogy is that it covers basically everything there is to know about software design. Imagine that you are building a structure out of lead bars. The ... http://www.codesimplicity.com/post/sane-software-design/ So, I just had my talk, Code Simplicity: Software Design In Open Source Projects at OSCON 2008. It went really well! Here's the slides from my talk (also available in PDF Format). -Max http://www.codesimplicity.com/post/slides-from-my-talk/ I'm going to be talking at FOSSCoach, a free series of lectures at OSCON. You don't need a session pass to attend, but you do need to register (for free). I'll be talking on Thursday, July 24, at 3:25pm, in either room E143 or E144 at the Oregon Convention Center. I'll tell ... http://www.codesimplicity.com/post/talking-at-oscon/ Bugs most commonly come from somebody's failure to reduce complexity. Less commonly, they come from the programmer's misunderstanding of something that was actually simple. Other than typos, I'm pretty sure that those two things are the source of all bugs, though I haven't yet done extensive research to prove it. When something ... http://www.codesimplicity.com/post/the-source-of-bugs/ Okay, most programmers know the story—way back when, somebody found an actual insect inside a computer that was causing a problem. (Actually, apparently engineers have been calling problems “bugs” since earlier than that, but that story is fun.) But really, when we say “bug” what exactly do ... http://www.codesimplicity.com/post/what-is-a-bug/ In The Never-Shipping Product, I mentioned seven ways to add complexity, and one of them was "Lock-In To Bad Technologies." But what's a "bad" technology? Is it all just based on opinion? Should we throw our hands up in the air and give in to the whims of ... http://www.codesimplicity.com/post/creating-complexity-lock-in-to-bad-technologies/ One of the most important things to know about any kind of engineering is: There are some things about the future that you do not know. Obviously it'd be ideal if we were all-knowing and could perfectly predict every consequence of every decision we'll ever make. But that's impossible. In ... http://www.codesimplicity.com/post/unforseeable-consequences-why-we-have-principles/ 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 ... http://www.codesimplicity.com/post/fosscoach-2008/ 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. ... http://www.codesimplicity.com/post/the-never-shipping-product/ 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 ... http://www.codesimplicity.com/post/specific-solutions/ 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 ... http://www.codesimplicity.com/post/complexity-and-the-wrong-solution/ 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 ... http://www.codesimplicity.com/post/truncated-posts-in-rss/ 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 ... http://www.codesimplicity.com/post/instant-gratification-instant-failure/ 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 ... http://www.codesimplicity.com/post/if-it-aint-broken/ 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 ... http://www.codesimplicity.com/post/the-fourth-law-of-software-design-complexity-vs-ease-of-maintenance/ 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 ... http://www.codesimplicity.com/post/the-third-law-of-software-design/ 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 ... http://www.codesimplicity.com/post/the-second-law-of-software-design/ 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 ... http://www.codesimplicity.com/post/the-goals-of-software-design/ 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 ... http://www.codesimplicity.com/post/the-purpose-of-software/ 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 ... http://www.codesimplicity.com/post/what-is-software-design/ 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 ... http://www.codesimplicity.com/post/the-primary-law-of-software-design/ 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 ... http://www.codesimplicity.com/post/there-is-no-science-of-software/ 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 ... http://www.codesimplicity.com/post/simplicity-and-strictness/