Just as with many other areas in life, in the software development world, there’s a lot that hangs on communication. After all, a single misplaced word can result in monumental misunderstandings, sparking people to become offended, befuddled, dismayed, or even outright outraged as they go about their day.
So while of course, at SPG, we certainly do not expect our customers to be immediately aware of all the lexicon to adopt and avoid, we would like to provide some helpful instruction to ensure communication goes as swimmingly as possible.
This is best explained through a dictionary of do’s and don’ts:
1. “Bad code”
A tired, go-to expression, “bad code” is most often used when referring to projects with vast amounts of technical debt, outdated code or requiring some serious refinement. However, because we work hard to improve your software products, calling them “bad” is neither appropriate nor fair. In all likelihood, for one, the product would have been in perfect working state at the time of its original release. So with this in mind, “legacy code” is the preferable option — as a bonus, incidentally, it is also suitable when referring to code which is sorely in need of indispensable unit tests.
2. “Bug”
Though a matter of day-to-day parlance, “bug“ is in reality an obvious misnomer, as it suggests your code is crawling with a crowd of incurable pests. This, however, is certainly not the case at all, which is why at Software Planet, we are partial to the term defect. Unlike bugs, for instance, which in order to be dealt with must entirely be eliminated, a defect can actually quite easily be fixed!
3. “Coder”
A frankly demeaning term, “coder” is frequently erroneously employed when referring to senior-level and other seasoned software developers. The main issue here, however, is it comes with a distinct amateurish connotation, as these are not merely “coders” writing brainless lines of code, but rather hard-working, professional problem solvers. For this reason, we ask our customers to please refer to our team members as software developers (developers for short) or alternatively, software engineers.
4. “Outsourcing”
While in the past, it was used in relation to any work which was carried out abroad, over the years, “outsourcing” has taken on a much more negative modern implication of abusing foreign labour in favour of reducing costs. As a result, we advance the term remote work, as this is far more aligned with what our company actually stand for. After all, though we certainly do our best to keep our prices as competitive as possible, the main benefit to our customers is not mainly related to costs, but the ability to gain access to a pool of phenomenal talent.
5. “Script”
Similar to “coder” in its somewhat demeaning connotation, whenever a “script” is mentioned, what generally springs to mind is something akin to a side project that was built in 15 minutes — and likely without an ounce of actual expertise in sight. For this reason, when discussing your applications, please refrain from adopting the above-mentioned term and instead make reference to our software solutions.
6. “Task”
Because at SPG we prefer to work with high-level requirements, a “task” does not suitably indicate the nature of the work that we are carrying through. This is why we avoid technical jargon by talking about user stories, which enable both customers and developers to be on the same page and speak the same language.
7. “Tester”
Though it may be perfectly appropriate in English, “tester” generates confusion in the mind of Russian and Ukrainian speakers — by conjuring a random image of a device used to measure power lines. Of course, as a company with a large number of Ukrainian developers, it is best to ensure that our team members will be able to understand you well. This is why we kindly request that you stick to the term QA, or Quality Assurance engineers if you don’t mind the extra words :).
When in doubt, look it up!
By following this simple dictionary, you can communicate with our developers with confidence and ease and avoid unfortunate mix-ups that can hamper your project’s development.
But of course, to err is human, so remember that these are guidelines, not a rigorous set of directives, and be sure to let us know if you have any questions at all.
