7 Software Development Processes and Guiding Principles
At Earnest, our values, among others, are to deliver high-impact results and create lifelong value for our clients. We try to enforce these values in Earnest Home Engineering, a team of three software engineers and one QA engineer. Here are seven software development processes and guiding principles that we use on our team and tidbits on how we utilize them.
1. Pair Programming
Pairing is a development technique where two programmers work together. This allows us to have a shared context when developing on feature, and generally enables us to be more in sync as a team. Pairing also prevents knowledge silos, thus people from becoming single points of failure. We don’t employ a strict rule on when to pair. It’s fine if one of us works alone for a while, however, sharing is encouraged and the team is open to pair at any time. Pairing is also great for onboarding, which is why we pair with new members when getting them up to speed.
2. Trunk Based Development
Trunk Based Development is the practice of committing code to one shared branch, also known as the trunk. For us, we commit directly to master. Short-lived feature branches do exist, and we sometimes have pull requests, however, most of our work is done directly on master. This works really well for us because we have a relatively small team, and we pair frequently. It gives each member of our team full autonomy and expresses more faith in them and their judgement, not to mention moving faster. We also believe having a robust set of tests for our system helps with trunk based development, which is why we write a lot of tests (more on this later).
3. Testing Pyramid
Our team relies heavily on automated tests and follow the testing pyramid structure. We bias towards writing more unit and integration tests because they are cheaper, and less brittle. End-to-end tests are there to cover mostly the happy paths, and are fewer in numbers than our unit and integration tests. There is also a balance, though, in that we don’t just write tests for the sake of having them. The goal isn’t to have a high test coverage, it’s to make sure that everything important is covered. Generally, our metric for deciding if a test should be written is whether or not it would help us sleep better at night.
4. Minimum viable feature
We work closely with Product and Operations to define upcoming work. The work that we lay out is structured in a way that each layer on its own provides a clear business value, and is immediately usable, especially the first version of a feature. This allows us to iterate faster, get feedback from our users to further improve our design, as well as better inform us on the next piece of work. We usually never plan more than a few weeks in advance, and leave plenty of room for change.
5. Options Thinking¹
Because we lean towards making data-driven decisions, sometimes we just don’t have everything we need to make them. This is where options thinking helps our team. Generally, we delay making hard and fast decisions as late as we can, and favor doing things that will give us more options in the future. For example, we delay architectural decisions because those decisions are hard to change. We implement features in ways that will give us the option of easily changing them in the future. Similarly, we write integration tests that assert on the outcome given some input, rather than testing the implementation because it gives us the option to refactor later without having to change the test.
6. What does ‘Done’ mean?
A feature is ‘done’ when it is deployed in production. Even better is if we have feedback on its usage, i.e. has it improved our conversion. Preferably, we don’t consider a task done until it is in the hands of our user. This is important because we value feedback on the usefulness of our work. Furthermore, clearly defining what done means helps us see things through to the end and prevents us from simply marking tasks off of a list.
7. Follow your heart
Lastly, when in doubt, we follow our hearts. We rely on our instincts and try to be explicit about why we make certain decisions. Programming is hard and sometimes when we don’t have everything we need to make a decision. So when in doubt we just follow our hearts.
What software development processes and principles does your team use? Do you like what you see here and would like to join us? Our team is hiring so please email me at peter.prakobkit@earnest.com, or visit us here.
[1] More on options-based thinking for software management here
