DEV Community

Discussion on: Anarchitecture

Collapse
 
diakula profile image
diakula • Edited

Complements on the enthusiasm and time taken to put into good text! You feel strongly about this, so the energy is there, and this is the most important to drive a community.

Nevertheless...

Where is your evidence? Besides convenient quotes, I see an article with confirmation bias scoring through the roof.

The whole article is centered on the developer and their experience from conducting business. This is very convenient to make your life good, to be listened to on your opinions, and to feel good about yourself in successes (I helped win) and failures (somebody else messed up).

Have you created a business where you have put bread on the table for 3-15 employees?

Have you surveyed successful business on their models in writing your article? With statistical significance of the surveys?

I suspect not.

In my opinion, the described model can only really work for large open source projects (even those are dictatorship to succeed with massive value), or niche consultancy and freelance. One may see this model also work, if a business has made quite some money that provide substantial insulation from market pressure, and wants to experiment with an ecosystem, but doubting this can work under any real market pressure.

The piece that in my opinion has most value from this article is, that it addresses the pressure on developers that stifles their creativity. Flow and Creativity are the most important commodities for a developer. Any improperly done pressure for dates, for compromises, and so on, will stifle creativity. It is a bit of an art to fix that, but has nothing to do with anarchy.

Collapse
 
risavkarna profile image
Risav • Edited

Programmer anarchy is an idea promoted by Fred George, an industry veteran who has had successes with his approach. You can see him claim here that, "managerless processes are not only feasible, but nearly indispensable" albeit just for "solving certain classes of problems (Complex problems in the Cynefin model) and for achieving rapid, continuous delivery (exploiting MicroServices)".

I would also encourage you to look up his case studies if you are genuinely interested. However these still do not make a large enough sample for statistical evidence. It is hard to have non-anecdotal evidence for something that has not been tried out widely enough.

As I mention in the earlier comment, I will be reporting back on how it plays out for our new team, which is comprised of smaller autonomous teams in 3 continents and developers often crossing time zones to meet partners and clients. However this is not my hypothesis and therefore on me to prove actually. I am merely summarizing the project management journey of the industry and how the founders of agile movement view the current state.

You can still make your own judgment of the situation by looking at companies like SonarQube, or the ones I have worked at as a developer/architect (you can google or find my LinkedIn/Xing linked in dev.to profile, since you asked) where the managers themselves are experienced developers and communicate with both customers and developers with near to zero semantic gaps.

Lastly, I insist that anarchy is the essential fix for teams with enough senior developers who can take the lead as and when needed. "Anarchic teams have emergent leaderships and self-organization strategies rather than pre-ordained leadership or lack of well-suited organizational strategies." That's why this is merely a lengthy opinion piece piggybacking on historical summary.

Collapse
 
diakula profile image
diakula • Edited

Thanks for the response, I am looking forward to your reports on success of the projects and business as a whole. Thanks for the useful pointers too, will checked them out.

A few notes.

Bad management is bad in general, not just to developers or in the context of software projects. The goal of a good manager is to "remove" the need of themselves through training independent, productive and powerful team members.

Emerging managers from a tactical background have one big challenge - how to delegate, really. A domain-expert manager under pressure for delivery often ends up "robbing" (subconsciously) his team mates from sharing opinions (most experienced person in the room), failing on their own, etc. As such, an manager that is expert can actually fail to build a powerful team of independent empowered experts.

On the other end, a pure manager over a technical team can never reach the depth needed for full velocity, or fail to gain the respect of the team members. It is a bit ironic really.

Therefore, a practical thing may be to actually compose a "handbook for the emerging tech lead" how they can let their team mates grow.

Thread Thread
 
risavkarna profile image
Risav • Edited

The goal of a good manager is to "remove" the need of themselves through training independent, productive and powerful team members.

Amen to that. Even a good developer should aim to make oneself obsolete although you may only get asymptotically closer to that goal currently.

I often cite the example of the movie Armageddon where they chose to train miners into becoming astronauts rather than choosing to train astronauts to learn the parts of mining necessary for their asteroid problem. I would love to see the industry shift towards training developers to be managers instead of certifying managers for technical project management.

I am still chuckling as my friend just shared his piece of misery to me after reading this article:

Developer: "This is out of the scope for this sprint. It will take extra resources. We cannot manage it now."

Project Manager: "I just feel like I should learn how to program and just show you; you can do it over night."

This was overheard at a prestigious company that my former roommate quit after 6 months so as to not let his PhD go to waste.

Thread Thread
 
diakula profile image
diakula • Edited

Good move, that guy, he apparently knows where his career needs to go, commendable on not taking shit too long!

What is funny, is that both roles can be right, from my personal experience on both sides of the trenches.

The project manager comes off as disrespectful in the end.

The developer is probably OK.

Having mentioned academic background, there is one note I want to make.

It is very demotivating to live as a developer knowing that you always have to make compromises with designs to make money and meet project timelines.

There is a positive way to rephrase this that is very very powerful:

  • "Find the right problem definition!"

A good developer with an academic background knows what is the BEST possible theoretical solution 90% of the time. This is what they are solving. Subconsciously, everything they solve is measured by that, and hence the satisfaction level is correlated by the size of compromise.

This is not good way to live.

What is important to understand when in business, is that the realistic problem rarely is academic. You can be in business with a half baked awkward and expensive to run legacy monster service for 20 yrs. But it is beautifully reigning in money, until the competition comes.

Therefore, the developer requires a lot of respect, but also training in pragmatic problem description. A dev has to wire up their internal reward system to always giving 100% to what is necessary for the problem at hand.

Identifying the right problem to be 100% no compromise on the spot is the art form.

Some call it scope, but there is psychology behind it too which if not aligned, is massively demotivating.

Thread Thread
 
risavkarna profile image
Risav

Well said regarding problem definition. I happen to have a similar but a bit of an extreme opinion on this, pieced together here:

"Businesses, [also clients or managers] can still partner with software teams in an agile way to properly define the problems and agree upon the desired features for any possible solution that may emerge in the solution space after enough iterations [but nothing more...]
Otherwise we would be in the business of building the fabled horse carriages of customer's dreams when we could be building them cars or even star ships that the customers do not yet know about."

Thread Thread
 
diakula profile image
diakula

Indeed! Building a team that draws motivation and satisfaction of delivering iterativelly is the challenge. It is the essence of realizing what developer profession means.