http://www.codesimplicity.com Thu, 17 Nov 2011 19:00:52 +0000 http://backend.userland.com/rss092 en Here are some clues that tell you that your code may be too complex: You have to add "hacks" to make things keep working. Other developers keep asking you how some part of the code works. Other developers keep mis-using your code, and causing bugs. Reading ... http://www.codesimplicity.com/post/clues-to-complexity/ Your program is not important to me. I don't care about its user interface. I don't care what its name is. I don't care that you made it, or what version it is. The only thing I care about is that your program helps me accomplish my purpose. That's a truly ... http://www.codesimplicity.com/post/developer-hubris/ Growing and maintaining an open-source community depends essentially on three things: Getting people interested in contributing Removing the barriers to entering the project and contributing Retaining contributors so that they keep contributing If you can get people interested, then have them actually contribute, and then have them stick ... http://www.codesimplicity.com/post/open-source-community-simplified/ Many people think that the readability of code has to do with the letters and symbols used. They believe it is the adding, removing, or changing of those symbols that makes code more readable. In some sense, they're right. However, the underlying principle is: Readability of code depends primarily ... http://www.codesimplicity.com/post/readability-and-naming-things/ How many times have you used a piece of software that was full of incredibly convoluted features, strange decisions, and unusable interfaces? Have you ever wanted to physically or verbally abuse a computer because it just wouldn't do things right, or you couldn't figure out how to make it function ... http://www.codesimplicity.com/post/the-power-of-no/ One of the major goals that I have with researching software design is the hope that we can take people who are "bad programmers" or mediocre programmers and, with some simple education and only a little experience, bring them into being good programmers or great programmers. I want to know--what ... http://www.codesimplicity.com/post/before-you-begin/ In the context of The Equation of Software Design, it is now possible to reduce the primary principles of software design into just two statements: It is more important to reduce the Effort of Maintenance than it is to reduce the Effort of Implementation. ... http://www.codesimplicity.com/post/software-design-in-two-sentence/ 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/