The solution is to form cooperatively owned, democratically operated, companies.
The primary difference of interest here is the way an employee owned cooperative is directed by people the employees (who know what is really going on in the company) and for their benefit, rather than for the benefit of disinterested shareholders.
Without a clear provider of vision and decision, it crumbled. This part is true of any venture, but I think becomes even more critical in a co-op since the authority is necessarily shared.
I think in broader terms, cooperatives are bound to be less efficient than an equivalent capitalist controlled venture, but that difference doesn't have to be a death sentence for the cooperative.
If you are brilliant at engine design does not mean you are brilliant at selling cars.
Selling cars make money. There is negative value in a bunch of engines lying around.
As software engineers we design automation to make a business more efficient.
To make money you need to run a business.
Wow, great solution!
Except that, of course, you're missing the problem. Firing the employee isn't the problem - I don't think it's relevant whether it's done democratically or if the CEO "dictates" it.
The problem is, how to find freeloaders? In absence of objective metrics (which is what the parent raged against), it's an art! Or, it will come down to internal politics, ass-in-the-seat time, popularity contests, ... not that much better than in a non-cooperative company.
If you have a system where a freeloader can win, then you have a system that encourages freeloaders.
There are other systems that make freeloading impossible.
Are you aware of pair and mob programming?
People want to be successful.
No one likes to lose.
Even a freeloader is expressing that behavior because they believe that is the best way to win.
Pair and mob programming completely makes freeloading impossible. It also is true teamwork where everyone is literally on the same page.
The reason why you have a system where a freeloader can win is management that believes pair or mob programming is a waste of time.
This allows silos to build up, provokes and allows for dividing politics of who can know how something works or not and breaks team morale.
You get the behavior you design for.
We prevent freeloader problem by requiring everyone to pay taxes. The equivalent at work is requiring ass-in-the-seat / face-time policies.
I don’t see how pair programming can solve anything, people can still contribute zero (except their presence).
That's not how pair programming works.
Pair programming is not sitting and doing facebook while the other person churns out code.
Infact, in pair programming, that is exactly what you cant do.
Once you understand this, you intuitively understand why mob programming is so much more efficient.
Apologies if I came across saying there is the only way to do it. Let me rephrase - if there are multiple stakeholders in a product, I have found it really valuable to have them, physically or virtually in the same space as the work gets done and feedback gets provided in real time dissipating confusion and questions as soon as they arise.
In my experience, fixing an issue at the source is cheaper than discovering it later and running to fix it then because the wrong assumptions were made just because everyone is too busy banging out code.
Creative blocks as real. Rubber ducking is effective and real too.
> I think most companies have no time to have 2 or more programmers working on the same thing even if it produces some decent, soon to be legacy code
1. Why do you think that is? If this question totally flummoxes you, a narrower question could be "what is the objectives of these companies with the code", but try answering the broader question if you have the time
2. Do people generally solve problems better when working in isolation or as a team?
Now, did the companies you have experience with not have more than the programmer who wrote the code review it?
Or test it?
Who wrote the requirements?
Who checked whether the deliverable(s) met the requirements?
In my experience, more than one person ends up touching the code in one way or another until it actually reaches the customer.
I have found, the overall quality is much better when everyone is working together instead of in a waterfall model, in strict sequence with lots of back and forth and meetings with subset of stakeholders until the product actually behaves the way its expected to. Reliably.
The risk of this happening goes up as removed the programmer is from using the product themselves. So if dogfooding works on your projects, by all means do it.
Looking forward to your thoughts.
I'm confused - it seems to me that you understand that ass-in-the-seat / face-time policies only address the presence problem but cannot address contribution.
1. Do you agree with this? 2. What's your solution to fixing the contribution problem?