Internal Project
Methodology

Release of Komander.io

A few days ago, I made available on DockerHub a development tool that I built and have been using for several months.

This tool, named Komander (https://komander.io), is the result of the same approach I use with my clients, applied to my own activity. Here's what it consists of.

It All Starts with the Need

The need arose (as often happens) from various frustrations: throughout the year, I create numerous repositories for each project I work on, and I maintain some of them for over 10 years! However, I realized that I was performing certain time-consuming and low-value-added tasks in a repetitive manner, such as initializing repositories with the right base files (.gitignore, Dockerfile, README.md, etc.), configuring certain naming conventions, or adding deployment scripts, etc. On the other hand, I had difficulties keeping development environments operational on the oldest projects and realized that over time, one tends to forget the architectural details that make each project unique.

So, I summarized my need in 3 points:

The Design Phase

First of all, I always approach the problem backwards! I start with the solution: what does the ideal solution look like in terms of user experience? I always start with the functional, real, practical need, and the operational aspect. Then, little by little, I abstract the needs to identify the technical requirements and design an overall architecture.

The Development Phase

In fact, it would be more accurate to talk about "development phases" in the plural, because the approach is iterative. I design, develop, use, note the corrections to be made, and start over until I have a satisfactory solution. But what is a satisfactory solution? This question is even more difficult to answer when working on a "clientless" project, where one tends to work without a budget and without real constraints. For me, the important thing is to progress step by step and give yourself time to really use a software solution in order to evolve it as closely as possible to real business needs. So yes, everything is not perfect at the beginning, but often we realize that some aspects are not as essential as we thought or that other more important aspects are missing. This saves time and resources.

What's Next

This project is still very young and I already see many possible improvements, but I would like to be able to exchange ideas with other developers to confront certain ideas and see how we could evolve it to meet the needs of a larger number of people. That's why I opened a discussion on Discord, where anyone can come and ask questions / give ideas, etc. about Komander, here: https://discord.gg/3Whq6UrKpq

See you soon!