DEV Community: Mikael

Clawdbot/Moltbot security issues.

Mikael — Thu, 29 Jan 2026 00:13:45 +0000

Hey Everyone, you might have heard of Moltbot, a project that has fantastic promises. Delivering agents locally to your machine and connecting it to a wealth of tools and chats for interractions. Today I decided to dig into their code, and surprise... project initiated in Nov 2025, already has 8000+ commits on main 🧐 700+ issues and close to 300 PRs. For a project that young it's an insane amount of code being shipped. This raised red alerts straight away. I started to read some of the code and let's say... best practices were not really implemented. One commit incremented a wait time for Telegram messages from 1500ms to 5000ms.. I mean, just a magic value lost in a script. Typical AI slop.

Anyways, I was sure this project could present significant sec risks if used, so I ran a Gemini Pro report using deep search and sure enough, interesting things surfaced.

You can read it here for those interested enough. It's worth the read. One safer moltbot fork is proposed and I think it's completely necessary (https://github.com/titanicprime/moltbot-safe)

Enjoy the ride, and stay safe!

Easy Ledger CLI: a management tool for ledger-cli ledgers

Mikael — Sat, 13 Dec 2025 21:39:29 +0000

Hey all!

I recently started using ledger-cli, a Fat-free Accounting tool.
In their own words:

What it does offer is a double-entry accounting journal with all the flexibility and muscle of its modern day cousins, without any of the fat.

Check their github for more details. It's really a great concept and lovely to use for reporting and tracking your accounting.

The only caveat for me is the commands you type to append transactions to your ledger can get quite long and tedious. One of the main "issues" from the command line interface is that you have to write your ledger file path every time you enter a transaction (yes, the DB is a simple text file 😊). The author of ledger did add a ledger-mode allowing you to use shortcuts and syntax highlighting in order to ease the management of the ledger file, but I do not want to work from a file and would much rather add my transactions via cli in an easy, clean and straight forward way. I also do not want to know about my actual ledger file, why should I manage it myself?

In order to fix this, I wrote a very basic cli (for now) that allows you to:

manage multiple ledgers (think one for your company, one for yourself)
seamlessly switch between those
add stocks and transactions in an interactive way

In the near future I plan to support all supported transaction types and details as well as adding a few basic reports and maybe the ability to pre-configure your own ledger commands.

Give it a try, let me know what you think, contribute!
Link to the npm package

Day 1: Scary attempt at building in the open

Mikael — Mon, 15 Jul 2024 18:31:14 +0000

Hey 👋

Nice to have you here.

🤔 What is this post anyway?

This post serves as a starting point for my "building in the open" attempt. I have seen a few people doing so on LinkedIn and was inspired to start my own journey.

As a small dev team, we are constantly juggling between internal and client work. Our internal work revolves mostly on developing tools and software that we might use internally or just complete as hobby projects. The vision, the dream, is of course to make it big with our products in order to break free from our client's chains. Building in the open might just be the way to go.

🧑‍💻 What will you be building?

I am not yet 100% convinced of what shape this project should or will take, however, I can reveal the main idea behind it:

Enable all LLM applications to use any service on the internet.

This comes from the simple observation that LLMs and their applications are missing on the most important feature a user would want after passing the honeymoon phase: Do something useful.

👈 What's next?

I am not yet 100% convinced of what will come next, but I can assure you that I will continue posting on our journey to build this thing. You following me and sharing feedback in the comment section will help me and I will find it extremely encouraging!

For now have a great day and see you soon for Day 2!

Meaningful Software Companies?

Mikael — Wed, 04 Jan 2023 16:17:00 +0000

I am slightly tired of working on meaningless software products that do not provide any real value to society and the world in general. Do you have any recommendation of great startups/scaleups in the ecosystem?

Thanks! 🤍

🤖 Automate your version management 🤖

Mikael — Sat, 25 Jun 2022 18:57:48 +0000

Introduction

Version management, or the art of passing from 1.0.0 to 1.0.1, is a process, in our technical world, that is very important but sometimes vastly underestimated and somewhat disregarded by some of us (me included 😅).

The benefits of good version management, to list a few, could be:

Information - When the versioning is well done, it can provide very useful information to users and softwares (technical and non technical).
Security - For us, technical people, we use versioning to make sure we run the latest, security threat free, packages.
Compatibility - For a package manager such as NPM, it helps creating the perfect package mix and alert of breaking changes and security threats.
More information - For end users, it helps understanding if they are up to date, or not!
Activity - A great measure to understand if a project is still ongoing is the frequency at which it releases new versions to adapt to security threat and updates from other packages.
more ... I don't know, let me know in the comments 😁

Essentially, a version is often written as 0.0.1. This versioning style is essentially composed of three components: the lead 0, the middle 0 and the 1. In most cases, they indicate the following:

Lead 0 indicates the major version.
Middle 0 indicates the minor version.
The 1 indicates the patch version.

MAJOR, MINOR, PATCH versions. As simple as that.

If you want to respect those rules, which are commonly accepted, the idea is that you update your version according to the following principles:

Major version changes are made when a breaking change is introduced or when the product changes profoundly
Minor version changes are made when your team introduces a new feature
Patch version changes are made when changes occur in the code base that do not introduce new features. Could be a security patch, some bug fixes, more stuff.

How we automate it

In my world, in which most projects front and back are managed with a package.json, version management is usually forgotten and updated from time to time in a not so much established process. Usually the impact is slim to none we run most of our development internally and with a very closed IT environment. However, we recently decided to kick our devOps a notch and one of our projects was to automate version management. We wanted it automated to 1. never think about it and 2. show the state of each platform we develop. Hopefully a 1.0.22 shows more work than a 0.0.2.

In our efforts to automate the process of going from 0.0.1 to 0.0.2, we built a small (1 script), lightweight (17kb) and git ready package for reusability across all our projects.

Enters bumpme, a cli that helps you automate your package.json version management.

Bumpme is a simple CLI that helps you automate your version management. You can run it like so bumpme or with arguments like -s or -i. -s represents severity (patch, minor, major) and -i represents increment (by how much it should be changed).

A cool feature of bumpme is the automated integration with git. The idea from the get go was to integrate it with git in order to read the commit message and bump the version accordingly. bumpme reads the git commit message and tries to find a specific command which can be something like [[patch:1]]. Such a command, as you guess, will pass the package.json from 0.0.1 to 0.0.2. Pretty cool!

Automate it

It would be silly of us to keep the responsibility of versioning and running a specific bumpme command for each commit to our main branch to a human! We decided to use Github workflows for that. If you do not know what a Github workflow is, I encourage you to learn about it. It is a very useful automation tool. For each commit merged into our main branch, for which one person is responsible to press the button, a github worklow will trigger. In this github workflow we simply insruct the machine to un npx bumpme or npm run bumpme (how you want to do it is really your problem). The bumpme command simply reads the latest git commit message (which comes with the merging of branch) and bumps the version accordingly. Again, pretty cool!

If you want to test or use it, here is the NPM link: @food7go/bumpme.

This is an open source project, meaning that we welcome review, new ideas and obviously contribution.

Thanks for reading!

How it feels to look for new gigs right now

Mikael — Mon, 13 Jul 2020 21:19:48 +0000

https://youtu.be/x1TsOHyJPpw

🔥 Firebase Auth Migration 🔥

Mikael — Tue, 23 Jun 2020 09:58:34 +0000

Introduction

This article is a short tutorial aimed at giving you a path to migrate users between two Firebase projects (or really any authentication service).

As I passed a good amount of my morning trying to figure out how to do this, I thought spreading the word on the internet could potentially help more people locating it.

The documentation on this matter is hoster by Google here. So if you like to work with docs and do not want to read my little tuto, feel free :)

Tutorial

Step 1: Firebase CLI

In order to perform the import, you will need to use the Firebase command line interface. You can install it without issues on your machine by entering this command into your terminal (npm users)

npm install -g firebase-tools

Continue with the login process and init your firebase repo. Once all is done, you are ready to import/export your auth users.

Step 2: Import users

To import users, go into the Firebase repo you just have inited, and enter the following command

firebase auth:export accounts.json --format=JSON

This will download your current users into your local machine. Make sure the file location is secured, not committed to any git repo and offline. You don't want to leak your users' passwords.

Step 3: Export users to new project

First, switch projects using

firebase use new-project-name

Then go to your Firebase dashboard and go to Authentication > three dots on the top of user card > Hash parameters. You will need this information.

Now to import the users enter (replace the with your config from Firebase)

firebase auth:import accounts.json \
> --hash-algo=<hash_algo> \
> --hash-key=<hash_key> \
> --salt-separator=<sale_sep> \
> --rounds=<rounds> \
> --mem-cost=<mem_cost>

Once successfully migrated, you should receive something like

Processing accounts.json (XXXX bytes)
Starting importing 15678 account(s).
✔  Imported successfully.

All done, you have successfully migrated your users.

Now before you migrate please make sure you have disabled access to your old project for all users in order not to have different data from one project to the other. Also make sure that the apps are correctly updated to use your new project's config. If you respected that, the experience for your users should be seamless.

Have a great day of code!
Mike

About me

I am a partner at MMPG Consulting, a firm active in the custom software development industry in the Spanish and Swiss markets.

For more content, you can add me on LinkedIn or shoot me a DM if you want to discuss specific topics, your software or an idea you want to implement.

Ultimate Terminal Customization

Mikael — Mon, 22 Jun 2020 22:55:11 +0000

Introduction

If you are a Linux user, you will use your terminal a lot. Terminal, once you know how to navigate your machine with it and work on a daily basis, will tremendously increase your productivity. For example, you can easily move files around or use CLIs from your favorite providers or apps to perform complicated tasks that would take way more time if done through a visual interface. In summary, it allows you to have a greater understanding of how your machine works and lets you be more productive, at the cost of you staring at a black screen with cryptic messages.

Just type cmatrix in it for fun.

Anyway.. Since we are going to spend a lot of time in it doing various complex things and probably get frustrated over time, why not make it pretty and fun. For your own sanity of course.

In this very short tutorial I will show you how to easily customize your terminal. I am myself using Linux Ubuntu 19.10. Users from Mac and Linux distros should have a pretty similar experience. Microsoft users, I can do nothing for you.

Most Ubuntu users start with the terminal looking almost like this:

A completely fine looking terminal if you ask me. But not fancy enough for our special breed of dev. We want something personal so when our colleagues or friends look at our terminal, they understand that we know what we are doing.

Let's change things a bit!

First Steps

The configuration of our terminal is defined by the variable PS1. To change what your terminal displays, you just need to type in it

export PS1='I am so fancy 😄 $ '

Magic! you now have a custom terminal. But oh misery, when you close and boot it up again, your terminal will be going back to boring old normal. Don't worry, I got you, there is a way of making things more durable.

The secret lies in the .bashrc file.

Go ahead and type the following command into your terminal

cd
vim .bashrc

This will open a file looking like this

We know from before that the variable PS1 holds our prompt display. Go to the following line and uncomment

force_color_prompt=yes

then go to the line below

PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

Huray! this is your traditional Ubuntu terminal prompt.

Ok, great, we have it.. now what?

Now comes the fun, it is time to customize things a bit. But first, let's understand this mess.

Here is a short description of the different parts

${debian_chroot:+($debian_chroot)}: this part is explained here in a very good way, I encourage you to read it
\[\033[01;32m\]...\[\033[00m\]: Are the opening and closing tags of bash text styling
\u, \h and \w: respectively user, machine name and current path

In order not to get too much content in, we will first just create a simple prompt that will look like this

😍😍 DEV MADE ME DO THIS 😍😍 $

(with more colors)

Let's customize

In your .bashrc go to

PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

We will start by removing the unwanted boring content. We will remove the username and machine name but will let the path in. Always nice to know where you are. Your code should look like:

PS1='${debian_chroot:+($debian_chroot)}:\[\033[01;34m\]\w\[\033[00m\]\$ '

to apply the changes, save your current modification and type in your terminal:

source .bashrc

We have to continue the work, enter again in your .bashrc and change the code to the following:

PS1='${debian_chroot:+($debian_chroot)}😍😍 DEV MADE ME DO IT 😍😍 \[\033[01;34m\]\w\[\033[00m\]\$ '

This is not so bad... right? But we miss something... I know! Colors!

We need to try and make a rainbow. Basically how the styling work is as follows. As seen before, we have \[\033[01;32m\] as opening tag and \[\033[00m\] as closing tag.

Adding Colors in your Life

openning

\[\033[01;32m\] is the bash way of saying increased intensity with color green. In this string of characters, the 01 means increase intensity and the 32 means green. Try 02 instead of 01 and your text will be a bit transparent. Try 33 instead of 32 and your text will become brownish. DON'T FORGET TO SOURCE .BASHRC.

closing

\[\033[00m\] really just means no more styling. Yep, that's it.

So! let's finish our beautiful rainbow of colors. We will use the following colors:

red: 91
yellow: 93
green: 92
light blue: 96
blue: 94
purple: 95

which will give us:

PS1='${debian_chroot:+($debian_chroot)}😍😍 \[\033[01;91m\]D\[\033[00m\]\[\033[01;93m\]E\[\033[00m\]\[\033[01;92m\]V\[\033[00m\] \[\033[01;96m\]M\[\033[00m\]\[\033[01;94m\]A\[\033[00m\]\[\033[01;95m\]D\[\033[00m\]\[\033[01;94m\]E\[\033[00m\] \[\033[01;96m\]M\[\033[00m\]\[\033[01;92m\]E\[\033[00m\] \[\033[01;93m\]D\[\033[00m\]\[\033[01;91m\]O\[\033[00m\] \[\033[01;93m\]I\[\033[00m\]\[\033[01;92m\]T\[\033[00m\] 😍😍 \[\033[01;34m\]\w\[\033[00m\]\$ '

Alright... This was of course just to showcase what you could do. I personally went for something more basic:

Congrats! You are now a master of personalizing your command prompt. In order to learn more about how to visually customize your prompt, use the link right below to find more resources. You will be able to create crazy blinking animated terminal sessions with it, trust me it's fun:

https://en.wikipedia.org/wiki/ANSI_escape_code

It would be nice to see what you guys built, so let us know in the comments!

Til next time.
Mike

About me

I am a partner at MMPG Consulting, a firm active in the custom software development industry in the Spanish and Swiss markets.

For more content, you can add me on LinkedIn or shoot me a DM if you want to discuss specific topics, your software or an idea you want to implement.

🔥 Firebase Firestore Migrations 🔥

Mikael — Mon, 22 Jun 2020 18:06:32 +0000

Firebase is one of the greatest serverless environment for developers to quickly get scalable products up and running, it lets you focus strictly on code and not care too much about what happens in the backend.

Although serverless is great, developers often face use cases that the developers of those tools didn't think about or implement yet.

I came across one of those problems recently and wanted to share to the greater community a nice workaround the community has built for us.

My problem arose when I wanted to migrate the noSQL data I had in one Firebase project to another Firebase project. Google lets you use the gcloud CLI for this purpose and has a very useful gcloud firestore export and gcloud firestore import that normally poses no issue. However, when you start to have nested collections, this tool will fail and only export the first level documents, which is not exactly what it should do...

After searching the internet for a bit, I came across this awesome npm package: firestore-export-import. This package will let you use the command line to do exactly what it does best: export and import data from firestore in JSON format easily. It's really a child's game.

1) install the package:

npm i -g firestore-export-import

2) Export the credentials.json from your Firebase project
Firebase Dashboard > Settings > Service Accounts > New Private Key

3) Export Data

firebase-export -a path/to/credentials.json -b path/to/savefile.json

4) Import Data

firebase-import -a path/to/credentials.json -b path/to/savefile.json

Change the project credentials in between step 3 & 4 to switch the target project.

and.. that's it!

Amazing little package that lets you perform those tasks in a way easier way than the tools Google proposes you to use. Only caveat, make sure to secure your local private keys. If anybody finds them, you will compromise your entire Firebase project.

Code safe!

5 Things to Consider when Hiring a Software Dev

Mikael — Thu, 18 Jun 2020 17:32:30 +0000

For newcomers that want to outsource the development of their first app or website, the experience can be unforgiving and sometimes harsh both financially and mentally.

I will never forget how one of my uncles, who happens to be an entrepreneur, once lost USD 60'000 hiring a software development company that was not a great fit for his needs resulting in him being disgusted by his project and entrepreneurship for a while..

This should not happen to you, and with this quick guide I will propose you a list consisting of 5 things to consider when hiring a software dev. You can apply this list to your current vendors and see if yes, or no, they are the right fit for you. Let’s start!

Business Understanding

This point is absolutely crucial and should be one of your top priorities. Your developer or developers need to have a crystal clear and deep understanding of what your business is about. If they understand your business vaguely, they will not understand how your app or software could be improved and as such, will probably lead you into traps that are either expensive to get out of, or simply put a project stopper. In summary: take your time, have at least two brainstorming session with your outsourced resources and define clearly requirements and needs. This will help them help you.
At MMPG Consulting, we always set at least two sessions in order to understand your situation, where you are coming from and what. The first one is always free and is often the one during which we find pitfalls and the best way to help our clients.

Project Structuring

You need to make sure that the project is well structured. This seems obvious, but is often a step disregarded by software devs and clients altogether. A well structured project contains:

1. Deadlines: Define when the final delivery date is. Accept the ones set by your dev, it is worthless insisting on tighter deadlines as the will be missed, or worst, will be met at the detriment of quality
2. Milestones: Define milestones to achieve along the way. It is important to break your final project and deadline into smaller milestones to reach along the way
3. Cut-off points: Be ready to pull the plug on a dev team that is not performing according to the milestones and deadline set earlier. It might be scary at first because of the resources and time invested, but it will be necessary at some point
4. Budget: Define a clear budget. The budget can be per hour with a bag of hours pre-bought or it can be established based on success. Usually part of this budget will be wired in advance at the start of the project and the rest will be paid at the end (usually the success of it)

Risk Understanding

You absolutely need to understand the risk represented by hiring an external developer to build your project. First of all, the road will not be all pretty and cloudless. There will be plenty of misunderstanding and frustration, deadlines missed and bugs, and probably some shouts or heated emails. However, let’s be honest, this is part of most of most outsourced projects and if you understand the risks before starting such a project, you can actively and preemptively manage them. As such, be clear about the potential risks, actively manage them and communicate extensively with your team. Things should go smoothly after that.

Budget Controlling

It is important for your wallet and financial health to understand exactly how much you are paying at any point. Make sure that the team you hire let’s you know at all time the hours already consumed by the team, the estimated budget needed for completion and if it will fit in your initial estimates or discussions. Do those checks often as they can save you from a nasty bill at the end of the month.

Source Code Ownership

This one should be common practice within the industry, but is really not. Many of my clients are disgruntled clients I gather from competitors and to my surprise, when they come to me, they have nothing, zero, nada in their hands. I mean, some work has already been done and paid to the outsourced team and they didn’t send any source code. As the owner of this project, make sure that in the contract you sign with your vendors, the source code ownership is included and that the source code is always sent at the end of the current sprint which should be weekly or biweekly.

With this 5 points in mind, you should be able to have a better understanding of how your software development project should be steered and how to control the details of it, without losing your cash and sanity.

Leading our customers into this complicated world of software development is what made my company MMPG Consulting successful. We value transparency, communication and client ownership. It is part of our DNA and core values to help rather than provide a service.

If you want to know more about us, visit our website or send me an email at mg@mmpg.xyz. I will be happy to help you develop your project and achieve your vision.

Software Architecture - What is architecture?

Mikael — Tue, 12 May 2020 01:42:40 +0000

I have not written for a long time on this series. Circumstances, lots of work for other projects and the unfortunate events that happened linked to Covid-19 have thrown me back. But I am back now and ready to talk more about Software Architecture, its concepts and best practices.

To put us back in perspective, last post was dedicated to introducing the topic and this series. Today's post will be dedicated to define what is architecture and define its goal.

#	Title	Description	Link
1	Introduction	Introduction to the series	link
2	*What is architecture?*	*Introduction to the concepts of design and architecture in software and why they matter*	*link*
3	Starting from the bottom	Coding paradigms and why they affect our architecture	tbw
4	Design principles	5 architecture design principles to always have in mind when designing software	tbw
5	...	...	...

Introduction

In software development we often distinguish two critical concepts that influence different levels in the software: architecture and design. In practice, we often refer to architecture as a high level principle such as using using microservices, authenticating using this kind of flow or another, or more on a high level organization (efficiencies, maintenance, cost, etc.). Those macro architecture principles would then provide guides for the design, referring mostly to the specific decisions made by developers while building/putting together the piece of software. Although for most of us this picture is clear in our mind, it is unfortunately our first conceptual mistake, and lesson :)

To illustrate our point:
Think about an architect planning a house: the architect will need to define the high level plan (walls, materials, etc.) but ultimately, his decisions will influence and define the position of power switches, lights, electrical cables and from which wall the water intake would be located. Macro architectural decisions affect and define lower level design decisions.

Similarly to a house architect, a software architect will define the high level structure, taking decisions that will not only influence, but also strictly define several low level designs. We decide to take a microservices approach that will influence how we communicate between those, structure our code and name our variables & files. As such, we need to consider architecture and design as strictly similar concepts. Software Architect professionals should therefore not limit themselves to high level concepts, but also understand how their decisions will influence and directly define low level design decisions. Software Architecture and Design are the same.

And all those decisions? What are they meant to achieve? What is the goal of a software architect? According to Robert C. Martin:

The goal of software architecture is minimizing the human resources necessary to create and maintain the required system

What does it mean? It means that the quality of an architecture will be defined by the amount of work the related software's creation will require but also what maintenance will it require. I am sure you can already think about one of your project, in which bad architectural decisions lead to hours spent where they shouldn't have been spent therefore costing more to your company, your clients and ultimately your own sanity. Second lesson, software architecture quality can be measured by objective metrics.

Short case study

In order to make it clearer, let's exemplify it using a fictional case:
Imagine a company that is currently completing a project with a team of 8 developers.

Those 8 developers cost USD 800K a year and managed to deliver a product of 1,000K lines of code. We can define their monthly productivity as 1,000K lines of code / 8 devs / 12 months = 10.5K lines of code per months per dev at a cost of 80 cents per line of code. Not so bad in my opinion!

Now let's imagine: Our devs integrated many third party libraries too quickly because they were pressured by deadlines and did not think well about some crucial part of their architecture. After a while, some crucial security issues arise from those libraries, and it's time to update them. Problem: The devs, pressured by deadlines, didn't take the time to integrate the library properly for example in a separated service clustering all the functions using this specific library. They simply called the library directly whenever required directly from many services spread across the software. We all know the complexity arising from this kind of tedious upgrades. In order to upgrade and maintain those integrations that are critical for their software, the dev team needs to grow by assigning a few devs to make sure any third party libraries integrated are maintained up-to-date and integrated properly.

Let's go back to our numbers:
We now have 10 developers for a cost of USD 1,000K a year.
Two developers are assigned full time to make sure to maintain integration and do not produce new code, they only work on maintenance tasks (bug fixing, updates, etc.). Our devs monthly productivity at N+1 is therefore 1,000K lines of code / 10 devs / 12 months = 8.3K lines of code per dev per month at a cost of 1 USD per line of code. A little worse than before.

As you can see, productivity per dev dropped 21% and cost per line of code rose by 25%. Not great. And this is just the first year. As we all know, those kind of behaviors and bad decisions are usually rooted in the company DNA. It will probably get a lot worse before anything will be done by the higher management that will start to witness immense increase in dev numbers, salary paid together with a decrease in productivity (new features, extensions, etc.).

This is the definition of a bad software architecture. A great architecture would have limited the time and resources needed to perform maintenance, bug fixes, updates but also would have kept a smaller team more focused and overall would have delivered greater productivity (at least in theory).

Potential Causes

Most of the time in software bad decisions leading to bad or not so great architecture happen when devs are:
1) too confident about their decisions
2) rushed under crazy deadlines

It is essential that software developers and architects take their time, think their decisions through and make sure their current decisions (that will probably deliver the intended purpose in the short term), will not influence badly their project in the long term.

We all lived situations in which we had to come back to our code, months down the road, in order to change this or this part because of our bad decisions (rushed through to respect deadlines or without consulting our peers). It is tiring, frustrating and difficult sometimes to get back the mindset and momentum we had at the moment of built.

Conclusion

In order to tackle those issues, organizations and developers need to understand and recognize that their decisions might not be the best ones. We need as professionals to understand the implications and tradeoff we make every time we take a decision on software architecture.

Is respecting this deadline more important than really thinking through how I structure my micro-service and maybe spend the next two days structuring it, testing it and making sure it is well integrated within our structure?

Rather than creating monolithic components to go fast, I will rather take some time and separate functions in separated services.

Should I really consult my colleagues when deciding upon going with this kind of data structure for this particular object? Going one way will be easy, the other way will signify building more code an ultimately delaying other things I would like to tackle for another months. Should you kill reusability for the sake of time?

All of those moments/questions will ultimately take a few hours off my planned schedule, sure, but in the long term, a serious look at the quality of my software, the time needed for maintenance and the resources spent on it will give our clients and users satisfaction.

Don't forget our two insights in today's article:
1) The quality of our architecture is measurable objectively with the time and resources spent on building and maintaining it
2) It is better to think a lot on the quality of our software and go slower than the opposite

That's it for today! Although the article was short, I believe it really reminds us all that, when it comes to Software Quality and Architecture, every decisions count both on Macro and Micro level and we need to be 100% aware that quality now will influence quality in the future.

In the following article, we will take the time to learn/situate the great coding paradigms that have a strong influence on how we practice software architecture.

Make your software provide more smiles than tears!

About me

I am a partner at MMPG Consulting, a firm active in the custom software development industry in the Spanish and Swiss markets.

You can add me on LinkedIn or shoot me a DM if you want to discuss specific topics, your software or an idea you want to implement.

Disclaimer

I am writing this series while reading books about software dev, the ideas and principles exposed will be taken from those books. In those articles I will sum them up and discuss concrete examples. I am not introducing new ideas or principles about software architecture. Essentially because my thoughts on it do not, and will not, introduce a paradigm shift or introduce ground breaking architecture principles (...who knows!).

Software Architecture - Complete Guide

Mikael — Mon, 02 Mar 2020 06:50:09 +0000

Introduction

As a developer that has to undertake software architecture problems quite a lot in my recent projects, I educated myself on basic Architecture principles and techniques by reading books (and maybe a few blog posts). In my opinion, Books have higher quality content that is, most of the time, written to be resistant to time and as such can still serve you as a reader in your day to day fast changing environment. So if you want to learn about any specific topic in a deep manner, read a book, blog posts are often outdated, too focused, and not written by professionals or cross-read.

Anyway, after many hours spent reading about Software Architecture, I decided to put together a blog post series based on my findings in order to share with fellow developers (and architects) clean architecture principles. This should be useful for you at all level, from Junior to Senior, in order to build software that is scalable, resistant to change and, the most important, maintainable.

Series structure

I will approach the series in the following way:

#	Title	Description	Link
1	*Introduction*	*Introduction to the series*	*link*
2	What is architecture?	Introduction to the concepts of design and architecture in software and why they matter	link
3	Starting from the bottom	Coding paradigms and why they affect our architecture	--
4	Design principles	5 architecture design principles to always have in mind when designing software	--
5	...	...	...

In each of the posts enumerated in the table above I will sum up key ideas taken from a book I am currently reading and completing the summary with a short collection of thoughts and real life example showing how relevant are those to us in modern days software development and architecture.

Why should I spend time reading those?

If you are new to software development & architecture, reading about principles that structure your software in a way that will make it scalable, fast and easy to maintain is a must. You need to understand how not to grow a monster full of intricate dependencies and bugs that require your entire code base to change in order to get fixed. After all you don't want to just write code, you want to be productive while doing it. Each character you type needs to produce something that will make your software better, not just fixing legacy dependencies after a breaking change was introduced.

If you are experienced in architecture and development, reading about all of those concepts you had to experience at a theoretical and practical level so many times will probably remember you funny and sad war stories about how your own software was poorly or amazingly designed. Sharing comments would be amazing for new devs, and funny discussion topics for experienced ones.

Conclusion

Looking forward to write about this topic as it is often not the first thing we learn when developing code for the web or any other tech but is definitely the single most important thing we need to understand and work on constantly.

See you on another post!
Mikael

About me

I am a partner at MMPG Consulting, a firm active in the custom software development industry in the Spanish and Swiss markets.

You can add me on LinkedIn or shoot me a DM if you want to discuss specific topics, your software or an idea you want to implement.

Disclaimer

As mentioned above, I am writing this series while reading books about software dev, the ideas and principles exposed will be taken from those books. In those articles I will sum them up and discuss concrete examples. I am not introducing new ideas principles about software architecture essentially because my thoughts on it do not, and will not, introduce a paradigm shift or introduce ground breaking architecture principles (who knows!).