14 Design Lessons Learned from Berkeley DB

The original article can be found here, but I wanted to put together a summary list of the design lessons in the article for later reference for myself.

1. Software should be designed and built as a cooperating set of modules. Each module should have a well-defined API boundary, which can (and should) change as needed, but a boundary is always present.

2. Software design is a way to force oneself to think through the entire problem, and it is really worth thinking through before writing code.

3. Software architecture will degrade over time, there is no way around it.

4. Naming (variables, methods, functions, etc.) and coding style should be consistent, since good naming and formatting provides a lot of information. Failing to follow expected coding conventions should be considered a significant offense.

5. Make upgrade decisions carefully. Consider carefully minor updates to major releases.

6. In designing a library, respect namespace. Do not make engineers put in an effort to memorize reserved words, constants, etc. just to get your library working without naming collisions.

7. Make functionality shared if they appear more than once. Write a test suite for general purpose routines. If the code is difficult to write, write and maintain it separately so that other code cannot corrupt it.

8. Use encapsulation and layering, even if it seems unnecessary. Life will be easier down the road.

9. Think stability over increased concurrency.

10. If one is thinking of writing special purpose code to handle something, step back and see if things can be simpler.

11. If one doesn't have the time to make a change right now, then one won't find the chance later.

12. "...Every piece of code should do a small number of things and there should be a high-level design encouraging programmers to build functionality out of smaller chunks of functionality, and so on..." (from Berkeley DB article)

13. Every bug is important.

14. "...Our goal as architects and programmers is to use the tools at our disposal: design, problem decomposition, review, testing, naming and style conventions, and other good habits, to constrain programming problems to problems we can solve...." (from Berkeley DB article)