1. 2
  1.  

  2. 2

    Decent writeup, and good that it specifically calls out some of the stuff that often falls through the cracks (deployment, frequency of communication with client, number of other devs, etc.). These are the sort of things that often get lost while focusing on the main fire of the project and end up making everything else terrible.

    I do disagree a bit with one thing though:

    Signs of a healthy codebase include unit tests, documentation, and proper object oriented design.

    If there is need for a hired gun then the codebase probably isn’t in great shape, right? That being the case, those bits about docs/tests/design are more likely to manifest in the form of obnoxious excesses–things like excessive but useless documentation (a=3; //sets a to 3), tests that test implementation quirks and not user-facing behavior, and really baroque architectures that are technically impressive OO hierarchies but make it hard to change things.