Legacy code is different.
Why would you choose Corgibytes over other software development firms? We’re experts at maintaining and improving codebases that already exist. But you don’t have to just take our word for it. Here are some more details about our experience to help you decide if we’re the right vendor for your project.
The key to keeping the best developers happy is giving them a steady flow of interesting and complex problems. Have an obscure system? Outdated framework? Tons of tech debt? Our developers can help, and they'll love it.
Autonomy, Empathy, and Balance
When Einstein needed to solve a problem, what did he do? He played the violin so his brain could rest. We've created a culture that allows elegant solutions to manifest. Autonomy, empathy and balance define our corporate culture. And every decision we make, both large and small, maps back to our core values.
The best developers have an insatiable appetite for knowledge. They want to surround themselves with other bright minds and have the opportunity to learn. Our team is empowered to self-organize, collaborate, and dedicate ten percent of their work hours to professional development.
Practices We Follow
While we draw a lot of inspiration from the practices below, we work hard to balance idealism and reality. Many of these practices have been tarnished by the people who follow them dogmatically, but when approached pragmatically, we’ve found that this combination of philosophies is a sound and stable way to maintain and improve existing codebases.
In this practice, automated tests are written before production code is written. The production code isn’t considered “complete” until every test passes. The library of tests grows over time and plays many roles:
- acts as a safety net for the introduction of bugs
- serves as another source of system intent and documentation
- reduces the risk that new features will negatively impact the existing codebase
- validates that the software does what the developer intended
One way of measuring how well this practice is followed, is measuring the percentage of production code that is executed by the test suite. We consider a value of 100% to be asymptotic, for a large system, it’s too ideal to ever be realistically achieved. A value in the 70% range is healthy, but what we find even more important is how the value is changing over time. We implement systems to measure this metric with every change that’s made and focus on making sure changes improve the score instead of degrading it.
This automated system monitors when source code changes have been made and builds the application, runs the test suite, and collects other metrics. This helps combat the “well it worked on my machine” issue which is caused by a developer not understanding how their development environment is different from what the user is experiencing. It also provides rapid feedback about whether the most recent change has “broken the build”, which could mean that the tests don’t pass or metrics have fallen below acceptable levels. This practice has value even when there is only one developer on the project and its value only grows with each developer that is added.
Quality Improvement Over Time
Alan Turing once said, “We can only see a short distance ahead but we can see plenty there that needs to be done.” Our approach follows this logic: make a small change, observe its effects, learn and repeat. While it is often useful to plan out broad goals to ensure strategic decisions, there is risk in spending too much time mapping out details based on assumptions and unknowns. While it can be tempting to try to fix everything all at once, that practice inherently introduces the most instability and you can quickly find yourself in the situation where you are introducing more problems than you are fixing. Our approach focuses on regularly prioritizing development tasks based on the most current information instead of doing a one-time grand plan that is built around assumptions.
Just as a newspaper department has editors and proofreaders to catch typos, or a construction project has an inspector, we believe a fresh pair of eyes is the best way to spot issues early so they can be addressed before changes are rolled up into production and while the problem is fresh in the mind of the person who worked on it. We often use pair and mob programming to collaborate.
We believe that using source control systems, such as Git, that capture a change, the changes author, and gives context for why the change was made is critical to maintaining and improving existing applications. Source control systems provide many benefits, including:
- Provides valuable insight into how the code is changing over time.
- Allows developers to review and discuss changes before they are accepted.
- Makes reverting changes easy, should an unintended change make its way into production.
- Acts as a backup of the source code.
- Holds people accountable, it’s very easy to see who made which change.
- Serves as an additional form of documentation and often provides the context for why specific decisions where made that traditional forms of documentation often lack.
- Is a source for valuable quality metrics such as churn.
- Enables multiple development efforts to be worked on simultaneously so you can be working on adding a feature to a future release of the application and then quickly switch context to fix a bug in the existing system.
- Removes the fear that past decisions will be lost. This allows developers to delete code that no longer has value and clutters the app, but still be able to retrieve it later should the need arise.
Open Asynchronous Communication
Developing software is just as much about communication as it is code. And using tools that enable teams to communicate effectively is critical to team productivity. At Corgibytes, we intentionally keep synchronous events, such as in-person meetings, phone calls, etc. to a minimum because we want to make sure that when they do occur, they are needed and you’re getting the most bang for your buck. We have built systems in place that encourage the documentation of issues, rather than relying on memory, notebooks, or the backs of napkins. This digital communication can be referenced when needed and also serves as supplemental documentation for the project.
We also encourage open communication by shifting the bulk of communication away from point-to-point sources, such as email, private chat, individual phone calls, etc. When everyone on the team has visibility into the progress of a project, they are better equipped to actually do the work instead of gathering information. We use point-to-many tools, such as Slack, instead of email and we highly encourage all of our clients to as well.
Need More Info?
We hope this gives you a little bit more about our approach. Should you have any questions or need more information, just let us know. We’d be happy to set up a time with you to go over any of these points in finer detail.