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 Reviews1: 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 you will face in most teams, there are developers with more overall overview able to write better code with less errors in less time than others. (One of the reasons is the varying amount of experience.) Take measures to keep all developers on (your) track, like pair programming and code reviews (at least two 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 art2, 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, but they 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.3.


1Although code reviews are a development team's topic, the organisational conditions has to be set up. Code reviews need time in which developers are not writing code.
2 Programming has it's own aesthetics, creativity and beauty, but, just as a carpenter, who's work is often a result of design, beauty, function and form, too, the money is made with usable products, not (only) with beauty, although beautiful code is, in most cases, part of working, maintainable and sustainable solution.
3 Sorry, designers, this might a bit exaggerated (but only a bit), but that is my experience.

Software design best practices

  • Unit Tests and Test Driven Development: Unit testable code leads to good software design and allows refactoring
  • 'The Run Script'4: Instead of documenting 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, 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, this container avoids side effect with your local system.
  • Development environment: Make sure your development environment (if the software needs more than the run script), can be set up from scratch automatically.
  • 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)
    • easy to rollback your system
    • easy to set up a new environment from scratch (see above)
    • possible to use whatever IDE to develop, do not force your team to use a certain software/IDE
  • Avoid inheritance...: Inheritance causes way more software design issues than you might think. There are lots of articles out there about this issue5, 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, ...
  • Read... (and understand) Robert Martin's Books6 Clean Code and Clean Coder.
  • 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 necessary7, don't do it. Strive for simplicity.

4 There is an excellent article about this concept from Thoughtwork's Pete Hodgson.
5 See http://programmers.stackexchange.com/questions/75189/why-avoid-java-inheritance-extends,
http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html,
https://en.wikipedia.org/wiki/Composition_over_inheritance,
https://blog.pivotal.io/labs/labs/all-evidence-points-to-oop-being-bullshit,
http://c2.com/cgi/wiki?ArgumentsAgainstOop,
http://blogs.perl.org/users/sid_burn/2014/03/inheritance-is-bad-code-reuse-part-1.html, ...
6 That is a very personal recommendation, but it definitely will help!
7 (Un)fortunately this decision will mostly be taken by other people (product owners, customers, stake holders). This decision has to be accepted. But you can make it transparent to them so that they have a better information basis to decide if they really need this few pixel alignments more.

comments powered by Disqus