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.hek...@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 <crw...@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@lists.zeromq.org >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
