
Manifesto for Self-Managed Software Development - aard
https://flatwire.org/2020/02/23/manifesto-for-self-managed-software-development/
======
sumanthvepa
I'm the owner of my small software development shop. So that makes me
management. I'm also the principle programmer of the code we develop. We have
junior developers whom I manage. There are several deep problems with the
rules described above. The primary problem the assumption of agency inherent
in these recommendation. The manifesto assumes that interests of the
employee/programmer are identical to the owners/managers. Most of the time
they are aligned. Occasionally, usually on critical decisions, they are not.

Take for example the principle of code ownership. I would very much like my
junior developers to own the code they develop, fix it and take pride in
maintaining it and refactoring it. However, for some of the individuals, their
objective is to learn as much as possible in the shortest period of time, so
they can grow and get higher paying jobs. This is a perfectly legitimate,
indeed desirable objective, for any individual. However, this also, often
translates to a lack of interest in maintaining code. So as their manager, I
also become the owner of the code. I find myself, maintaining a bunch of code.
I'm okay with this. I do delegate some maintenance of the code to others, but
I usually find myself modifying and once in a while rewriting the code, until
it is in a generally stable state, that does not require much maintenance.

Them there is the idea of voluntary and free collaboration. In general of
course, employment is voluntary, but I'm guessing the recommendation is not
made in that sense. The idea I think is that programmers should be free to
choose their own projects, possibly their own tech stack. That does make sense
within the confines of a given business need. However, free reign can be
dangerous. I routinely find, that my programmers, prefer to rewrite code in
the latest fad framework, rather than simply fix issues with old code. In one
extreme instance, I had a programmer use reactJS for what ended up being about
20 lines of plain Javascript. It seems like he wanted to learn to use React. I
deployed him onto a project that actually did need react, and rewrote the
original code in plain JS. It's now code that needs no maintenance at all.

Nevertheless the sentiments expressed in this manifesto are important to keep
in mind I suppose.

~~~
speedplane
> junior developers ... objective is to learn as much as possible in the
> shortest period of time, so they can grow and get higher paying jobs. This
> is a perfectly legitimate, indeed desirable objective, for any individual.
> However, this also, often translates to a lack of interest in maintaining
> code.

I've seen this over and over again. It can be frustrating for a junior
developer to create a large class hierarchy using arcane language features to
solve a problem that can be done with a function and a for loop. The problem
isn't so much that the code itself is more complex than it needs to be, it's
that when they leave, someone else will have to pick it up.

~~~
hinkley
Or worse, they stay for ten years.

Hypothetically speaking, of course...

------
CameronNemo
All good ideals, but no way to execute them with so much management in the
way. An important point for industries dominated by bureaucracy, oligarchy,
tenure, and political favoritism.

I work for a research and education network, and the only way to challenge
management is via board members who cycle every three years and have little
stake in the business, if any.

Larger telecoms are so hierarchical that any progress you might make could be
wiped out overnight by some c level or VP who feels threatened or jealous of
your team's output.

With consulting firms, we just outsource the hierarchy to a third party and
put up blinders to what we work on behalf of.

If anyone is hiring for a data analyst, data science, or general software
development role that has high social impact -- please let me know.

------
collyw
This sounds like the philosophy of a couple of developers that I have worked
with.

Basically they just picked and choose whatever they felt like working on (in
both cases they were raised on a pedestal by the company owners so got away
with this). They were not team players and other developers needed to pick up
the slack on the less interesting grunt work that needed to be done to keep
things working.

~~~
hinkley
Early in my career I had this illusion that working only with senior devs
would make everything better. But the first time this happened was not what I
had expected. Every single bit of grunt work was engineered away. In theory
that sounds like it might be nice, but rather than write a little repetitive
but clear code, everything got a processor or an engine or something, and with
some generic computer science name instead of using nouns and verbs from the
domain. To figure out what a piece of code did, even generically, you had to
decipher it to know what.

All of the code did something but none of the code said anything. It was
horrible.

I very quickly embraced the notion that software wants a mix of developers of
different skill levels, so that any task that must be done can find an author
who will remain engaged, and not have to create baroque code to get themselves
to do the work.

~~~
wangvnn
We already have to deal with this in current state of Class Oriented
Programming. Every class does something, none of them say anything about how
the program work at run-time as a whole. So bad naming (cleverly bad) just
adds on so much trouble in. Good naming from the domain helps, but it can not
carry the program that far since it only addresses things at low level. At the
architecture level, the class hierarchy still in control.

e.g.
[http://www.cs.unc.edu/~stotts/GOF/hires/chap1fso.htm](http://www.cs.unc.edu/~stotts/GOF/hires/chap1fso.htm)
"An object-oriented program's run-time structure often bears little
resemblance to its code structure. The code structure is frozen at compile-
time; it consists of classes in fixed inheritance relationships. A program's
run-time structure consists of rapidly changing networks of communicating
objects. In fact, the two structures are largely independent. Trying to
understand one from the other is like trying to understand the dynamism of
living ecosystems from the static taxonomy of plants and animals, and vice
versa."

~~~
hinkley
Someone I read about code maintenance and/or quality years ago asserted that
if the code uses different concepts than the domain the software is designed
for, then you have intentionally built an impedance mismatch into your project
and you're gonna have a bad time.

I haven't read enough about DDD to know if he was just a precursor or onto
something else, but it does seem to map well to my least comfortable work
situations.

------
vannevar
Aka, "Manifesto for the Solo Software Developer". Godspeed, Lone Ranger.

