An Unexpected Inquisition

An Impromptu Interview about Sovereign Software Development

In a functional programming chat room, a user named donderom set off a series of questions that unintentionally kicked off an impromptu interview explaining the reasoning behind my advocacy of Sovereign Software Development.

With some minor edits for clarification, the interview proceeded as follows:

donderom: Let me start with an easy question: what would make usage of FP easier for you (in the next year)?

bryanedds: Less corporate fuckery and more developer sovereignty.

donderom: Aside from that? I understand your points but they’re not related to FP. :)

bryanedds: The problem is more fundamental than what implementation paradigm is being used. Until these problems are addressed, no variation of paradigm is going to make much difference. I think engineers get distracted by implementation details while far more important things get compromised.

What difference does an engineer’s choice of tool make when he has already compromised away his ability to do anything terribly well with it?

The starting point, I believe, is the above sovereignty article.

donderom: The starting point for what?

bryanedds: Building / changing software institutions where necessary engineering integrity is preserved and engineers are respected.

Codes of conduct are just one small aspect of that disrespect for developer freedom — although I suppose the most visible nowadays. If anything, they seem to have been merely the ‘last straw’ for a lot of people who have lived through a long train of social and corporate abuses.

What we’ve found in the software community is that coerced tolerance for everything leads to a practical tolerance of nothing. Anything you say can and will be held against you.

donderom: From my experience doing the right thing is easier than trying to change others.

bryanedds: Well, it’s been my experience that doing the right thing for any length of time eventually gets you removed from most corporations. Are you saying you have a different experience?

donderom: We don’t disagree at the main point but it seems to me you speak about in every context. What I’m saying is that talking about tools makes the difference when you’re free of any fuckery.

bryanedds: Right.

donderom: Because you’re talking about corporations. My point is that it’s not such a big question working “for yourself”.

bryanedds: But even the small companies act exactly like corporations nowadays, for the most part.

donderom: Okay, 1-person shop.

bryanedds: Ah yes, that’s true. Obviously, in my open source projects I can do whatever I want, but that has it’s own dire sustainability problems, EG — making any sort of living of it. So doing open source long enough, you eventually run into the problem of not being able to do it any more because you run out of resources to do so.

I used to be an indie game developer. But none of that stuff makes money any more than, say, buying a bunch of lottery tickets. And maybe there is some market segment out there that a single programmer can serve, but I haven’t personally found one. The point is, I think it’s a false dichotomy between being constantly preyed upon and being self-employed.

donderom: I think it was corporate fuckery, not universal. :) If you want to expand your 1-person team is up to you to set up the right “culture” isn’t it?

bryanedds: Well, you won’t be expanding anything until you have some way to make money.

donderom: It’s absolutely different question. If one doesn’t have any ideas how to make money and doesn’t want to work for bully corporates… you know…

bryanedds: Sorry, I just think the dichotomy you’re presenting is false. You should be able to be both employed and respected. I don’t think that’s too much of a leap.

donderom: Actually the initial question was about the possible improvements to the tools and second that setting up the right attitude is easier than changing existing one. And everybody agrees on that but you have to deal with reality somehow right?

bryanedds: Ya — reality is the hard part.

donderom: If one understands that his job sucks what options do they have? Preaching the truth during the meetings? What?

bryanedds: The fundamental problem (I think) is that we have a societal culture of ‘giantness’.

Back in the 70’s E. F. Shumacher wrote a book called “Small is Beautiful” in an effort to affect change. Sadly, the change did not take place. In fact the problem has only intensified.

donderom: (Should you) leave the company? Personally I think it would be the good choice but it may be not for others.

bryanedds: Well, if the reasons you are leaving a company is for practices that have effectively become industry standard, then not really. Because wherever you go, there it is again.

donderom: What I don’t agree with (and I don’t insist you’re saying it) is that it’s 100% universally fucked up. That you’re better to prove. Because if there is one, at least one case which is not fucked up it cannot be universalized.

bryanedds: Well, I can put it in relatively simple terms. There is a basic minimum of respect that employees deserve and a basic minimum integrity software needs in order to be humane to work on. However, industry-standard practices like agile effectively gut out this minimum.

donderom: Absolutely. The question is what’s the plan to achieve it?

bryanedds: The only suggestion I have is in the above article.

I’ve tried the entrepreneurship route — my experience has not given me reason to believe I am personally cut out for it.

There was an article showing how success at entrepreneurship is more highly correlated with family wealth than other factors.

donderom: In any case be it entrepreneurship or employment there should be people responsible for that. And from my experience I don’t see how it’s even theoretically possible considering developers who are the lowest level at any big corp.

bryanedds: The economics are certainly against us. The supply of developers is constantly increasing, which can only lead to a more abusable talent pool.

donderom: Yeah, I think it’s correct observation.

bryanedds: I really don’t think I have any answer for sure, but I’m at least struggling to come up with some ideas — which frankly, is far more than most other developers are doing.

Most other developers seem to have turned on each other, and on their own personal beliefs. I don’t think that’s a good answer.

Even I, myself, and have said some regrettable things to other developers who perhaps only seemed to side against ethics.

We can’t keep falling into that trap.

donderom: It’s hard to come up with long-term goals when JS frameworks change the scene so fast!

bryanedds: lol

I think it does all go back to E. F. Schumacher’s ideas though.

donderom: You know, Ten Commandments consists of good ideas but…

bryanedds: But what? At the end of the day, you have to choose to live your life ethically or not — and to me that’s paramount to other concerns.

Other people, obviously those running things, differ…

…but no one can say which choice will ultimately bear more fruit in each of our individual lives.

donderom: My problem while working for The Corp Fuckery & Co was that I was telling about ethics and so on to other people they asked me how I deal with it… and answering “I don’t actually” is the worst strategy I’ve ever had.

bryanedds: Just because we’re confused doesn’t mean we’re wrong.

donderom: I don’t know how much time you spent fighting for it but wasted years. I (eventually) let them rot without me.

bryanedds: Ya, we’ve spent similar time on it. I really do wish I had some better, more practical ideas.

donderom: For me the killer feature of the future companies is the combination of ethics AND technology. The dispute if one can be ethical developing in Visual Basic is still open.

bryanedds: lol :)

donderom: Let me put it this way. What the first thing you want to see being changed? Just one.

bryanedds: End collective code ownership.

That’d be the best start — as it will preserve the integrity of more code and empower engineers to make other (more social) changes.

Collective code ownership has gutted us in so many ways, it’s hard to count them all.

donderom: Do you think microservices fit into your picture?

bryanedds: I think a lot of people, perhaps with some of the same sentiment as we, think they can use technical solutions like microservices to address what are essentially ethical and social problems. Leave it to engineers to try to solve all their problems with technical solutions — whether it makes sense or not.

However, in my experience, most common uses of microservices do little but add unnecessary complexity to development — the very same kind of complexity that makes software development an increasingly inhumane process.

Perhaps the same could be said to some degree of functional programming — minus the remark about adding complexity.

Modern engineers look around, and see all these blatant problems, and their first, second, and third instinct is to come up with technical solutions. But I’m one of the few people who have worked at companies who use both functional programming and microservices, and I can tell you they did not solve, much less address, these problems.

Most engineers are rightly apolitical, and avoid involving themselves with political issues. But it is my experience that attempting to solve problems rooted in unethical business decisions with new technologies, paradigms, methodologies etc. doesn’t work.

So eventually, we’re going to have to face the reality of the situation — if we are to solve the problem, we have to meet it with a non-technical solution. Which is why killing collective code ownership is so important. Doing so addresses the social problem with a social solution — in the same way that I think E. F. Schumacher would recommend in accordance with the principle of decentralization.

donderom: The members of the chat are witnesses, I tried to shift the discussion to the technical point of view. :)

bryanedds: But then that’s entirely the problem. So long as you try to solve a social problem with a technical solution, you won’t get anywhere. That’s the lesson that took me 10 years to learn.

donderom: As I see it the code ownership (change) leads to some technical steps doesn’t it?

bryanedds: Both technical and social — (collective code ownership is at) the layer where the technical and social come together — and therefore the place we should look for a solution.

donderom: (C’mon, don’t bother Silicon Valley to make the world better, we are still here waiting…)

bryanedds: Does that not make sense?

donderom: It will more if take the simple example. Imagine there is a code base for a site. You and me are the only developers.

bryanedds: Right.

donderom: And we both agree on the code ownership issue. What do we do next to avoid the issue with code ownership — assuming that we agree on the ethicalosocial aspect of it?

My question (if there are two initial developers,) who is the Crown in my example?

bryanedds: Typically, the first person who hacked together the prototype. For they are the person who outlines the architecture and have the most knowledge of the system.

If two or more people hacked it together at the same time, then some more interesting questions are raised. If it’s an odd number of people, it should definitely come down to a vote.

For 2 people, though, I suppose it’d have to be a fight to the death —

Just kidding, of course.

Like in business partnerships, it’s probably still better to have just one head architect rather than trying to share role — even if all other things are equal.

So however business people make that decision, presumably you could use the same method here.

donderom: Okay, I’ve created file for our website, I’m the Crown now! :P

bryanedds: Take a look at how John Locke describes how natural property rights are constructed out from nature. Specifically, how free land must be transformed in order to become homesteaded — that is, owned by it’s first owner. Obviously, cutting one piece of grass would not give you ownership over an entire meadow. At best, you would only own that one piece of grass.

You can be the crown of the file if you really want, I suppose.

In practice, it’s whoever hacks together the first prototype. And I know what some might say, ‘why the prototype’? Well, because in practice, your prototype is the seed of the actual system anyway since nearly all selected prototypes go into production.

And presuming you put a good architecture into the prototype (as that’s one of the points of a prototype — to prototype an architecture for the production solution), you will have transformed the repository in the way that John Locke would require you to transform homesteaded land.

donderom: What if the prototype is not so good and it’s obvious for the others (vassals)? What weight their voice has?

bryanedds: Then that’s a good time for the team to decide someone else to take the role of the crown. However, it would be a difficult thing to do, since you only know the outcome of the programmer who built it — how would you know if anyone else would have done better?

donderom: In that decision does the current Crown have the same vote weight?

bryanedds: I would presume so. Even if we know someone is going to vote in their self-interest does not disentitle them.

donderom: How would you know if anyone else would have done better? As you said, let the team decide.

bryanedds: Though Mel Brooks once told us “it’s good to be the king”, the fact is that the crown in this case’s most important task is to hand over as much code ownership to vassals as possible. He certainly cannot by himself maintain an entire system as it grows. And the true power in this system comes from code ownership, not the title of Crown, or what have you.

donderom: As a happy case scenario, yes, but I would rather not have the doors to abuse at all.

bryanedds: The crown’s job is to create the initial implementation and guide the vassals toward his envisioned architecture. Obviously, however, there must be a way to remove a crown if he consistently acts against the interests of the project or its people.

donderom: I still think the idea with README file is brilliant. :>

bryanedds: We’ll see if that flies with the team. :)

donderom: So,

1) Add the README file
2) Become the Crown
3) Add CoC

bryanedds: pwned :)

Yes, maybe the ideas I put forth are neither complete nor necessarily satisfactory, but I’m honestly hoping for someone to come along with a better solution.

Until then, we’re stuck with the ideas we’ve have had. And I’m not yet convinced the solution I’m putting forward is all that crazy. No crazier than Agile, at any rate.

So the answer to your actual original question is, what tools do we need to make FP better in the next year?

The answer is, tools that help all programmers, not just functional programmers, organize teams to use post-agile processes like Sovereign Software Development. Any tool that helps us organize ourselves and our work along those lines is what’s really going to make the difference.

Perhaps a portion of the solution is technical after all.


Dealing with the Bus Factor in the Context of Code Ownership

One question I repeatedly get is system with code ownership, like Sovereign Software Development, deals with the bus factor. The bus factor is the hypothetical scenario where one engineer who owns a piece of code is hit by a bus. For those who have read my writing in-depth, they will already know how the concept of ‘Steward’ was introduced to solve the issue.

Essentially, it works like this — while a module of code is owned by a ‘Vassal’, there are one or more Stewards who are responsible for the functionality and general knowledge of said code. So any time a Vassal checks in a change, it is reviewed post-hoc by the code’s Steward(s). Stewards thus act as sanity-checks for ongoing changes, as well provide redundant understanding of the code. With each Vassal being a Steward for one or more modules other than the one he owns, there is enough redundancy to take care of our hypothetical bus factor.