4 ms·

Manifesto for Self-Managed Software Development

53 points by aard 7y ago

CameronNemo 7y ago
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.
sumanthvepa 7y ago
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 7y ago
  > 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 7y ago
    Or worse, they stay for ten years. Hypothetically speaking, of course...
collyw 7y ago
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 7y ago
  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.
  - ASTP001 7y ago
    This reminds me of a chapter from Clean Code by Robert C. Martin where he suggests using names from the "solution domain space" ie. CS terminology, because names are succinct and more precise which is preferred over long names that are tied to some specific domain for which the software is being developed for, which might require expertise that is disparate. The author suggests to use terminology from the "problem domain space" when "there is no 'programmer-eese'" name for it. My team had a discussion about this and some argued that this might alienate programmers who are novices, and might be easier to use "Enlgish" but I think that if the problem space for your software is niche enough then a new team member, or a novice will have to learn terminology either way. In my opinion, programming terminologies are more precise and transferable to other programming jobs and problems in general, so is a more sustainable and relevant way of learning. It might be tough at first, and I agree the attitude of the senior dev would make a huge difference, but as long as the senior dev takes the initial confusion of the novice as a good teaching moment, and explains it patiently and clearly I think it can be more valuable in the long term.
vannevar 7y ago
Aka, "Manifesto for the Solo Software Developer". Godspeed, Lone Ranger.

53 points by aard 7y ago

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.

sumanthvepa 7y ago

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 7y ago
> 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 7y ago
  Or worse, they stay for ten years. Hypothetically speaking, of course...

collyw 7y ago

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 7y ago
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.
- ASTP001 7y ago
  This reminds me of a chapter from Clean Code by Robert C. Martin where he suggests using names from the "solution domain space" ie. CS terminology, because names are succinct and more precise which is preferred over long names that are tied to some specific domain for which the software is being developed for, which might require expertise that is disparate. The author suggests to use terminology from the "problem domain space" when "there is no 'programmer-eese'" name for it. My team had a discussion about this and some argued that this might alienate programmers who are novices, and might be easier to use "Enlgish" but I think that if the problem space for your software is niche enough then a new team member, or a novice will have to learn terminology either way. In my opinion, programming terminologies are more precise and transferable to other programming jobs and problems in general, so is a more sustainable and relevant way of learning. It might be tough at first, and I agree the attitude of the senior dev would make a huge difference, but as long as the senior dev takes the initial confusion of the novice as a good teaching moment, and explains it patiently and clearly I think it can be more valuable in the long term.

vannevar 7y ago

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