That pesky hard-coding

The other day I was reviewing a request for a quote and a statement of work for a project I've been working on for a while and my eye caught an interesting statement I haven't noticed before:
...the proposed approach of refactoring the codebase and procuring COTS products for replacement of hard-coded functionality is the lowest risk and most cost-effective approach to delivering an improved solution...
Hard-coded functionality? Huh? What's that?

Well, technically, all functionality implemented by means of software code is hard-coded in a sense or in other words, doesn't change unless you change the code logic. That's actually perfectly normal and good thing. You wouldn't want your software to go all fuzzy and produce different results each time given the same inputs. So clearly, whoever wrote the request for a quote didn't understand what hard-coded means.

The term hard-coded is used in a slightly different context and is considered a negative practice when input data or configuration data is embedded in software code as opposed to obtaining it via input parameters, configuration files or other appropriate external sources.

We live in a world of buzzwords and if you work in Technology domain you will know that use of technical jargon in widespread. The implications of poor or incorrect understanding of terminology, or technical jargon if you wish, however could lead to some interesting conversations down the track.

So for example, once we do our work and propose a target architecture for this solution we might get asked how our proposed solution addresses hard-coded functionality. Well it doesn't, the solution's functionality is still hard-coded and the hard-coding wasn't even a major problem in the first place. So if we haven't replaced the hard-coded functionality how do we explain that the proposed target solution is improved?

Comments

Popular posts from this blog

Poor Man's T-SQL Formatter

Essential skills - user experience