5 ms·

Nice post! I worked in a few big and small companies, and from I can see software companies with more then ~40-50 devs don't scale well (I only talk about about

Nice post! I worked in a few big and small companies, and from I can see software companies with more then ~40-50 devs don't scale well (I only talk about about single-ish product software companies here). The reason for this is in my opinion is absence of financial liability of devs: if you're a dev in a company with 500 other devs - most likely you have zero financial liability to produce great code, on other hand you have all time in the world to create job security code around you. Also if there is 500 devs on one project, most likely one will see a lot of infrastructure just to get this devs busy with something. This could be seen in companies were one department creates "the framework", and others departments create "features" based on this framework. In this case there is no "market" of frameworks - you basically stuck with it, and "the framework" has zero market competition. Compare it to normal market of middleware - if your framework is bad, I'll just go to your competitor. Free market is much healthier situation in my opinion (could be a strawman argument though). I am not wise enough to say that creating internal competition inside one company is always good thing, though financial contracts make a healthier political discussions.

emodendroket 9y ago
I don't believe job security code really works. If they're in a place where they're not paying any attention to you committing awful code why would they care when developers tell them that only you can work on your code?
- humanrebar 9y ago
  The job security comes when you write great code but awful designs and architectures. The resulting objections are more abstract and harder for project managers to really understand. Or they'll understand the objections but not know how to weight their severity.
  - emodendroket 9y ago
    They'll just ignore them and do what they please, is where I'm going with this.
    - dmytroi 9y ago
      Yes, but it's not as obvious as it sounds. For example let's say we have dev A and dev B and we give them same task. Dev A solves the task in such way that we don't need to come back to the solution at all, it "just works". While dev B solves it in such way that now we need 1+ devs maintaining a solution full time. Any solution that needs to be maintained full time is a form of job security. Sometimes it is needed (like placing a small team on devops), sometimes it is not (like in-house full time development of dashboard frameworks).

emodendroket 9y ago

I don't believe job security code really works. If they're in a place where they're not paying any attention to you committing awful code why would they care when developers tell them that only you can work on your code?

humanrebar 9y ago
The job security comes when you write great code but awful designs and architectures. The resulting objections are more abstract and harder for project managers to really understand. Or they'll understand the objections but not know how to weight their severity.
- emodendroket 9y ago
  They'll just ignore them and do what they please, is where I'm going with this.
  - dmytroi 9y ago
    Yes, but it's not as obvious as it sounds. For example let's say we have dev A and dev B and we give them same task. Dev A solves the task in such way that we don't need to come back to the solution at all, it "just works". While dev B solves it in such way that now we need 1+ devs maintaining a solution full time. Any solution that needs to be maintained full time is a form of job security. Sometimes it is needed (like placing a small team on devops), sometimes it is not (like in-house full time development of dashboard frameworks).