Less Software

 

http://gettingreal.37signals.com/ch10_Less_Software.php

Less Software

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. (我也很希望 programmer 能提出更省力的做事方式，學會怎麼偷懶，但又能完成事情，是我的人生目標之一。)

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.