5 ms·

Does not fit my experience. Best software I've seen was always single good developer. Plenty of great single-person open source software out there to prove it.

Does not fit my experience. Best software I've seen was always single good developer. Plenty of great single-person open source software out there to prove it. The problem is - good devs are actually very rare. A single not so good developer doesn't get any feedback, yet they have all the clarity and context in what their code is doing, so they can take their terrible code quite far.

bruce511 4y ago
Obviously experience will vary from person to person. But your point is well made. The quality of the code depends a lot on the quality of the programmer. Better programmers write better code. Of course very few of us are great programmers on day 1. we learn and get better. I'm spending a reasonable amount of my time now re-writing code I built 25 years ago. Equally, we grow better, and learn faster, when we get feedback. All too often the lone programmer is not reading code written by others, and is not getting feedback on his own code. So growth is slowed, or in some cases stopped for decades. Bad habits from 20 years ago still exist because there's no-one to rail against them. So yes, lone programmers can be great, especially if they are outstanding to begin with. But the vast majority are mediocre and need the assistance of peers, and seniors to grow. On the other hand those that grow up under seniors with bad habits, who _enforce_ those habits, are screwed.
- avgDev 4y ago
  I have been a lone programmer for a few years. Whenever, I'm doing bug fixes I dive deeper into "how someone else would approach this". It is actually quite easy to keep improving on your own. I read books on refactoring, clean architecture, etc. as part of my daily routine. The time not spent debating with another dev is spent learning. I guess as a lone dev it is easier to do no self-improvement and keep apps chugging along until something terrible happens.
ricardobayes 4y ago
This works if there's no time pressure involved.
- klabb3 4y ago
  This is key. Good projects are based on good ideas. Good ideas take a lot of time to develop, and often involves back and forth, iterations, friction and failure. If you have a good data model and technical architecture, the code almost becomes good on its own, even if it’s implemented by more people that understand the model. The problem is that it’s irrational to spend that amount of time, and it’s directly opposed to incrementalist mainstream paradigms of software development. It’s the process that almost has to happen outside of companies, because management would never let projects be executed in such a way. But when there are personal drivers (either by the creative aesthetic types or sometimes the hacker tinkerer types) you can sometimes, depending on the domain of the problem, get some really coherent systems that make people go “this makes sense, why would it be done any other way?”. To me, the story of git has many of those traits, especially when comparing to what existed before.
danjac 4y ago
As a sole dev you are also pushed towards simplicity, because your time and scope is so limited. So a larger team might build some intricate DDD-microservices architecture with a services bus and a complex SPA frontend because, why not? That's what everyone else does. As a single developer managing multiple microservices or separate backend/frontend codebases is a lot of overhead (unless it's a learning project). You have to do the simplest thing that will work. So if you can get away with server-side rendering, do that. A monolith makes more sense when you don't have multiple pizza teams, and so on.
- robertlagrant 4y ago
  This is true - you may (possibly) end up in a scalability dead end, but you will likely have been far, far more efficient along the way.
  - TeMPOraL 4y ago
    I think the only scalability dead end you'll end up in is people-related. That is, you won't be able to scale further because it would require using patterns/solutions that balloon the complexity so much you now need a team to keep track of it, and/or it would require more money than you can manage handling on your own (e.g. you would need to turn your project into an actual business in order to fund it further - at which point you need to start hiring people, to either do the businessy bits for you, or the technical bits, whichever your preference).
- fhd2 4y ago
  Or in other words: Conway's Law makes single developer code bases less complex, since there's no communication and responsibility boundaries reflected in it. That said, I've seen a lot of small teams create a ludicrous amount of microservices. One per independently working team is my usual heuristic.
  - danjac 4y ago
    There is a problem in the tech industry where people's pattern matching isn't terribly good. They will have worked for a big company, or have read literature produced by people working for big companies, and concluded that "microservices" (to pick one pattern) are the best practice, because it worked for $BIGCORP, or they expect to be $BIGCORP 2.0 at some point, so why not be ready for that? But, as you point out, microservices are the result of Conway's Law and shipping your org chart, not necessarily the best way to build software all other things being equal. If your org chart fits comfortably inside a broom closet, then maybe you're not quite ready yet for microservices.
hyperpape 4y ago
One way to put it is in that single developer code will have more variance, when compared to code developed by a group. This variance has a range of effects, and will sometimes be positive, sometimes negative. Certain idiosyncracies are unlikely to survive work in a group, which can be good for the group. But in the case of a single talented unicorn who is inclined to write well-architected code, a group will inhibit that, as each individual pulls in different directions.

bruce511 4y ago

Obviously experience will vary from person to person. But your point is well made. The quality of the code depends a lot on the quality of the programmer. Better programmers write better code. Of course very few of us are great programmers on day 1. we learn and get better. I'm spending a reasonable amount of my time now re-writing code I built 25 years ago. Equally, we grow better, and learn faster, when we get feedback. All too often the lone programmer is not reading code written by others, and is not getting feedback on his own code. So growth is slowed, or in some cases stopped for decades. Bad habits from 20 years ago still exist because there's no-one to rail against them. So yes, lone programmers can be great, especially if they are outstanding to begin with. But the vast majority are mediocre and need the assistance of peers, and seniors to grow. On the other hand those that grow up under seniors with bad habits, who _enforce_ those habits, are screwed.

avgDev 4y ago
I have been a lone programmer for a few years. Whenever, I'm doing bug fixes I dive deeper into "how someone else would approach this". It is actually quite easy to keep improving on your own. I read books on refactoring, clean architecture, etc. as part of my daily routine. The time not spent debating with another dev is spent learning. I guess as a lone dev it is easier to do no self-improvement and keep apps chugging along until something terrible happens.

ricardobayes 4y ago

This works if there's no time pressure involved.

klabb3 4y ago
This is key. Good projects are based on good ideas. Good ideas take a lot of time to develop, and often involves back and forth, iterations, friction and failure. If you have a good data model and technical architecture, the code almost becomes good on its own, even if it’s implemented by more people that understand the model. The problem is that it’s irrational to spend that amount of time, and it’s directly opposed to incrementalist mainstream paradigms of software development. It’s the process that almost has to happen outside of companies, because management would never let projects be executed in such a way. But when there are personal drivers (either by the creative aesthetic types or sometimes the hacker tinkerer types) you can sometimes, depending on the domain of the problem, get some really coherent systems that make people go “this makes sense, why would it be done any other way?”. To me, the story of git has many of those traits, especially when comparing to what existed before.

danjac 4y ago

As a sole dev you are also pushed towards simplicity, because your time and scope is so limited. So a larger team might build some intricate DDD-microservices architecture with a services bus and a complex SPA frontend because, why not? That's what everyone else does. As a single developer managing multiple microservices or separate backend/frontend codebases is a lot of overhead (unless it's a learning project). You have to do the simplest thing that will work. So if you can get away with server-side rendering, do that. A monolith makes more sense when you don't have multiple pizza teams, and so on.

robertlagrant 4y ago
This is true - you may (possibly) end up in a scalability dead end, but you will likely have been far, far more efficient along the way.
- TeMPOraL 4y ago
  I think the only scalability dead end you'll end up in is people-related. That is, you won't be able to scale further because it would require using patterns/solutions that balloon the complexity so much you now need a team to keep track of it, and/or it would require more money than you can manage handling on your own (e.g. you would need to turn your project into an actual business in order to fund it further - at which point you need to start hiring people, to either do the businessy bits for you, or the technical bits, whichever your preference).
fhd2 4y ago
Or in other words: Conway's Law makes single developer code bases less complex, since there's no communication and responsibility boundaries reflected in it. That said, I've seen a lot of small teams create a ludicrous amount of microservices. One per independently working team is my usual heuristic.
- danjac 4y ago
  There is a problem in the tech industry where people's pattern matching isn't terribly good. They will have worked for a big company, or have read literature produced by people working for big companies, and concluded that "microservices" (to pick one pattern) are the best practice, because it worked for $BIGCORP, or they expect to be $BIGCORP 2.0 at some point, so why not be ready for that? But, as you point out, microservices are the result of Conway's Law and shipping your org chart, not necessarily the best way to build software all other things being equal. If your org chart fits comfortably inside a broom closet, then maybe you're not quite ready yet for microservices.

hyperpape 4y ago

One way to put it is in that single developer code will have more variance, when compared to code developed by a group. This variance has a range of effects, and will sometimes be positive, sometimes negative. Certain idiosyncracies are unlikely to survive work in a group, which can be good for the group. But in the case of a single talented unicorn who is inclined to write well-architected code, a group will inhibit that, as each individual pulls in different directions.