Big projects can be killing
So how to survive?
A few months ago I got an offer request for a project which seemed big, but not undoable.
So we spoke about the financial part and I decided to take it. Can’t be that hard, right?
It’s just code 😉
But man, I’ve never been so wrong in my life before!
This was like what I had planned to do after, let’s say, maybe 2 years and I definitely didn’t expect this project being that big.
It’s hard to explain what I’ve been through, but it was with ups and downs and the downs were deep and sometimes the way up was incredible hard to find.
This WordPress project was a WooCommerce webshop with multiple languages where I used WPML for.
So, there it was. Me, with some decent WordPress experience and never touched WooCommerce or WPML before.
This went paired with a wrong start, wrong turns and terrible mistakes with my planning in front.
But after 3 months ( Woops! ) the project finally was done and I can look back to it as the best step I’ve taken so far.
Was it a “happy” project? No. This was the real deal and even an emotional rollercoaster.
Was it educational? Oh yes, it was! I learnt amazing stuff and also got confronted with making 2 WordPress custom Rest API’s for a dynamic header and the webshop filter.
But where it went wrong? Right, the planning.
Maybe it sounds familiar to you, but I just started coding the basics. I started and got coding along the design and made a lot of flexible blocks and other parts working.
But there the questions started to grow and I literally got stuck. There seemed no way out.
How should this been solved?
Well, let’s be honest. I can be kinda chaotic and that is the bad part in here. Just starting with the idea it isn’t that hard is a bad decision.
Planning on forehand is, to my experience, the best part of development.
There were some steps to take which I kinda skipped by just starting.
I can strongly advice to create some sort of technical flowcharts where you can link pages together so the questions about different blocks are getting formed.
Then it’s important to get into a conversation with the agency who gave the project and ask if you did understand everything correctly.
If I would have done it that way, I probably would’ve saved 30% in time.
Then it would have been clear that their card layout should have been build from a category selection instead of with manual input 😉
So if that technical flowchart is done and all dynamic parts are explained and clear, you can kinda make a new sort of technical document where a layout of the website is remade.
In this remake, you focus on which blocks are repeatable and which pages are template pages.
Also, you can decide the flexible structure of a website better if you make a technical remake.
You also decide, within this remake, which parts of the website is gonna rely on functions to make it even more readable for other developers too.
When starting to code along this technical specifications, you’ll notice all steps for the full website are clear.
The documentation just functions as a guideline through your coding and since all steps are clear, you can work yourself through step by step.
Ofcourse, a next project, I will do it like that myself too. This way, a lot of mistakes can be avoided.
So let’s say we can conclude that planning on forehand should be always done.
Just thinking out the structure of the website, the re-usable parts, the static pages and the flexible parts.
You will be surprised how much time you can win with that!