My learnings at FOD BOSA’s eProcurement platform after three years
For the past three years, I’ve been working on the Belgian federal e-Procurement platform at FOD BOSA. It’s a large application used to support public procurement, as you might have guessed. It contains dossiers, publications, agreements, purchase requests, purchase orders, approval flows, lots, suppliers, and quite a few other concepts I had barely heard of before joining this project.
From a front-end perspective, it’s also the kind of project that teaches you things smaller applications rarely do. We’ll go into depth about those learnings in this article.
The hard part usually isn’t the code
The first and foremost learning has been something I didn’t experience on this level in my previous jobs: actually understanding the business and the client, and making sure what we implement is really what they want (and that what they want actually makes sense).
Understanding these business rules (and validating them) has been a learning experience for me, on my previous jobs where I wasn’t a consultant the CTO / team lead usually just handed me the exact requirements and knew exactly how it should work (more or less). But now all of a sudden there’s a client that has a much deeper understanding of the business than you do, and you have to get on top of that information while also ruling out mistakes or inconsistencies in their feature requests.
This also means that you can’t just take a ticket and start implementing exactly what is written down. Sometimes something sounds perfectly logical until you start comparing it with how the rest of the application works. Other times you start implementing something and discover that a seemingly small change has implications in three other places.
A lot of the work therefore happens before actually writing the code. Asking questions, going through existing flows, talking with analysts and the client, and sometimes pushing back on requirements because you know they will cause problems somewhere else.
This is probably one of the biggest changes in how I see my role as a developer. Writing the code is only one part of the job. Understanding what code should be written in the first place is arguably the more important part.
You don’t need to understand everything, but you need to know where to look
When I started working on e-Procurement I obviously didn’t understand the entire application. Three years later I still wouldn’t claim that I do.
The platform is simply too large for one person to know every flow, business rule and technical detail. Different parts of the application have been built by different people over multiple years and some parts of the procurement process can get quite complicated.
At first this can be somewhat overwhelming because you feel like you should understand everything before changing something. Over time I’ve learned that this isn’t really necessary.
What’s more important is knowing how to find the information you need. Which developer has worked on this part before? Which analyst understands this business flow? Is there another part of the application doing something similar? What does the backend actually return here? Why was this code originally written this way?
Git history has become particularly useful for this. Something that looks completely unnecessary today might make a lot more sense when you find the ticket or commit from two years ago that introduced it.
Being able to navigate a large codebase and gather the context you need is a skill on its own.
Working with legacy code changes your opinion about legacy code
After three years on the same application, I’ve also become a lot less judgmental about old code. It’s easy to open a file, see something weird and immediately think: why the hell did somebody write it like this? Then you check the Git history and discover there was actually a perfectly reasonable explanation.
Maybe the requirements were different at the time. Maybe the framework didn’t support a better solution yet. Maybe there was an edge case you’re not aware of. Maybe it had to be shipped quickly. Or, even better, you check the author and discover that you wrote it yourself two years ago.
It has made me much more careful when refactoring existing code. Just because I can write something cleaner today doesn’t automatically mean replacing the existing implementation is a good idea. Especially in an application with a lot of business rules, weird-looking code can sometimes be weird for a reason. Of course there’s also just bad code. I’m definitely not saying every piece of legacy code is secretly brilliant. But I now try to understand why something exists before deciding that it shouldn’t.
Refactoring becomes more about confidence than making code pretty
I’ve always liked refactoring. There’s something satisfying about taking a messy piece of code and making it smaller and easier to understand. On a large application I’ve learned that the actual refactoring is usually the easy part. Being confident that you didn’t break anything is the hard part.
You can turn 500 lines into 200 lines and feel very good about yourself, but if those missing 300 lines contained some obscure behaviour that only happens for one specific type of procurement procedure then you haven’t really improved anything.
Tests obviously help a lot here, but even with tests you need to understand what you’re changing. Because of this I’ve started preferring smaller refactors that can be reviewed and verified easily over huge rewrites.
There are definitely moments where rewriting something completely is the right solution, but “this code is ugly” by itself isn’t enough of a reason anymore.
At some point, you become the person who knows why
One funny thing about working on the same project for three years is that eventually people start asking you why something works the way it does, and sometimes you actually know. You remember the bug that caused some weird condition to be added two years ago, or why two seemingly identical components behave slightly differently.
I don’t think you really notice when this transition happens. At some point you just go from being the developer asking everyone else how the application works to being one of the developers people ask.
It also makes you realise how much knowledge about a large application isn’t actually in the code or documentation, but in the people that have been working on it for years.
Three years later
Looking back at the past three years, I think the biggest thing that has changed is my idea of what makes a good developer. Writing good code obviously still matters, as does knowing your framework, TypeScript, testing, architecture and all the other technical stuff. But those things only get you so far on a project of this size.
Being able to jump into a part of the application you don’t fully understand, figure out how it works, understand what the client actually needs and make a change without breaking everything around it has become much more important to me.
Three years later there are still plenty of parts of e-Procurement I know very little about, and I still regularly open some code and wonder what the hell is going on.
The difference is that I’ve gotten a lot better at figuring out why.