Really Simple Development With Git

Once you've got your hot new app up on GitHub, you want to work on it, but you're used to the Subversion world of update-code-test-update-commit. What does a good code cycle look like in Git?

My friends, I tell you I have the answer. And it's simple.

1. git checkout -b nifty_name_for_nifty_new_feature
2. git pull [repository [branch]]
3. for each submodule of interest: cd path/to/submodule; git pull
4. [code code code]
5. [test test test]
6. git add files/related/to/commit
7. git commit -m 'nifty feature done'
8. take 5 minute break to feed puppy or check roast in oven
9. git checkout master
10. git merge nifty_name_for_nifty_new_feature
11. git branch -D nifty_name_for_nifty_new_feature
12. git push

This keeps all development in tight little branches. The branches only exist locally, and go away when the feature makes its way to master. Happiness. Especially when teammates ask you to stop working on nifty_feature and fix acts_as_pointy_haired_boss. In that case, I recommend "fixing_bug_12345" as the branch name; that helps you remember what the branch does after you get back from the really boring meeting on how you can sell more purple pleather pants to Auckland this year.

Reliable Software in 3 Simple Steps

(or: How I Realized Intro Economics Applies to Software Engineering)

The Rules:

1. Hire a small number of really good programmers
2. Hire one Information Assurance (IA) superstar
3. Hire as many testers as you can without regard to past performance

The Rationale:

• Software development is largely a weakest-link game. If you hire one crappy programmer, he'll write crappy code that the stars have to fix. They'll be slower and more resentful. Therefore, only hire really good programmers.
• Security and reliability measures are a best-effort game. You don't need a whole slew of IA stars to see the big picture. I'm a believer in the idea of "more heads..." thinking, so I might hire two experts if I could afford it, but this position has rapidly diminishing returns
• Bug fixing is a sum-of-efforts game. The more eyeballs the better. This is particularly true because even really good developers make assumptions about users. Having average-Joe people doing testing will get the developers good feedback early in the life-cycle

Finally, the credits:

• Joel has brought up these themes before, usually more eloquently and thoroughly
• Anderson and Moore come to very similar conclusions in Information Security Economics — and Beyond