Code Simplicity

Code Simplicity

Features, Simplicity, and the Purpose of Software

by Max Kanat-Alexander
Published on December 12, 2008

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 developers focus a lot on the quality of the system, the polish of each individual feature, etc.

Twitter’s just one of the many proofs that you don’t have to have lots of features to be successful. In fact, many successful apps have fewer features than their less-successful competitors.

Still, you’ve got to have some features. 🙂 After all, it’d be pretty silly to be programming, otherwise. But how do you decide which features you should have? Is it just up to the Chief Architect’s intuition, or how many users demand that you give them “feature X”? Does whoever shouts the loudest in the development meeting get their feature implemented first?

Well, no, there is a way to decide whether or not you should implement a feature, and it comes out of one of our most basic principles: the purpose of software. This principle (that the purpose of software is “to help people”) isn’t just some fancy-sounding gibberish I made up to make myself happy–I wrote it because it’s something that can actually be really useful to think about in everyday programming, and this question of “Should we implement this feature?” gives us a great opportunity to show how it can be applied. Keep Reading

(I)SAR Clarified

by Max Kanat-Alexander
Published on December 1, 2008

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 can either abbreviate this as SAR or ISAR, depending on whether or not we want to include “Input.”

Now, some people misunderstood me and said, “Oh, SAR is just another name for MVC.” No, I used MVC as an example of SAR, but SAR is a much, much broader concept than MVC–they are not comparable theories. MVC is a pattern for designing software, whereas SAR (or ISAR) is a statement of the three (or four) components that are present in all software.

The fascinating thing about SAR is that it applies not only to a whole program, but also to any piece of that program. A whole program has a Structure, just as a function or single line of code has a Structure. Same for Action and Results.

Here’s a little more about each of the pieces, and some examples to help explain:

Structure

Here are some examples of things that would be considered “Structure” for the whole program: Keep Reading

Structure, Action, and Results

by Max Kanat-Alexander
Published on November 1, 2008

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 structure of data to produce a result. Programs also take input, and so you could possibly argue that input was a fourth part of a program, but usually I just think of a computer program as the first three parts: Structure, Action, and Results.

In the MVC sense, the Model is the Structure, the Controller is what does the Actions, and the View is the Result. I think the analogy (and the words) Structure, Action, and Results are more widely and accurately applicable to the operation of every program in existence, though, moreso than MVC, though MVC is a perfectly good way of looking at it for GUI applications.

Really, Structure, Action, and Results probably describes almost any machine in existence. A machine has some parts that don’t move, a framework–that’s the structure. Some parts move and do something–that motion is the action. And of course the machine produces something (otherwise we wouldn’t care much about it) so that’s the result.

Computer programs are unusual machines in that they can modify their own structure. However, it’s important that some part of the program be stable, that they “not move” in a logical sense. The way that object classes relate to each other, the names of methods and variables–these are all parts of the structure that usually don’t change while you’re running. (Sometimes you make new classes, methods, or variables while you’re running, but they usually follow some pre-set plan, so there’s still a lot of “not moving” involved.)

When I’m writing software, I usually build the Structure first, then I work on the Actions, and then I work on the displaying of the Result. Some people work backwards from the Results, that’s fine too. Probably the only inadvisable thing to do is to start with the Actions, since it’s kind of confusing to be performing Actions without a Structure and with no defined Result.

There’s so much to this concept that I could probably write a whole book just on this one topic, but I think this is a decent introduction, and I’m sure that given this, you can think of lots of other useful applications of it.

-Max

Simplicity and Security

by Max Kanat-Alexander
Published on October 17, 2008

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 doors and windows are there on this building?” If your building has 1 exterior door, it’s very easy to protect that door. If it has 1000, it will be impossible to keep the building secure, no matter how good the doors are or how many security guards you have.

So we need to limit the “ways in” to our software to some reasonable number, or it won’t ever be secure. That’s accomplished by making the overall system relatively simple, or breaking it down into very simple and totally separate component parts.

Then, once we’ve limited the ways in, we need to start thinking about “How many different possible attacks are there against each way in?” We limit that by making the ways in themselves very simple. Like a door with only one unique key, instead of a door that can take five different keys, all of which individually will open the door.

Once that’s done, we limit how much damage any attack could do if it got through. For example, in a building, we’d make any given door only allow access to one room.

All of this explains, for example, why Windows is fundamentally flawed and will never be secure, and why UNIX-based systems have a better reputation for security. Keep Reading

What Is A Computer?

by Max Kanat-Alexander
Published on October 10, 2008

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 what is it that makes all that stuff a computer? Why do we look at it and go, “Oh yeah, that’s a computer,” as opposed to, say, “Oh, that’s just a TV,” or “That’s where I keep the leprechauns at night.”?

Some people try to define the word “computer” just by saying “it’s got such and such parts and they all work this way,” but that’s like saying “airplanes have two wings and jet engines.” It’s true, but I could build an airplane that didn’t have two wings or jet engines. The way something works is not a definition for that thing.

Others try to define it mathematically, but that can also be somewhat limiting, because then only the devices that fit into your mathematical scheme are computers, and there are multiple mathematical models that would all be considered “computers.”

So I turned to the dictionary. That was fun for me–I’m a dictionary fanatic. I’ve got lots of great dictionaries, and there are even more online. The Compact Oxford English Dictionary had the best definition, as it turned out.. I was very happy with it at first, but when I started to think about it, it didn’t quite work. For example, it calls computers “an electronic device,” and we know that computers can be built without electronics.

So I worked to come up with a definition of my own. Strangely enough, the key question that it boiled down to was “Why is a player piano not a computer?” It “processes information” by playing notes from its roll. If you gave it an etching machine, it could “store information” back on to the roll. But despite all that, it’s clearly not a computer. What is a computer doing that is fundamentally different from a player piano, that a player piano could never do? Keep Reading

Top 10 Reasons To Work On Open Source (In a California Accent)

by Max Kanat-Alexander
Published on September 12, 2008

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 work on open-source…as said by, like, a dude from Cali (with translations underneath 🙂 ). Keep Reading

Success Comes From Execution, not Innovation

by Max Kanat-Alexander
Published on September 8, 2008

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 execution.

It doesn’t matter how good or how new my idea is. It matters how well I carry it out in the real world.

Now, our history books worship the inventors, not the executors. We are taught all about the people who invent new things, come up with new ideas, and plough new trails. But look around you in present time and in the recent past, and you’ll see that the most successful people are the ones who carried out the idea really well, not the people who came up with the idea.

Elvis didn’t invent rock and roll. Ford didn’t invent the automobile or the assembly line. Apple didn’t invent the GUI. Webster didn’t invent dictionaries. Maytag didn’t invent the washing machine. Google didn’t invent web searching. I could go on and on and on.

Granted, sometimes the innovator also is an excellent executor (Alexander Graham Bell being an example), but usually that’s not the case. Most inventors don’t turn out to be the most successful people in their field (or even successful at all).

So stop worrying about “coming up with something new.” You don’t have to do that. You just have to execute an already existing idea really, really well. You can add your own flair to it, maybe, or fix it up a little, but you don’t have to have something brand new.

There are so many examples that prove this that it’s hard not to see one if you move your eyes anywhere. Just look, you’ll see.

Now, I’m not saying that people shouldn’t innovate. You should! It’s fun, and it advances the whole human race a tiny step every time you do. But it’s not the path to long-term success for you or for any group you belong to. That’s all in execution.

-Max

Designing for Performance, and the Future of Computing

by Max Kanat-Alexander
Published on September 4, 2008

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 of software simplicity, I’m opposed, in a theoretical sense, to designing for performance.

However, Google is in an interesting situation. Essentially, we live in the Bronze Age of computing (or perhaps the Silicon Age, as I suspect future historians may call this period of history). Our computers are primitive, compared to what we are likely to have 50 to 100 (or 1000!) years from now. That may seem hard to believe, but it’s always hard to imagine the far future. Google is operating on a level far exceeding our current hardware technology, really, and so their design methods unfortunately can’t live in a theoretical fairy-land where hardware is always “good enough.” (However, I personally like to live in that land, when possible, because hardware will improve as time goes on–an important fact to understand if you’re going to have a long-lived software project).

What is it about our computers that makes them so primitive? Well, usually I don’t go about predicting the future in this blog, or even talking about too many specifics, because I want to keep things generally applicable (and also because the future is hard to predict, particularly the far future). But I will talk about some of my thoughts here on this, and you can agree with them or not, as you please. Keep Reading

Design From The Start

by Max Kanat-Alexander
Published on August 15, 2008

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 never add a feature unless the design can support it simply. This drives some people crazy, notably people who have no concept of the future. They start to foam at the mouth and say things like, “We can’t wait! This feature is so important!” or “Just put it in now and we’ll just clean it up later!” They don’t realize that this is their normal attitude. They’re going to say the same thing about the next feature. If you give in to them, then all of your code will be poorly designed and much too complex. It’ll be Frankenstein’s monster, jammed together out of broken parts. And just like the friendly green giant, it’ll be big, ugly, unstable, and harmful to your health. Keep Reading

Sane Software Design

by Max Kanat-Alexander
Published on August 11, 2008

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. Keep Reading

Previous 1 … 3 4 5 6 7 … 9 Next
  • Home
  • Contact
  • About
  • Book: Understanding Software
  • Book: Code Simplicity

Max Kanat-Alexander Follow

mkanat
Retweet on Twitter Max Kanat-Alexander Retweeted
January 10, 2023

@__mharrison__ I did.

I would've read Kanat-Alexander's "Code Simplicity" sooner.

I truly think it may be the most crucial code learning resource there is.

I'm thankful for all other books. They give information/knowledge about usage of tools. Code Simplicity, however, teaches wisdom.

Reply on Twitter 1612846495056945152 Retweet on Twitter 1612846495056945152 1 Like on Twitter 1612846495056945152 21 Twitter 1612846495056945152
Retweet on Twitter Max Kanat-Alexander Retweeted
December 9, 2022

@mkanat just ended reading "Code Simplicity", great ready: simple and easy to understand, just as code is meant to be! 👌🏼

Reply on Twitter 1601103831101685761 Retweet on Twitter 1601103831101685761 1 Like on Twitter 1601103831101685761 1 Twitter 1601103831101685761
December 7, 2022

Sometimes you have to choose whether to be “nice,” or actually say “no” to doing the wrong thing. Keep in mind, it is not actually kind to deliver bad products to all your users, just so you can be “nice” to one person.

Reply on Twitter 1600448041848229888 Retweet on Twitter 1600448041848229888 Like on Twitter 1600448041848229888 4 Twitter 1600448041848229888
November 15, 2022

It's always important to understand your users and the problems they actually have.

In developer tools, it's easy to assume you already know the problems, because you're a developer. But often, it's surprising to discover what developers' actual pain points and requirements are.

Reply on Twitter 1592626294474559488 Retweet on Twitter 1592626294474559488 Like on Twitter 1592626294474559488 11 Twitter 1592626294474559488
Retweet on Twitter Max Kanat-Alexander Retweeted
November 15, 2022

How does LinkedIn approach developer productivity?

In this week's issue, @mkanat shared his learnings from spending ~20 years in this field, and how LinkedIn approaches this area.

Subscribers can read the full issue here: https://newsletter.pragmaticengineer.com/p/linkedin-engineering-efficiency

Reply on Twitter 1592567547718553600 Retweet on Twitter 1592567547718553600 11 Like on Twitter 1592567547718553600 107 Twitter 1592567547718553600
  • Home
  • Contact
  • About
  • Book: Understanding Software
  • Book: Code Simplicity