Non-Negotiables For Software Development Process

Putting together some content for the joint SAS/DSH Workshops "Doing Software the Pragmatic Way" at GDevCon N.A. You can get tickets here. I was thinking a lot about running projects and what makes for a successful project. This kind of goes in line with my fundamental assumptions about coding and my Sam Evaluation.

My Non-negotiables

These are things that in my experience have to be true for every project to be successful. In the beginning of a greenfield project you can, of course, build these things up as you are building the project. However, any time I inherit an established project and any of these are missing, I stop and implement them immediately. There is no point in writing any production code until you have these things implemented.

These non-negotiables are meant to be prescriptive, not descriptive. As an example, you have to have testing in place. However, I am not going to tell you what testing framework to use or how many tests to write, or what needs testing. The goal is to be able to have confidence that what you ship is functionally correct. For some of these concepts, there may be multiple different solutions.

• Versioning - You need to be able to know what version of the software is running at any given time. You need to be able to tie that version to a specific set of source code files. This aids in tracking down bugs. It also aids in auditing systems. You need able to roll back changes and see the difference between versions. I will specify the implementation here a little bit - you must use a Source Code Control tool (Git, SVN, Mercurial - it doesn't matter which one). Zip files and share drives just don't cut it. In addition to Source Code you should consider versioning configuration. Any reuse code should also be versioned.
• Testing - You need to be able to verify that the code you are about to ship is functionally sound. Ie. it does what it is supposed to do and there are no known bugs.
• Code and Architecture Quality - You need some way of maintaining a high-level of code quality and architectural design. This helps to keep your code readable and maintainable and helps keep down the cost of adding features and fixing bugs.
• Feedback - You need a way of getting feedback. There are really 2 types of feedback I care about. One is feedback from the customer. Are you solving their problem? The other type of feedback is internal. How are your current processes working for your team? You can't solve a problem you don't know you have. Also the sooner you know about a problem, the easier it is to solve, so you should be getting feedback regularly.
• Clear Agreed Upon Way of Working - Within your team, you need to have an agreement on how you are going to work: What tools and processes are you going to use? How are you going to structure the code? How do you divide up the work? There need to be clear answers to these questions (and probably some others I'm missing).
• Onboarding Documentation - You need to be able to hand your project off to someone else. You may not plan on leaving a project, but life happens. In order to hand off a project you need some very basic documentation. Things like: A high-level description of the problem the program solves. An outline of the overall architecture. How to set up a development environment. How to build the program. How to run the program.
• Build Process Documentation and Automation - It is important that you build the software the same way every time, whether that is following a manual checklist or through an automated script.

What am I missing? What are your non-negotiables? Is there anything on my list that you find non-essential?