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

[Harald Achitz]

C4 is of course not working in commercial software as in open source
projects.
But that does not mean there is nothing to take from it.

One of the most important things could be stopping PR review ping pong,
where Senior devs want others to write code as they would write it, name
variables as they would name it . ...
If there are no serious concerns about the code in general, and it passes
the test, merge. If you do not like it's style, adopt yourself
I think this could be something very healthy for several places :-)


On Tue, 9 Feb 2021 at 19:15, Esa HekmatiZadeh <esa.hekmat at gmail.com> wrote:

> Hi Charlie,
>
> Whenever you adopt the C4 process, you may encounter prioritizing
> difficulties. It's more related to the type of the project, not the timing.
> For example, C4 is very effective in ZeroMQ project because of its
> free/open-source nature, Think about how task get prioritized in ZeroMQ,
> tasks come from client needs, If I need some feature I can make an issue in
> ZeroMQ Issues page in Github, of course clients could have different
> priorities, but the brilliant point here is that the resources who decided
> to work on a specific feature are also clients and individual contributors.
> So, I as an individual contributor can decide which issue is more important
> to me to work on. if you think your issue is more important, of course you
> can work on it but you can not force others to work on your issue because
> you think it's more important.
>
> In a private corporation, things are a bit different, there is some
> limited resources, and there should be some kind of consensus about most
> important issues.
> I think C4 with some additional practice for prioritization could be very
> effective and useful in private companies also however without this
> prioritization practice, you may end up with a situation that you have a
> very important bug at the hand but developers are working on some fancy
> features.
>
> Best,
> Esa
>
> On Mon, Feb 8, 2021 at 4:56 AM Charles West <crwest at ncsu.edu> wrote:
>
>> 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
>> mind?
>>
>> Thanks,
>> Charlie
>>
>> On Sat, Feb 6, 2021 at 4:06 AM Esa HekmatiZadeh <esa.hekmat at gmail.com>
>> wrote:
>>
>>> 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
>>>
>> _______________________________________________
>> 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/20210209/73f7dbd2/attachment.htm>