In the previous post, I talked about organizational changes I observed on my third contract in 12 years on a monolith that grew up quickly with a team of 3 up to 20+ people today. In this post, I focus on design and technical changes we started one year ago.
In the previous parts of this series, I focused on my two first (quite long) takes on a project we started at the end of 2005. I left the project in early 2007, I came back in 2009, and left again in 2012. and this post is about a new come back (for a bit more than a year now) on this 12 years old project. I will try to expose lessons learned from this experience, from organizational and technical points of view.
In the previous part of this series, I focused on organisational issues we had and solutions we found when I cameback in 2009 on the monolith project we started at the end of 2005. In this post, I focus on technical issues and solutions.
In the first part of this series, I focused on the genesis of the monolith we started at the end of 2005. I left the project in early 2007. It was planned to grow quickly, then the team would have to adapt (in size and more...). I came back on the project in 2009, this post highlights new challenges we faced from organisational point of view, evolution we made (lots of experiments) and consequences until 2012 when I left again.
I would like to share an experience I started at the end of 2005 and I followed in time up to now (in 2017). In 2005, the team I was working in (3 persons) started a from-scratch rebuild of a legacy Notes application. Today, it is a huge monolith application with lots of legacy code, having several issues these kind of application have. My goal is to retrospect its history, to hightlight impacts of some choices and then try to find solutions.