One of the difficulties with budgeting technical projects is because there is a lot of variance in how long it may take one developer to do something from the next, and from a non-technical perspective some solutions look the same, but may function entirely differently from a code-perspective (which may introduce problems later).

Here’s my article explaining some of the different reasons for why simple things may take longer than expected and my advice for what do about it when hiring a developer and planning your project.

First, let’s take a look at a simple example…

Let’s say I have a button.

My Button

And I tell my developer to change the color of the button from blue to red.

Actually in code, this is very simple. Take a look:

<button 
	type="button"
	class="bg-blue-700 text-white rounded-lg 
	text-sm px-5 py-2.5 mb-6"
>
	My Button
</button>

There’s a line of text that says “bg-blue-700”. I change this, to “bg-red-700” and…

Voila: My Button

This should take, 1 minute tops.

Okay, but let’s say I have 2 buttons… My Button My Button

Then by that logic, I need to change it x2 times. So maybe 2 minutes top, but really nothing more.

But what if I had 200 buttons?

The thing is…

In coding there’s a principle called DRY which stands for don’t repeat yourself which is a key principle for developers to follow because it reduces the amount of code in a project and makes it easier to update your project as well.

If, instead of copying and pasting this button code and changing each individual one, I can “encapsulate” it into a component, then I would only need to change it once.

Long story short. For example… this new button here:

My Encapsulated Button

Looks like this instead:

import ExampleButton from '../components/ExampleButton.astro'

<ExampleButton color="bg-red-700" />

And the file itself, includes the code for the button we referenced earlier. So as long as I use this component for everywhere I need a button, I can then change only this file, and all the places where I added my ExampleButton code will change as well.

It doesn’t matter if I have thousands of buttons… I can just change 1 line of code, and they will all change.

import ExampleButton from '../components/ExampleButton.astro'

<ExampleButton color="bg-blue-700" />

---

This example has a lot of implications and explains a lot of problems that crop up in code bases.

What if the developer copy and pasted several variations of buttons? Some in red, some in blue, some in green, etc.

They’d have to search for all the buttons, change the ones that are relevant, and make sure the ones that are supposed to be different remain different. This can get rather time-consuming, especially if there are lots of files in the codebase, the developer is new to the codebase, and/or there is uncertainty on what files do what.

What if there is a component button, but that component button is only used in some places and not others?

Now take this button example and expand the scope to all the different elements you see in a website… buttons, links, tables, dropdown menus, popup menus, cards, forms, tabs, etc.

That’s a lot of wasted time searching for small things to change.

What does this mean for a real-world project?

If you’re designs for buttons, menus, etc. are all very unique and custom, your project is going to take longer to build AND you DON’T want to use a component library.

Component libraries like MUI5, shadcn/ui, bootstrap, etc. are nice because they create components styled out of the box so it’s a given that you’re going to use those components and not your own. You can customize them, but at a certain point if you’re trying to customize it too much you’re better off doing it from scratch.

If you’re happy with the general feel of a component library and its designs, then you’re good to opt-in to a framework.

A good developer will attempt to code and develop in a way where other developers can read and understand their code. A lot of time is wasted on reading and searching for code only to have it break or having missed a spot where it was supposed to be changed but wasn’t. Technical debt is really just people (previous developers) writing in a way that’s only easy for themselves to understand.

…

Of course, this article is only touching the surface, but stay in the loop and subscribe below —I’ll be writing more about explaining tech to non-technical founders so we can avoid technical mishaps earlier in the processs, rather than later.