Bullet Points About Software Development

Recently I got to thinking: I’ve been doing software development professionally for over a decade (gosh…).  I must have learned something, right?  Right??  So I thought I’d brainstorm some of the things I’ve learned, and maybe blog about some of them in more detail later.

These are mostly more recent insights.  Hopefully there are more things I’ve learned earlier, which I’ll list in a future post.  Let me know if any of these really resonate with your experience, or if you disagree.  Also, if there’s anything you’d like to hear more about.

• Design up-front can help
  • If you do big requirements up-front, you need to do big design up-front
  • Or at least, you will need big refactoring in the middle
• What requirements are for
  • Naive CS understanding: tool for developers to know what to definitely build, what to maybe build, capture context, and flesh out a model of the system (pre-design)
  • Gov’t contracting understanding: a list of features that contractually must be delivered. All of them.
    • Pre-design is still helpful info to include with requirements
  • Synthesis: Internal vision document, shared with the team
    • Keep the requirements and the vision separate.  Share the vision with the customer only after considering how they will perceive that information
• Hofstadter’s Law – it always takes longer than you think
  • Corollary: Avoid giving estimates.
    • Especially don’t volunteer estimates.
    • Just say you’re working on x, or will work on it after you finish y, fate permitting.
  • When you must give estimates, break down into subtasks first
    • Preferably, do the design before estimation
  • Hypothesis: if you can estimate it, you should have automated it
• You will have to revisit the code later, so code and document with that in mind.
  • You never know when you’ll be interrupted by more urgent work, which will take longer than you thought, before you can come back to what you were working on, so code and document with that in mind
  • Well-designed command line and debug interfaces are helpful
  • Refactor and document whenever you can get away with it
• You can write good code and bad code in any language
  • Some take more effort than others though
• A halfway done big refactoring project of bad code is worse than just the bad code.
• Morale is a multiplier
• There’s nothing more permanent than a temporary solution.