4 ms·

>Software is not a contest in being liberal and tolerant. There are methods and techniques that are objectively better than others in reaching most of the goals

>Software is not a contest in being liberal and tolerant. There are methods and techniques that are objectively better than others in reaching most of the goals that are important. Oh please. Dogmatists make the worst software developers. The "objectively better" criteria is highly situational and not nearly as clear cut as it looks most of the time. There are plenty of methods and techniques in software that work well for some goals and absolutely suck in others and it's very often not obvious that something that is working well or badly for you is doing so mostly because of your situation. My favorite example of this is microservices - which apparently worked really well for Martin Fowler once or twice (and I'm 90% sure he didn't understand why) and then when he promoted it, it got applied dogmatically by teams all over the world in situations where it was manifestly an idiotic idea. The same goes for most hot-button issues - type systems, functional programming, nosql, etc.

jstimpfle 8y ago
Believe me, I know that microservices suck for almost anything, because of the added software and infrastructure management complexity. And so it is with most other hyped technologies. The complexity and loss of control is very rarely worth it. I'm not a dogmatist, but have seriously tried many different approaches. And that's why I do mostly C (well, not for web applications, which I try to avoid as well :>) with only very simple data structures, and I love it, and it works, and it's maintainable, modular, and very performant. Although I know that C has flaws - I have been trying to find ways to improve (and failed so far).
- crdoconnor 8y ago
  >Believe me, I know that microservices suck for almost anything woosh They work really well in large organizational environments where inter-team coordination costs are very high and language flexibility is valuable. Where these benefits outweigh the additional infrastructure headaches it works very well. I've likewise worked in environments where they were a terrible idea (e.g. startup team of six). Like you, I used to be dogmatically anti-microservice. I was wrong.
  - jstimpfle 8y ago
    Yes - that may be, so I'm sorry for omitting the context that I don't work in large teams where you can throw lots of money and developers at problems. (I think that's a sad state of affairs, though). Again, I'm not dogmatic, but have actually tried it, and I know (and have described in my comment) the problems they bring.
- ahmedalsudani 8y ago
  It seems to me that you are young and just starting your career. It’s ok to only want to do certain kinds of work (for example C code that runs close to the metal and that is performant and easy to reason about). Other people in the world though enjoy doing different kinds of work and going about it in different ways. My advice to you is to be humble and watch people as if they had something to teach you. Whether they are doing scrum, waterfall, using this or that language or architecture, there’s always a ton of things you can learn by watching how someone works. If you pay closer attention, you will see value in what other people are doing and be able to benefit from what they have discovered.
  - deleted 8y ago
    [deleted]
barrkel 8y ago
Very true. There's an alchemy between the software you already have, the tools and technologies your team are familiar with, the problem domain you have, and the solution you implement. There are multiple stable equilibria, multiple local optima. In a more complex environment, microservices can let different teams find local optima better suited to their combination of factors. I'd still be suspicious of people who start out saying they're going to implement a microservice architecture (especially greenfield) without having an understanding of why, though.
- crdoconnor 8y ago
  I'm suspicious of anybody who starts out with a clear picture in their head of "what the architecture should look like". I've almost always found that the earlier on in the process I made hard-to-reverse architectural decisions, the worse the architecture ended up being. The more the architecture came about as a series of gradual, iterative refactors that took in to account the various trade offs that became evident, the better it ended up being.
  - pas 8y ago
    I'm an anonymous architecture astronaut, so usually I have those "should look like" high-level pictures in my head. But that's just a fucking picture. A plan. That usually does not survive contact with the changing requirements and implementation reality. Anyone incapable of admitting that there will be changes should be taken upstate to a nice farm, then shot behind the barn. Usually these people are on the client's team. :(

jstimpfle 8y ago

Believe me, I know that microservices suck for almost anything, because of the added software and infrastructure management complexity. And so it is with most other hyped technologies. The complexity and loss of control is very rarely worth it. I'm not a dogmatist, but have seriously tried many different approaches. And that's why I do mostly C (well, not for web applications, which I try to avoid as well :>) with only very simple data structures, and I love it, and it works, and it's maintainable, modular, and very performant. Although I know that C has flaws - I have been trying to find ways to improve (and failed so far).

crdoconnor 8y ago
>Believe me, I know that microservices suck for almost anything woosh They work really well in large organizational environments where inter-team coordination costs are very high and language flexibility is valuable. Where these benefits outweigh the additional infrastructure headaches it works very well. I've likewise worked in environments where they were a terrible idea (e.g. startup team of six). Like you, I used to be dogmatically anti-microservice. I was wrong.
- jstimpfle 8y ago
  Yes - that may be, so I'm sorry for omitting the context that I don't work in large teams where you can throw lots of money and developers at problems. (I think that's a sad state of affairs, though). Again, I'm not dogmatic, but have actually tried it, and I know (and have described in my comment) the problems they bring.
ahmedalsudani 8y ago
It seems to me that you are young and just starting your career. It’s ok to only want to do certain kinds of work (for example C code that runs close to the metal and that is performant and easy to reason about). Other people in the world though enjoy doing different kinds of work and going about it in different ways. My advice to you is to be humble and watch people as if they had something to teach you. Whether they are doing scrum, waterfall, using this or that language or architecture, there’s always a ton of things you can learn by watching how someone works. If you pay closer attention, you will see value in what other people are doing and be able to benefit from what they have discovered.
- deleted 8y ago
  [deleted]

barrkel 8y ago

Very true. There's an alchemy between the software you already have, the tools and technologies your team are familiar with, the problem domain you have, and the solution you implement. There are multiple stable equilibria, multiple local optima. In a more complex environment, microservices can let different teams find local optima better suited to their combination of factors. I'd still be suspicious of people who start out saying they're going to implement a microservice architecture (especially greenfield) without having an understanding of why, though.

crdoconnor 8y ago
I'm suspicious of anybody who starts out with a clear picture in their head of "what the architecture should look like". I've almost always found that the earlier on in the process I made hard-to-reverse architectural decisions, the worse the architecture ended up being. The more the architecture came about as a series of gradual, iterative refactors that took in to account the various trade offs that became evident, the better it ended up being.
- pas 8y ago
  I'm an anonymous architecture astronaut, so usually I have those "should look like" high-level pictures in my head. But that's just a fucking picture. A plan. That usually does not survive contact with the changing requirements and implementation reality. Anyone incapable of admitting that there will be changes should be taken upstate to a nice farm, then shot behind the barn. Usually these people are on the client's team. :(