Defining key factors for successful software development

A while ago I was asked about my opinion of key factors for successful and quality software development. There are a few lists published from more or less famous programmers, like this excellent collection from Jens Rantil or this from computer game development legend John Romero (scroll down to the bottom of the article).

Both of these lists do not separate more general, organisational topics from detailed, programming design specific guidelines. Both aspects are important, but the latter ones can be implemented within a development team, while the former topics might need to be addressed to a higher organisational level and though might be, depending on your organisation, more difficult to implement.

I won't mention evident best practices, such as "use a version control system", "set up a continuous integration", and so on, I assume nobody will argue about those points.

Organisational key factors

• Code Reviews^[1]: As a development team member, review code, as much as possible, not to control your team members, but mainly for knowledge transfer. If several people are working on a system, it will help to prevent re-inventions and will save time on further development if the team members are aware of the changes done to the code they are working with.
• Mentor-ship in heterogeneous teams: Heterogeneous is a complicated word for a simple fact that you will face in most teams: there are developers with more overview able to write better code with less errors in less time than others. One of the reasons is the varying amount of experience, so take measures to keep all developers on (your) track, using e.g. pair programming and code reviews (with at least two developers in front of a screen forcing them to talk directly, unlike above, without code review tools), short training or live coding sessions, ...)
• Be pragmatic: No ideological discussions. Strive for pragmatic solutions. Software development is a business, not an art^[2], you earn (or your company earns) money selling solutions, not the most beautiful piece of code or technology.
• UX: If your software needs an UI, especially a web based UI, try hard to get an UX expert which takes the principle UI decisions, not the so called designers. Most designers (all I met) are perfectionist about their layout and design^[3], but they often don't think beyond it. This means that they don't think about what should actually happen if the user clicks on their so carefully designed button or what should happen if something goes wrong^[4].

Software design best practices

• Unit Tests and Test Driven Development: Unit testable code leads to good software design and allows refactoring
• 'The Run Script'^[5]: Instead of documenting extensively and describing how to run your project, create a script running your software on a developer's machine (I recommend container or virtualization technologies (Docker^[6], Chef, Ansible, ...) over build systems (Maven, Gradle, ...), if possible, out of two reasons: First, you have a running example of a possible deployment scenario; and second, a virtualized container avoids side effects with your local system.
  I ususally set up both.
• Development environment: Make sure your development environment (if the software needs more than the run script), can be set up from scratch automatically. Minimize or avoid ramp up time, developers need to start the project. Whatever is important to know to get started, should be documented shortly in a kind of README^[7].
• Further Automation: automate all tasks you have to do more than once, this includes acceptance tests/web tests. Automating will not only save you time, it will make your environment more maintainable (testable). This implies automation of release todos.
  
  The three bullet points above, unit tests, 'the run script' and setting up the development environment are parts of automation, as well.
• Encourage innovation: With good and motivated developers innovation will happen, if the technological framework and project set up won't stop it. Assure that it is...
  • easy to switch development branches (use a clean repository^[8])
  • easy to rollback your system
  • easy to set up a new environment from scratch (see above)
  • possibility to use whatever IDE to develop, do not force your team to use one OS/software/IDE
• Avoid inheritance...: Inheritance causes way more software design issues than you might think. There are lots of articles out there about this issue^[9], consider Robert Martin's Book and Gang of Four's Design Patterns, as well.
• Operation awareness: You may call it DevOps or not, keep your developers aware of or make them take part in the deployment and operations of the software they write, this will help them to keep in mind topics like caching, distribution, synchronization, sessions, monitoring, performance, redundancy, concurrency, ...
• Keep your Code clean: Read, understand and follow Robert Martin's principles in his Books Clean Code and Clean Coder.
  As developers spend about 10 times more time reading code than writing code^[10], you can imagine that speeding up the reading process will help your efficiency.
• Frameworks: For the same reason: choose a framework not (only) considering speed of development (unless you are prototyping), but considering the cleanness of it's architecture and it's principles to keep your code clean.
• Be aware of the Pareto principle, which is so true in software development. Keep this in mind when estimating and when communicating that "80% of the task is done".
• Be pragmatic: Again.
• No ideological discussions about technology.
• If the 20% of the work of a certain task which needs 80% of the time is not really necessary^[11], don't do it. Strive for simplicity. Remember: Quality, Tests and clean code is no option!

Thanks to Don Swinscoe (@dswinscoe) for re-reading and correcting this text as a native speaker.