When creating a new system most of the infrastructure and technologies are well known to the team. At least that’s been going on for me for the last systems we’ve built.
Most of the parts are well known, but what about those dark shadowy places?
We started a new system a few months ago (I wrote about it here). The first part of every good system design is, well, designing. Part of the design relied on something I told my team that can be possible to do. They never did it but they trusted me that will work. We drew the diagrams and the architecture, showed it to our manager and received the OK from all the people we needed. All this was done before we wrote a single line of code.
A couple of weeks after we started I realized I’ve never shown my team how we can accomplish that little part they trusted me to know how to do. Moreover, I started to feel unsure if I can really do it!
POC POC POC POC
That’s the moment I said to myself I need to stop whatever I’m doing and focus on making a working demo to show to my team.
POC – Proof Of Concept. Before you make the real, well structured and tested end-product, you should make a small POC of it. It’s a good excuse to do something quick and dirty. After you have your POC in place, working and demonstrable, you need to refactor it enough to a “real” product.
I stopped working on whatever I was working on and began building a POC. While building the demo I wrote comments on what parts will be needed to be refactored into different packages. After a week or so, I had a working demo! (And it really worked!)
I was glad for two things; first, the demo worked like a charm, it was really pretty to look at (and still is). Second, the team gave their trust into something I said can be done and it really was like that.
But what would’ve happened if I didn’t make that POC? This time nothing would have happened as it did work. But what if it didn’t work? As I said, this module was required only later in the system. We could have worked months on something that wasn’t going to work and only at a later phase we would realize it wasn’t going to work and need to change the whole architecture.
We did two things right when designing this system. The first one is that we design every aspect of it right from the beginning. We didn’t go deep into each module and microservice, nor into the UI itself, but we design what each microservice will do, how they will communicate with each other and how they will share resources. We designed the system from the very first module up to the last module, knowingly the last module won’t be relevant in the next few months.
The second thing we did right was to POC the unknown territories. Knowing all the modules that were required, and knowing our strengths and weaknesses, we knew what would be simple to implement and what would be hard. The simple things were left untouched and without any worries. The hard things, the new things, those received more attention. Those parts were marked and those are the parts we realized we need to POC.
No Comments