There’s this notion within the software industry that a company’s process usually scales with its team size. While this certainly makes sense on a lot of levels (instances of managing 5 programmers vs managing 25), we tend to prescribe a need for a better process to companies who are going through some tough growing pains.
However, I believe ants lead to an interesting secret about how we should structure our teams. Ants can lift weights far exceeding their own personal weight (due to a strong exoskeleton). When multiple ants organize, small teams can lift a significant amount of weight. This law is certainly scalable in a realistic sense, but its beauty lies in how important small teams are.
You might roll your eyes at me while reading this section. Maybe you’d fire back: “We already have a testing framework, Taylor!”
Yet, the true question is: Do you leverage your testing framework in the best way possible?
Here are a few good questions to ask yourself (in the Rails space):
- Do you separate your JSON and HTML controller tests? Do you separate tests by namespace?
- Do you provide other developers means to replicate the data relationships in your local app?
- Is your master branch “clean” in the sense that all tests are green?
- How often do you write tests? Is there a pattern to when and how your write them?
In a perfect project, all of these (and more) would probably be covered. However, there’s a great enemy of testing: deadlines.
Many of us would rather have an untested “complete” app than a fully testing “incomplete” version. This mainly has to do with the viewpoint of the consumers and clients: their enjoyment and payment is initially based on a delivery date. Its not until later that they begin to notice the hidden grime within the product. So, theoretically, you could fix all the glaring mistakes before the client / consumer notices.
Sounds easy, right?
A lot of companies go along with this idea, even Apple. There’s a running joke about products saying that: “version 1 always sucks.” This certainly isn’t entirely false. Every product is always going to have problems and improve over time. But what about products that die an early death because of the overwhelming amount of flaws?
Milestones can certainly help!
In my opinion, milestones get lost within the Agile Development world. While discussing the effectiveness of Agile Development is a way bigger conversation, milestones often come off as one of many decent advantages of being “Agile”.
However, what milestones do effectively is offer up a global grocery list of items that need to be delivered in some form before a certain date. If you structure your milestones to be knock-out major features early on in the development cycle, it leaves room for developing auxiliary and vague features later.
Release candidates are essentially milestones after they’ve happened. The reality is: not everything from your planned milestone is going to end up in a release candidate. However, release candidates can be a lifesaver of frozen code. Think if some sprint went horrible wrong, and you can’t release new features to a client. You could still deliver a release candidate that meets more quality QA standards.
Pushing features directly from a commit into the live server is a really dangerous thing. Sure, you can trust fellow contributors and commits. However, testing often can’t keep pace with rapid development close to a deadline. We need release candidates to give us a physical representation of what’s stable and what’s not!
I love what Github offers in terms of open-source versioning. If I wanted to be “cutting edge”, I could download the master branch of the project and venture into the great unknown. However, if I wanted to use an older version of a project, I could download a release file from the “Releases” section. Docker does this particularly well with Docker, Compose, and Machine.