By Soo Somerset, Green Mars CEO
It’s not uncommon for a small company to have a “one person software engineering team”, where a single full-stack engineer writes and supports all the software for the company’s main technology. The advantages of a single in-house engineer include having someone on hand to participate in discussions about requirements, address bugs quickly, develop product knowledge, and generally be dedicated to solving problems for the company. However, there can be drawbacks as well.
We often see this scenario: An engineer gives their notice, and the state of the software falls into chaos (through no fault of anyone involved). When that engineer transitions out, the disruption can mean major costs to the company, both in terms of lost time and resources, especially if the departure is poorly timed or quite sudden.
Faster Development, Lesser Maintainability
As a single engineer, one writes code in one’s own style and without the expectation to work with other engineers. The individual who wrote the code will most likely be the one to fix it. This permits much faster development, and the process, to be honest, is more satisfying for a developer — to write code without the encumbrance of design, coding standards, or (though rarely admitted) thorough testing.
Coding in Isolation
There is also the challenge of “delicate” code (a.k.a. “kluge”, “spaghetti”, etc.), where the solution works, but it’s been written in a way that is ultimately not maintainable by human hands. This occurs when engineers must find a way to solve a complex problem without the benefit of collaborating on ideas, and what results can be, well, a bit of a mess, but at least it works. Then, as features grow and usage builds, this code can become part of the foundation of the platform and create issues later on, whether or not the engineer is still working there.
In short, while there are a lot of good reasons to have a one-person engineering team, those reasons come with significant risks.
Lending a Hand
At Green Mars, we have supported many clients who have called after their consultant or their one engineering resource has had to suddenly leave (for any reason) and they are stuck in the void left by their resource. These are considered “Projects in Crisis”, and we have crafted a solid solution to serve those clients.
However, we also realize an opportunity for clients to evade that void altogether, and that is by prudent use of outsourced support — what we call “auxiliary support”, which provides a lightweight, cost-effective framework to team up with the resource and keep them in the right mindset for maintainable software.
What is Auxiliary Support?
Auxiliary support starts with code reviews. Our engineering team uses coding standards that are intended to promote maintainable code. Our practice of code reviews is focused on clarity and constructive feedback to encourage engineers to see the benefits of our standards. They are commonplace in our company as part of our work.
Design review is another feature of auxiliary support, where your engineer can bounce ideas, make sure they’ve addressed the whole problem, and considered details that could have been overlooked. With the objectives of the software held firmly top of mind, design support is about asking good questions and supporting strong documentation in preparation for testing.
Another aspect of auxiliary support is quality assurance (QA) testing. Our team tests the connected areas of the software to ensure that the changes have not disrupted functionality elsewhere in the code. Having outside resources objectively test your code and return clear steps to reproduce bugs confirms your software on two levels: first, that your requirements are clear and accurate enough to be tested, and second, that the functionality works as the requirements expected, all without taking up valuable resources in your own team.
As much as I love a good engineer, time management is rarely among their best strengths, which means that they are often over-committed and running behind schedule, and nearly always with the best intentions. This is a sign that project management as an auxiliary service may help a great deal, to assist in organizing the engineer’s workload and priorities, and support the consistency of their work.
Over all, auxiliary services in these forms make your engineer better at their work, more efficient, more reliable on deadlines, and more satisfied in their job. The collaborative nature of these services makes the role more fulfilling, and with added accountability, the software quality benefits.
But what does this service cost? Well, that depends on you — we recommend about 3–5 hours per week of support of this kind, maybe a little more for additional testing if a big release is coming up. It could be as little as 10–15% of the engineer’s salary. That’s a lot of value for the cost.
Then there is the perception of the “hassle” to bring in another team to support your engineer — it would slow down work, not to mention trying to coordinate time to make it happen. But we think you’ll agree, there’s a lot of benefit in slowing down just enough to produce quality work, then once that rhythm is established, efficiency goes up.
Finally, even if the above concerns aren’t relevant, you may think this may be a good idea for “later”, because there’s just so much going on right now. To this, we offer a simple response: all things being equal, it will never be easier to do this than right now, because the future will just get busier.
If these services sound like they’d be of value to you, please get in contact with us. We’d love to help support your team!