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.
In the previous post, I started a first F# implementation, showing "beauty" of F# code ;). Now it is time to improve a bit the controller function to be more fluent.
As a followup of the previous post, I would like to adjust the last example (using some comments' suggestions) and introduce a first basic F# implementation, which will allow to illustrate Railway Oriented Programming.
I already mentioned the video from Mark Seeman about Functional Architecture. I proposed sessions on this subject at SocratesCH to discuss and to understand it better. My understanding is still far from perfect, and in this blog post, I would like to give some feedbacks on experiments I have done with an OOP language, sketching hexagonal architecture implementations, before switching to functional implementation.
In september 2015, I tried a refactoring kata to practice my F# skills. In this attemp, I focused on immutability and pure functions, keeping in mind what I know about refactoring in other language.
Then, in november 2016, I assisted to the refactoring workshop from Michael Feather at BuildStuff. And talk a bit with him about the idea of identifying functional code smells and refactoring patterns.
So I like to start to write a bit on this subject, from my humble newbie perspective :).
In the first part post (5 years ago...yes!), I talked about some refreshing visions on IT industry. It was quite rhetorical, now it’s time to illustrate with real examples from my experiences. 5 years later, sadly, I just have more examples...
The mainstream organisation is still quite far from Features Team, collocated teams and all other concepts that were proposed early by Agile advocates (and even Lean before Agile...). Even if Agile is more and more popular, it is often interpreted just as a method, missing crucial aspects.
So let's try to dive in details of these organisations, but I will not mention specific to avoid defamation.
As I said about F# in this post, I used a sort of "maturity model" to learn new languages/platforms. That's at least my way of learning based on some experiences, I don't know if it would be applicable to anyone. So I would like to expose facts that lead me to this "model".
I had two blogs in the past, the first one in English on Blogspot and then when I created DevCrafting company, I created a new site only in French with Office 365 (SharePoint).
I never managed to keep writing new posts, for several reasons, mostly bad ones probably, but I would like to give another try with another approach. I want to talk about that as a feedback.
Also, I would like to be able to write sometimes in English, sometimes in French depending on the subject.
And last, I like the idea of FsBlog and since it did not support all I wanted to do, I decided to play with F# on my own and to create my website and blog with F# as Tomas Petricek did.
I would like to write a post on this subject for a while (amongst lots of other…), and a post of Mike Cohn about Agile in the Age of Hyperspecialization reminds me the subject (in addition it is also a recurring subject at work for me). I wrote some comments on his blog, but I would like to detail a little bit here.
First of all, I am not confortable with the analogy done between manufacturing activities (or buildings and civil works) and IT industry, which basically leads to reduce developers to “simple” workers that could work in a production line (cf. Ford, with respect for manufacturing workers)…and I think that’s a point that is totally missed with hyper-specialisation.
I prefer other visions more suitable to our industry. In this first post, I will talk about “cultivate your code” analogy, “mentofacturing”, and feature teams approach.
Then in a second post, I will dive into an illustration of what could be stereotypical organization nowadays with “hyperspecialization” and my vision (shared and applied in my team), which is best aligned with Agile and Lean principles from my point of view.
I'd like to give my point of view about the subject of communication mediums in general, It is just a first try on this subject. I will dig communication mediums in enterprise through communication tooling. The goal of this post is to analyse which communication medium should be used for which purpose.
This post is quite general and focused on concepts (even if I am not an expert in the field), I will publish an example of what I mean with an example around tools that can implement what I explain in this post.
Note : I do not talk about how people can change communication according to their behaviour, which is more psychology, I just talk about means, even it is sure that the way you communicate is also an important subject.
I think communication as the main factor of success in any project in general, because a project is rarely a personal one but the one of a community in general (which could be a couple, a team, a service, a department, an enterprise, and so on...). Good communication leads to more efficiency and comprehension.