Today I was having an off-topic discussion with my wife who is not amused at the number of potential employers who don’t really seem to understand the QA/Test Lead role (duties and responsibilities) and the number of job ads posted which significantly maim it into other roles.
It made me think about QA automation, a popular and emerging field in software QA, and I remarked that if she demonstrated a capability in test/script automation, potential employers might assume that she can “write code” (being that their view of coding is flawed). This led me to the view that not all code is created equal.
Why ponder such a weird adage? Well, if you think about it, there is a lot of difference between “production ready” code, “proof-of-concept code”, test scripting, build automation scripting and a whole host of other types of “code” which I haven’t bothered to mention here. Just because you can produce working “code”, doesn’t mean you can build quality software, it doesn’t mean you can code.
The experience and attention to detail required to product robust, secure, production-ready code is analogous to an architect designing a building. Anyone may be able to draw or sketch a building or plan, but few have the necessary knowledge and training to produce a plan which can be developed into a real building. The same applies to writing software.
Many proof of concepts are designed to nab a big project, but the code is rarely a sound basis for a proper commercial solution. Yet we see, time after time, businesses forcing the hand of solution architects and developers to deliver a production ready version, because they “already have a working version”. Not all code is created equal.
I usually cringe when I see code copied from codeproject or sourceforge in a commercial code base. It’s not the obvious plagiarism, it’s the fact that the majority of code posted on those sites isn’t ready for mainstream publication! Many examples and samples contain massive security flaws, or conventions which are unfilled such as caching, performance tuning or scale.
As a result, when people go hunting for real development talent, they need to be very careful what they wish for. Hiring someone cheaply who can “produce code” is not the same as hiring someone with commercial experience, and a demonstrated track record of publishing their work, or seeing their project go into production. Such people are often expensive, but they are usually worth the extra money!
What can I say? The first step is to identify that there are different kinds of code quality, and that the ability to create each variation also varies. Just because I can write an automation script, doesn’t mean I can write a website, and vice versa. A more global understanding of this concept might help reduce the number of failed projects, and botched interviews. Discuss.
One thought on “Not all code is created equal.”