Programmatic Management (and Patterns)

This article is not quite the case, as they like on Habré. It demonstrates the situation when a programmer tried to look at society through the prism of concepts of system design. And this article will give a simple idea of ​​some patterns to those people who do not want to study them, but are not averse to know what they are talking about.







so



I had a chance to somehow occupy one of the leading positions in one not quite serious ( not serious at all ) organizations (not IT). There were 9 people in my department, 5 of them were engaged in similar activities, while the occupation of the rest was more difficult to call similar - but together a viable process was obtained. I also had information that the unification of my department with another was coming, and that was all I knew about combining.







I must say right away that the article is comic, but as they say, in any joke there is a fraction of a joke .







Along the way, during the writing of this article, I will recall what the different situations are called and write them in the form of patterns (or rather, my modest knowledge of them). To make it more fun, because everyone loves decomposition :)







Start



When I arrived, there was no interaction of entities as such: if there were any problems, it was supposed to turn to me, and two-way: I, in turn, also had to kick people if they could not cope ( front controller ).







Since the organization, as I said, was not serious, I decided that you can do the same kind of creativity as in the systems I wrote - namely, to ensure that everything works reliably, without negativity and automatically (put IoC there). And most importantly, I wanted to achieve scalability so that many new people could come to the department - and I would not have to change the structure (because the organization surprisingly grew rapidly).







First steps



Employee motivation was directly proportional to the position held; accordingly, the smallest number was among those specialists who were the majority (those same 5 people).

And this was a problem, because the whole organization worked on this principle and on almost bare enthusiasm. That is, the benefit to the employees, of course, was, but it was not money. And any of the participants lost too little when leaving, and finding new ones was not so simple. And these 5 people were aware of this, so there were many cases of non-fulfillment of their duties (25%).







Of course, the first thing I decided to multiply the number of employees of one type of occupation, and with difficulty I found 2 more people. Further, I conducted a survey to find out what days of the week which people are preferable to engage in; and finally set himself a substitute. This was a man who did not do his job very well, but was a good organizer and had authority in the team. By this I wanted to kill two birds with one stone: firstly, to increase his motivation by raising him in office; secondly, to add an abstraction layer to the structure, so that he would be the only person from this block who interacted with people ( mediator ) - because, for example, I did not know many of the specifics of their work and wanted to be understood without technical details ( fasade ). Plus, I did not know what would happen to my department as a result of the merger; but at least one integral block (into which you can add any number of employees ( open-closed )) I had. He performed one function ( single responsibility ), so I was calm that he would not be reorganized and that he would maintain his integrity.







Further more



But what about the remaining four? The situation there was fundamentally different: each had its own specifics (1) (something remotely resembling interface segregation , which I did not use); although they were in my department, there were things about which I knew nothing; but the leader knew a higher rank. Therefore, I was not their only leader (2) ( multiple inheritance ). They were all girls (3), I did not have a good idea how to work with them and keep them motivated. It was probably more correct not to go there at all (because they gave fewer failures than the first block), but similar problems forced me to try the same tactics as with the first block: I prepared a list of positions for which additional people were needed and I wanted to appoint the main unit.







Thus, the department would be fully scalable.







With these suggestions, I came to the central meeting of the organization.







The final



Unfortunately, my proposals were not implemented due to differences in views. Well, they know better)







Nevertheless, being in this organization gave me a fun experience that I would not dare to repeat in a real company. And that's cool)







What would you do in this situation?








All Articles