Ever since I’ve been developing software, I have found that explaining what programmers do to non technical people has been as challenging as developing itself. You may ask why this is even important? Well, there are many reasons actually. Here are a few I can think of:
They will understand
- Why the time estimate is so long.
- What the repercussions will be for cutting corners.
- What the risk is.
- What needs to be done “later”.
- Why this piece of code is so great
From my experience, clients/bosses/project managers that understand more about what you do is generally better than the opposite. You don’t want to overload with technical jargon but being able to explain with analogies for them to relate to is useful.
So, to explain the title of this post, “Hardcoding and Spreadsheets”, I think you may already know what I’m getting at. Most people have used a spreadsheet and know that formula based sheets save a lot of time. If you don’t use a formula when you can, and instead “hardcode” a constant number into a cell, any future updates you or someone else makes can “break” the spreadsheet. Even worse, you may not even know it’s broken. While this seems very amateur, I would not be surprised if hardcoding in spreadsheets has led to many mistakes, and potentially financially devastating results for accounting firms. Using a formula requires identifying redundancies and factoring out any opportunities for duplicate data to be required. For example, if tax is defined by two cells, 5% for GST and 7% PST, then the total tax is defined by the addition of these two cells. If you decide that you’re too lazy to input GST as a separate cell and instead “hardcode” 5% in the formula for total tax, then you may have more than one place to update if GST changes. Okay, I know this is not ground breaking material, but it’s pretty much the same issue we developers face on a daily basis.
Hardcoding a particular piece of code is bad because if it can be factored out so the logic is more sound, it should be done. In most instances, this is the case, but quite often deadlines and/or laziness conflict with this goal. Perhaps the client needs this particular piece done by tomorrow and you know that if you do it the “right way” it will take 2 days. Or perhaps, you have a party to go to and decide to fix it “later”. So, you think “hey, I can hardcode this and deal with it after”.
From a developer’s perspective, it’s not just “hardcoding” but poor programming practices that must be avoided where possible. As developers, we must weigh the technical and business risks of our choices and decide the best route. It’s not easy and requires experience to pick a choice. For instance, hardcoding can be a great solution if the application will exist for a short period of time. It would be a waste of a budget to code the most elegant piece of software that will only serve one very specific purpose for a short period of time. On the other hand, if the client mentions “reusable” and future use, then you should consider this and explain why this would cost more.
The difficult situations are where the client or boss decide they don’t care and want short turnaround time, reliability and flexible software. There is little a developer or anyone can explain to an unreasonable person. But if they are willing to listen, attempting to relate software to common tasks like formulas in spreadsheets could help. The last thing you want is to explain that this “bug” was their fault. As a developer, communication is one piece of the solution to enable sound development.