[zeromq-dev] C4 - The Good, the Bad and the Ugly?

Charles West crwest at ncsu.edu
Mon Feb 8 02:23:40 CET 2021

Hey Esa,

Thank you for taking the time to respond!  If I understand you correctly,
you like the basic properties of the C4 process but had difficulties
adjusting it to work on a corporate project that had interfaces not built
with it in mind?  Does that sound right?

Do you think the scheduling issues would still be a problem if your
organization was built from the ground up with use of the C4 standard in


On Sat, Feb 6, 2021 at 4:06 AM Esa HekmatiZadeh <esa.hekmat at gmail.com>

> Hey Charlie,
> I have used the C4 model in a corporate project in a private company. It
> has a lot of brilliant ideas and novel benefits, however there are certain
> things that you should be aware of before using it. like other things, it
> has pros and cons. In this email I will try to explain my thoughts and
> experience about it. Of course, my understanding of C4 might not be fully
> valid and correct, I ask others to correct my understanding about it if I
> describe something wrong.
> The first positive point that comes to my mind is that it really
> appreciates diversity in the team. by its democratic model, it enables
> everyone to have equal voices and it really helps collective ownership of
> the project. Besides that, it has a very simple and understandable model
> for every developer, it's really easy to apply it in a project without
> worry about complex branching models and different kinds of tasks. One
> novel idea in C4 is that every change should address a problem,
> everything's a problem, there is no distinguishing between Task, Story,
> Feature, Bug ...
> The above positive points in C4 make it a really useful model in
> developing an open-source project, however its too democratic approach may
> not be suitable in all environments.
> For example, in our case, we had a lot of important issues at hand, a
> rigid roadmap defined by product managers, and limited resources. C4 does
> not tell you how you should prioritize your tasks in the team. Of course,
> the approach that "everything is a problem" would help you a lot to find
> out most important problems in the project and address them first, although
> it's a little hard to communicate it with product managers, and also, it
> requires every team members to have a solid understanding of the business
> needs and the whole big picture, it's not an impossible thing, but it
> requires a very mature and pro-active culture. Maybe having some additional
> principles to prioritizing tasks and making consensus about most important
> issues to work on, could improve it in this kind of situation.
> --
> Best Regards,
> Esa
> On Fri, Feb 5, 2021 at 7:59 PM Charles West <crwest at ncsu.edu> wrote:
>> Hello!
>> I'm a longtime user of ZMQ and fan of the project.  I've been reviewing
>> Pieter's writings about the C4 process and would like to use it for the
>> (robotics/Godot/machine learning based) open source project I am hoping to
>> launch in the next few months.
>> Before I commit to that though, I was wondering if the awesome people of
>> the ZMQ mailing list might be willing to tell me about their experience?
>> Does it work as well as Pieter said it did?
>> Biggest advantages over other processes you've worked with?
>> Biggest problems you've run into?
>> Would you recommend it for a new project?
>> Thanks,
>> Charlie West
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20210207/a4722520/attachment.htm>

More information about the zeromq-dev mailing list