How to explain to a layman the disadvantages of HardCoding and not using OOP principles?

Organize a meeting. Involve a few more people than just your immediate manager just as 3rd party observer.

Explain in very conceptual terms what you are doing and how long it will take, and explain options.

For example:

Dear Manager & Co, you have expressed that you are seeking to build
a Business Dashboard and to you the end product look simple. But to
build it it is not so. I need parts A, B, C, D, and they take
respectively 1 month, 2 month, 4, month and 8 month to build.

There are also 2 approaches to building software: Hardcode and OOP.

Hardcode will make it work sooner but it will create a lot of problems
for me and other programmers down the road. This phenomenon is so
frequent it got a name of Technical Debt.

OOP will get you the product in X amount of time longer, but it will
be much easier to modify and change it to your needs over a longer
period of time.

Use analogy, for example .. it may take you faster to build a ladder to climb on top of 2nd floor building, but ladder cannot hold two persons at once and will break. It will take you a lot longer to build stairs to the 2nd floor, but many people will use it for a long time. It is a lot easier to maintain stairs in the long run, because the structure is sturdy, while ladders have to be fixed more often from wear and tear because they are just planks hammered together with nails.

Now with that information what product do you want and how well-built
do you want it?

In the end, manager will have to

• trust or not trust your judgment (you are the expert, she’s not)
• make a choice (Hardcode with technical debt or OOP)
• hire or not hire more programmers to help you

To summarize you have to

• explain in conceptual terms (without too many details) what you are tasked with to do
• trust your manager to trust you (or get out)
• ask for what the manager wants you to build, once they have knowledge of their options

Also, have a good idea on time estimates of how long it will take you to build parts of software using this or that way, and why, and be prepared to answer questions about it. It may help you to put together a document on proposed software features and approximate time and complexity that is involved into making them happen.

And also, you are the expert and you can refuse (or not even mention) that there are deficient ways to do the job. You can refuse to do bad work.

Firstly I do not see this as a conflict between hard coding (or rather quick-and-dirty) and OOP.

I am a proponent of OOP, but sometimes what is called for is not a long lived solution, sometimes quick-and-dirty is exactly what is called for.

Are you sure that your manager wants everything to be perfect? You really need to discuss what your managers expectation is, before you can discuss how best to achieve the goal.

Maybe your manager have been tasked to make a quick throw away prototype as a proof of concept.

If the goal is a long lived solution, then it is time to discuss how to avoid technical debt. For that a manager often needs to know about best practises not OOP.

Don’t try to explain or justify technical design decisions for a non-technical manager. You should not bring up terms like hard-coding or OOP. Trying to explain OO design principles and so on to a layman with no technical background will get you nowhere.

It is not even clear from your question if this is about “OOP” versus “hardcode” (whatever that means) at all. For all we know she might still think the “quick and dirty”-solution would take too much time, or maybe she wants the maintainable solution, but thinks your are not working enough hours and spending your time on Facebook.

You need to listen before you start teaching. It is typical developer mentality to think any disagreement must be because the other part simply does not understand, hence “how do I explain..”. But it is not clear you have made enough effort to understand the reason for your boss dissatisfaction.

Before anything you need to understand why she don’t have trust in you. Since you are the sole technical person she need to trust you with technical decision, so you need to figure out why you have lost this trust and what you can to to gain it again. An organization simply cannot work if a non-technical boss does not trust the technical lead with technical decisions.

You need to ask her. What is her grounds for thinking you are taking too much time? Does she think you are slacking off, or does she think you are over-designing and need to do less work? What is her frame of reference for how long she believe a task should take? Does she have experience with other developers on similar projects? You need to understand this before you can respond.

It is possible you have a manipulative boss who is trying to shame you into working harder or take unpaid overtime. It is also possible she have legitimate concern due to bad communication or lack of transparency in your development process.

I’m going to talk about some changes you may be able to make, not because I think you are in the wrong here, but because yours is the only behavior you have control over. I learned a long time ago that better arguments rarely convince someone. You need to change something in order to show them.

You mentioned you believe yourself to be an agile programmer. I don’t know if that means you are practicing “agile,” but I would recommend:

• Making a user story backlog and sitting down with your manager to prioritize it.
• Delivering incremental improvements every two weeks if not more frequently/continuously.
• Having a demo of those improvements every two weeks.

In my experience, this feedback cycle and especially the demo can really change the dynamic. It shows that you are getting things working. You can showcase why it is an important step. It keeps you focused on actually finishing things. You get better at explaining the need for things in a way management understands. And management typically gains a better appreciation for the amount of work that goes into keeping the quality high.

It becomes sort of, “I’m proud of the work I did the last two weeks, so I’m inviting you all to a meeting to show it off,” instead of the manager thinking, “I have to get status from him again. It feels like he’s hiding something from me.” Managers worry less about “behind” schedules when there is more transparency.

I’m going to make the assumption this question is just looking for a metaphor/explanation to someone who is not a programmer. Also, you drove this answer to work this morning.

I would explain to your manager that building a program is a lot like assembling a car. Most cars get built in factories by a team of folks, all using a similar set of patterns and conventions to arrive at the final product. Each of the parts of the car also made a certain way, so if its cheaper to get them from another place, you can without affecting the final function of the car (refactoring). Doing things this way makes it easier put on a body kit (change how the car looks), make it go faster (optimizing the engine), or put things like rocket launchers on it (weird, but adds a new function).

The other benefit to building the car like this is that if the car breaks down or gets in a wreck, you can take it to a body shop (front end developer) or mechanic (back-end developer) or the dealer (full-stack developer) to work out what broke and replace it easier or do easy things like change the oil (maintenance).
Its worth emphasizing that the time put in up front during initially building the car is paid back in less time that you’re stuck fixing – or worse rebuilding – the car after someone crashes it.

Compare that to a car that had entirely custom parts built very fast by a car builder who used custom parts and died all of a sudden. If he didn’t follow rules or accepted conventions anyone else does, it could take years to unravel how the car’s put together before you can even fix it when it breaks down.