June 19, 2015

Software engineering practices

Posted in Software at 03:08 by graham

A selection of software engineering practices, from notes I took at an XTC meetup many years ago. They have survived the test of time very well. Practices change much slower than tools, and are typically a better investment.

  • Keep your methods short.
  • System should always be running – this means you need either live upgrades or a cluster.
  • Always have a goal in mind – visible task. For example keep you current task on an index card stuck to the side of your monitor.
  • Code should express intent – self documenting code.
  • Verbose test names – Think of test methods names as a sentence.
  • The code is the design.
  • Do not duplicate code, effort, anything.
  • Twice is a smell, three times is a pattern.
  • No broken windows. Fight entropy.
  • Check everything into source control. Tools, libraries, documentation, everything.
  • Separate things that change.
  • Write pseudo code first and keep it as comments if it is still useful. OR, write pseudo code as methods and then flesh out.
  • Code for the common case – focus on building functionality that is the most useful first. 80% value for 20% effort.
  • Text is king.
  • Have courage – don’t talk instead of doing – resolve design debates by implementing the alternatives.
  • Take a break.
  • Proceed in small steps / small iterations.
  • Understand the domain. Better domain understanding lowers communication cost and means you can use vaguer specifications.
  • Make it work, then make it right, then make it fast.
  • Strive for a coherent abstraction – does each ‘unit’ fit together.
  • Open black boxes – look into bits of legacy systems you don’t know.
  • Automate.
  • Avoid ‘Manager’ objects – instead make them more specific: Retriever, Calculator, Finder, etc.
  • Think in terms of interfaces, of behaviour, not of data.
  • No magic: No wizards.

1 Comment »

  1. Dan Ellis said,

    June 19, 2015 at 04:22

    Think in terms of interfaces, of behaviour, not of data.

    This one intrigues me. I’ve always been fond of thinking in terms of interfaces, but I’ve increasingly been thinking in terms of data and their transformations rather than “behaviors.” Building functions that transform data without side effects seems to be more testable, stable and makes thinking about interfaces simpler.

    Thinking in terms of behavior seems to be the best path to brittleness. “Okay CarStarter, go openTheDoor(), insertTheKey(), and turnTheKey()!” God knows what’s going on in the internal state, and I sure hope you called the methods in the right order. Also, have fun mocking out all the side-effects.

    Maybe that’s not what’s meant by behavior here though. I’d be curious to hear your thoughts.

Leave a Comment

Note: Your comment will only appear on the site once I approve it manually. This can take a day or two. Thanks for taking the time to comment.