In my around 14 years of working experiences I have found these 5 cases almost impossible when need to be done later. Such small amount of time not spent at the start of the project can grow into gigantic monsters. In all cases, it's on the experience and solid judgement of decision makers to avoid these.
1. Make sure you can run everything
Most likely you can run your frontend with npm start, but can you run any of the backend servers locally? Can you test cronjobs locally? Do you have a local DB to play with? Can you run the exact docker image that will run and can you log into it for debugging?
When crisis hits and stress kicks in, if you can't get access and run and observe any part of your environment you might be losing days while waiting for builds to go through, tests to run and fail, users to report things.
If you let people create more and more obscure configurations that requirs arcane knowledge of the right environment variables and system settings held by a cabal of insider engineers, you shoot yourself in the foot so much, that no 360 performance review will get you out of it.
("PRO" tip: Hey, but you can always fire the engineers who complain the loudest!)
2. Flexible design
Remember the good ole' times when you could get away with optimizing for HD/Full HD? Or just two resolutions? The latest years did not converge the device we are viewing content on but diversified them. "Looks great on the company laptop." is no longer cutting it.
If you spend time at the start of your frontend project defining the main proportions of your application, the sizes of titles, proportions of using flexible sizes that can grow to a 33 inch monitor and shrink to a mobile phone continuously, then later you will just need to make small adjustments.
However later, when the average full-stack dev made some assumptions and relied upon margins being always exactly 15pxs it's going to be a nightmare.
Once every engineer is "born into" a flexible design they would themselves check if their components fit the design principles.
With a new project we did exactly this and after the early days of figuring out how relative sizing would work, I would say it is the same effort to continue keeping it flexible, compared to old projects that had no flexibility.
(PRO tip: read a couple of articles from https://every-layout.dev/ - they are great! 👍)
3. Working dev server environment
I have been working with teams and companies where the dev environment was always working (even dev! not just stage and production) and I was working with teams where not even stage was stable and people were just firing up their own private little microservices, tested on their little bubble of mocks and hoped that after deployment it will work with production data.
Once you have 50+ servers running and many of them are outdated/down for a reason, you won't be able to have a working environment ever again. Even if the teams themselves know it's not good, they will have deadlines of shipping features, not a working DEV environment, which they could ship earlier having a working DEV environment.
Here the only thing you can do is to check with each new server that the DEV environment is keep working. Usually it is significantly easier to fix just one server having a bad day than trying to fix 15 while the other 35 get more and more code.
4. Dark/light theming
Just like with #2 having a crude scheme at start is way, way better than trying to make your existing design have a dark theme.
When you do it from scratch, you can define a set of CSS variables from which point everyone uses it.
The reality is that most engineers when they add a new feature they look for a component that looks clean, they copy it and modify it until it's the New Component. People copying components with great practices, like holding color values in CSS variables, would most likely to follow those great practices, just out of laziness.
5. Testing (a classic)
If you start a project with tests, even if you barely add coverage you will be way better off than trying to test code that was never written with testing in mind.
Here again I worked with projects, where all data must have been mocked on the frontend, but now I work with projects where I can test my database queries locally in a local DB, I can write tests to make sure that worked previously is still working.
Your turn
Have you seen other cases of innocent looking tech-debts that grew into time swallowing monsters?
Top comments (0)