Show Menu

Essential Software Development Principles Cheat Sheet by

Essential software development principles
development     design     principles     software

1. Accoun­tab­ility without authority

If you've been working for more than a little while, you have faced accoun­tab­ility without authority.

The extreme case is holding the janitor accoun­table for quarterly profit­abi­lity. No matter how much the janitor cleans, he can't make the company more profit­able. If the janitor comes to the sales meetings, he can't make the junior salesp­eople make more calls; he has little to no influence over the salesp­eople. If he attends the marketing meeting, he can't really get marketing to craft a new campaign.

2. Don't repeat yourself

The "­don’t repeat yourself” principle is that you should have one unambi­guous author­itative repres­ent­ation in a system. Basically, if you find that you're cutting and pasting a block of code into multiple places, your design is flawed and you should fix that first.
Violations of this principle aren't merely a waste of time; they cause mainte­nance problems. Every cut-an­d-p­asted bug has to be fixed in multiple places. Also, imagine security flaws replic­ated.

There are many ways to fix this problem, from just fixing your overall archit­ecture to code generators to dependency injection, but—no matter what—you should fix it!

3. You ain't gonna need it

Implement a feature when you need it, not when you foresee needing it. Because, chances are quite high that you ain’t gonna need it. And if you do later need it, add it when you do.

If you are archit­ecting a module and think of everything that it needs to do this releas­e—and in the future—and try to account for all of that, you get needlessly complex software that supports things that may never even happen.

Remember: You understand the present much better than you can foresee the future. Deal with the present.

4. Minimum viable product

When creating something new, it is best to have it do the least it can do really well rather than have it do everything it could do but not quite as well. That’s called the minimum viable product (MVP).

Doing the MVP makes it easier to demons­trate the utility to a user or customer. And there is less to correct if it is wrong, and less invested if it fails.

5. An inch wide and a mile deep

The more a product or company tries to do, the less it does really well and the greater cost and complexity it assumes in doing it. You don’t want to be an inch deep and a mile wide.

It is an issue of focus. Larger organi­zations or more mature software can create "­pla­tfo­rms­" and divisions to apply more resources, but small companies need to avoid doing too many things at once.
But even in larger organi­zat­ions, the “an inch wide and a mile deep” principle should exist. Achieving it should be a principle for each part of the organi­zation or platform. Those separate inches may add up to many feet, but they each must be a mile deep.

6a. Least cost (opera­tional excell­ence)

6a. Least cost (opera­tional excell­ence)
6b. Best product (product leader­ship)
6c. Best total solution (customer intimacy)
The "­bes­t," or most effective, organi­zations are said to pursue one of these three strate­gies. As a result, these organi­zations are the cheapest, are the best, or provide the best service.
If you're focused on being the cheapest, you're not going to pursue some of the leadin­g-edge features that would be part of the best product in a category.
If you focus on providing the best service (aka customer intimacy), your product will generally get pulled in multiple directions and be heavily tailored and customized to each customer. This costs you in terms of innovation and usability.
Only two of these goals scale really well: Be the cheapest or have the best product. That’s why you can't call Google customer service when you don't get the search results you wanted.

7. Test first

In a modern IDE, you should test first. That means to write a unit test first and then have it generate your classes and such. This results in higher quality software because it makes highly testable software. It also tends to cause you to follow other design princi­ples, like design by contract.

7. Test first

In a modern IDE, you should test first. That means to write a unit test first and then have it generate your classes and such. This results in higher quality software because it makes highly testable software. It also tends to cause you to follow other design princi­ples, like design by contract.

8. Design by contract

For each routine, you should know what it is going to accomplish and what it needs to accomplish it. You do that by designing by contract. Using that approach avoids side effects, global variables, and other fallacies of the modern era.

9. Beware race conditions

Generally, a race condition is the multi-­thr­eaded violation of a design by contract.

In its simplest form: If two threads are modifying the same variable and if one thread does it first, things are fine. But if the second thread modifies the variable first, you have an error—that is a race condition.

It isn't always possible to detect these sorts of design flaws. There is no unit test that can catch them because frequently they are interm­ittent and occur only under load. Heavily defensive design and avoiding cooper­ation among threads are good ways to prevent race condit­ions. Still, even with messaging and event-­driven software, there are other versions of race conditions that are possible (just less likely). Concur­rency is just hard.

10. Conway's Law

Conway’s Law says that you are doomed to develop software that reflects the commun­ication structures of your team. In other words, you can't change the fundam­ental structure of your software without changing the fundam­ental structure of your team (which is often more diffic­ult).

11. Fail fast

The “fail fast” principle is beloved in Silicon Valley, but it’s a good one anywhere. Basically, your software should crash boldly and horribly if an error occurs.

Amateur progra­mmers check every variable for null and replace it with something like 0 or an empty string even if there is no way it could be null. Then they let the code continue even though an impossible and invalid situation has occurred. The best developers either let the null pointer exception get thrown or actually throw the error themse­lves.
In project manage­ment, it means chasing every political or technical barrier that might exist as early in the project as possible (aka “kick every bear first”).

In business, it means pursuing the bold plans that prove or disprove the product or business strategy rather than slowly investing in an eventual failure or so-called ramen profit­abi­lity.

12. The mythical man-mo­nth­/da­y/year

Adding more manpower at the end of a project makes the project later. The classic book The Mythical Man-Month) describes many of the errors in software engine­ering today—yet it was written more than 40 years ago.
The term is also used sardon­ically to answer "when will it be done?" Well, I have no control over my schedule. If I ever had nothing else to do, I'd have it done in three mythical man-days, but I'm about to have six more meetings where someone asks the same question.

Download the Essential Software Development Principles Cheat Sheet

2 Pages

PDF (recommended)

Alternative Downloads

Share This Cheat Sheet!



No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Intuit's Design Principles Cheat Sheet

          More Cheat Sheets by Davidpol

          10 Little-Known Rules in the Art of Listening Cheat Sheet