2018 retrospective #

Well, first and last article for this year. And it's been quite of an exiting and exhausting one.

I've written a few in French, mostly technical ones on serverless, AWS Lambda and Microsoft WCF. The two firsts are part of what I've been doing professionally this year, architecturing and building a serverless Node.js REST API.

So many things happened this year. I'm now owning a house 🏠 in which I started to build my own home network and started to add some home automation. I'll probably blog about this later.

Working #

This has been a rough year. The first version of the project I architectured in September 2017 went to market in February. Almost a year and a half after I typed the first bits of code, it started to get customer traction. To manage this we had to go through a lot. Success came at last, but error were made along the way.

Feature first #

For the product to explore a brand new market, we had to build it in a very specific context where everything were meant to change. The data and the business logic, but also the requirements changed a few time during the process and there still doing so today. Adapting in a such changing environment is challenging. We've chosen to apply some agile process to the dev team. If this choice is yet obvious for the technical staff, it's not the case for the management which were used to work in a kind of V-Model kind way, so a lot of pedagogical work were required.

A hell lot of features were expressed, which is good. Lot of them had to be refined many time to get to a full comprehension from the whole team, and only then solutions, functional and technical, were defined. This was and still is a time consuming process, not easy to justify (yet again, managers were eagerly expecting results), yet it resulted in a lot of mater to start programming with.

With a list of feature this long, the product owner, in order to get to market fast, fitted the maximal value into each sprint, setting aside a lot of technical tasks. Developments seemed to go fast, a lot of value were gained as well, thus the product acquired a large technical debt. The first version were deployed as such and the development of the second one started, laking the expected debt reduction.

This release were expected 3 months after the first one. It actually came 7 months later. After the features were made, the QA (Quality Assurance) assignment failed, many time, in a row, during a total of 4 months. It was the most fastidious time of the year for the whole team. Yet, it also was the occasion to reduce the technical debt, which in most cases was the reason the problems.

During this phase, we defined process to identify the existing technical debt. Sorted it according to many criteria and linked them as requirements to future features so we could not had a feature without having the debt paid first. We also allocated a part of the resources (around 10%) on identifying and fixing the debt during each sprint.

TL;DR #

• Many feature makes business officers and managers happy
• Fast made features often needs to be refined/refactored
• Include it into your sprint otherwise you'll probably face it later
  • and it will hit harder
• Audit your technical debt and choose which item to pay back

Going fast #

Working on such a startup project implies that you'll have to work fast, change direction and maybe work on something that'll be abandoned. One day you'll get really exited by something, and the other you'd be crushed by a bad new on the very same subject. Some people call this the "startup emotional roller coaster".

This kind of rhythm makes the "decision making" a critical role, and relies on the one(s) making them. Fast choices is also leading to errors, so to apply this kind of methods, everybody has to understand the human nature beneath it.

Once this is accepted, I had to find balance between all the subject I had to deal with. And it was not such an easy task.

It's okay to be hard working when wanted or required, as long as it's recognized and rewarded. On this, I defined to myself the following rule, if it feels like suffering, even for a day, then it's not healthy anymore and a solution needs to be found. When it happened (because it did 😉), it was easier to detect, react and manage the case.

Likewise, you're always challenging yourself, and I feel quite good about it. New problems, requirements or features make me learn new solution and in that way it always makes me grow. Yet it can guide to sacrificing some other thing or even yourself. This one is tricky to me, I'm naturally letting a few things aside, driven by passion I guess and let other topics (eg. sports) on the side. I have no efficient solution on this yet 😞.

Frequently, it's required to get out of the comfort zone and that's normal. It's the place I learn the most. It's easy here, if no boundaries are defined, to push yourself to hard. To define my limits, I get back to my personal objectives and ask myself :

• Why am I doing this instead of something else ?
• What do I learn ?
• What Will I re-use it for ?

If the answer to any of those questions is negative then the task and effort is not worthy. It doesn't mean it won't be done in the end, it means my impplication won't be at its finest.

TL;DR #

• Working hard: 👍
• Suffering: 👎
• Challenging yourself: 👍
• Sacrificing: 👎
• Getting out of your comfort zone: 👍
• Pushing yourself beyond your limits: 👎

Solution design #

It's my favorite part of my job, solving problems. Building a solution to a complex problem. Last year the criteria were, a scalable architecture with a low cost so defined and implemented a serverless infrastructure based on AWS Lambda.

This year was mostly about standardizing this architecture and making multiple components dialog with each other in an standard way. TypeScript was introduced for a stronger typing on the interface between components, and message brokers and message queues came and replaced the HTTP calls, which also was a required action for the scaling of it all.

A second team started using the same architecture on an other project, so a lot training and accompaniment was put in place. The enhancements on the design of this system now becomes tricky, as their impacts are growing.

Design patterns are a large source of inspiration in my work. For long, I knew and used the "Standard" patterns originated from the GoF (Gang of Four), yet an overlay is required for it to work in a cloud environment. So I'm now using and discovering (day by day) the cloud design patterns. As the "standard" ones, the role of each pattern is simple and reliable. Rest of the work is implementing them and making them work with each others.

I'm also doing a lot more of functional programming (fp). Coming from an almost full OOP set of experiences, it at first kept my head spinning for I did not understand the full beauty of it. Now that I have, that's a pleasure to add some bit of it to the existing stack. 💡 Also, I learned that the word "patterns" seems to annoy a lot of persons doing fp, replace it by "practices" or "approaches" and you should be fine.

TL;DR #

• Inspire on patterns
• Mix programming paradigms
• Nice and simple design will be reused by other
• Keep learning

Living #

Music #

I listen a lot of music while working, commuting and at home. Here is a non exhausting nor ordered list of what I liked this year.

The bands I discovered this year (& liked 😉):

• PowerWolf
• Jinjer
• Unleash the archers
• Battle beast
• Amaranth
• Gojira
• Alestorm
• Leo Moracchioli (one man cover band)
• Antonin Leopold Dvorak

Those I rediscovered:

• Queen
• Ultra vomit
• Within Temptation
• Foo fighters
• Iron maiden
• Ludwig Van Beethoven
• Frédéric Chopin

Sports #

Something bad/weird happened this year. I managed to get myself signed up for a year at a gym. Never went before, so it was kind of new and fun at first. Since I'm not trying to be muscular or fitted, I played with the various machines available for a while and got bored pretty quickly. Lifting things does not appeal to me at all, so does the "running in front of a window" thing. Here's something I won't do in 2019 😄.

A nice discovery I made is block climbing. I've been climbing a lot of things as a child (mostly trees), and it was a real pleasure to rediscover it as an adult. The discipline is slightly more secure and organized as just climbing on stuffs but the results are here, it's fun 🎉. For those wondering, it looks like this : 📹 https://youtu.be/dQhHRAJmGqY?t=6m.

As for archery, I'm still practicing. I paused the "podium project" for a while so it's not as intense as it once was.

House #

So, I'm now the owner of house. In itself that's a life milestone.

I started this year, and will continue, to transform (refactor 🤓) it as I wish. The firsts elements in the nerd todo list are the home network and the home automation. More will come.

Wrapping up #

2018 has been tough but great year. Many challenges came to my path, mostly not easy ones, making me learn new things to solve them and triumph ✌️.