Keep your code as simple as possible
You’d think that twice as much code would make your software only twice as complex. But actually, each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition, each change, each interdependency, and each preference has a cascading effect. Keep adding code recklessly and, before you know it, you’ll have created the dreaded Big Ball of Mud.
The way you fight this complexity is with less software. Less software means less features, less code, less waste.
The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that’s alright. Solving 80% of the original problem for 20% of the effort is a major win. The original problem is almost never so bad that it’s worth five times the effort to solve it.
Less software means you put away the crystal ball. Instead of trying to predict future problems, you deal only with the problems of today. Why? Fears you have about tomorrow often never come to fruition. Don’t bog yourself down trying to solve these phantom issues.
From the beginning, we’ve designed our products around the concept of less software. Whenever possible, we chop up hard problems into easy ones. We’ve found solutions to easy problems are not only easier to implement and support, they’re easier to understand and easier to use. It’s all part of how we differentiate ourselves from competitors; Instead of trying to build products that do more, we build products that do less.
- Less software is easier to manage.
- Less software reduces your codebase and that means
- less maintenance busywork (and a happier staff).
- Less software lowers your cost of change so you can adapt quickly. You can change your mind without having to change boatloads of code.
- Less software results in fewer bugs.
- Less software means less support.
Which features you choose to include or omit have a lot to do with less software too. Don’t be afraid to say no to feature requests that are hard to do. Unless they’re absolutely essential, save time/effort/confusion by leaving them out.
Slow down too. Don’t take action on an idea for a week and see if it still seems like a great idea after the initial buzz wears off. The extra marinating time will often help your brain come up with an easier solution.
Encourage programmers to make counteroffers.
You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.” Let the software push back. Tell programmers to fight for what they think is the best way.
Also, search for detours around writing more software. Can you change the copy on the screen so that it suggests an alternate route to customers that doesn’t require a change in the software model? For example, can you suggest that people upload images of a specific size instead of doing the image manipulation on the server side?
For every feature that makes it into your app, ask yourself: Is there a way this can be added that won’t require as much software? Write just the code you need and no more. Your app will be leaner and healthier as a result.
There is No CODE That is More Flexible Than NO Code!
The “secret” to good software design wasn’t in knowing what to put into the code; it was in knowing what to leave OUT! It was in recognizing where the hard-spots and soft-spots were, and knowing where to leave space/room rather than trying to cram in more design.
—Brad Appleton, software engineer (from There is No CODE that is more flexible than NO Code!)
Complexity Does Not Scale Linearly With Size
The most important rule of software engineering is also the least known: Complexity does not scale linearly with size…A 2000 line program requires more than twice as much development time as one half the size.
—The Ganssle Group (from Keep It Small)