41–50 of 195 posts
Whether it is a function, class, module, application or service I think there is one word for it - encapsulation.
Earlier quoted context omitted.
We might not be able to quantitatively measure it but we can run studies to evaluate what individuals and teams can handle. Human factors people do this and it’s a sub field in industrial engineering. The military runs these studies and I’d imagine air traffic controllers do them as well, etc. You sometimes get really surprising results.
That's something I've noticed: the way we treat systems developed to work on data is _completely_ different from systems developed to work on, idk, oil. You can build data refineries (ETF) same as an oil refinery. The difference is, the engineers who build the oil refinery create manuals and standard operating procedures to operate the refinery, because if they don't, then the new board operator will press the wrong…
I used to complain about overly complex software, until I realized the problems themselves were very complex. There was/is no way around complexity, and pushing for early simplicity causes more problems than it solves. People need to accept that encoding 1,000 if else statements (software engineering) will be complex no matter how you spin it. Just design the software upfront for what you will need, like a profession…
> Just design the software upfront for what you will need That assumes that you know upfront what you will need and what software design will best meet the need. Sometimes that is the case, but many times it isn't. Different strategies are needed to deal with the latter case.
The moment you adopt service based teams with service based managers, say goodbye to engineers caring about working product. Say hello to cross team meetings and project management every time you want to ship a feature. It's pure vanity for a startup to think they will become the next AWS by adopting hard service-based contracts between teams.
This strikes me as overly cynical. My current job is working with around 20 other engineers on an extremely bloated and coupled monolith. I'd love to be able to separate myself and my team from others by an agreed-upon interface. Yes, "agreed-upon" is certainly doing some heavy lifting there, but I don't think it's realistic to expect that > cross team meetings and project management every time you want to ship a fea…
Don't doubt it, but that is what the grandparent was going to - you don't want to be held accountable for the success of the overall product, you want a defined contract that you maintain and the value-add of that is someone else's problem.
The dysfunction of a business is made up of individuals doing what makes the most sense for them locally. It isn't unreasonable to want microservices, it just happens that the incentives that make developers like microservices also tend towards systems that lack accountability for achieving system-level outcomes.
Earlier quoted context omitted.
That's something I've noticed: the way we treat systems developed to work on data is _completely_ different from systems developed to work on, idk, oil. You can build data refineries (ETF) same as an oil refinery. The difference is, the engineers who build the oil refinery create manuals and standard operating procedures to operate the refinery, because if they don't, then the new board operator will press the wrong…
Oil refineries don't have backup restore points.
Think sensor data and the sensor is a vital signs monitor in a hospital. The service that reads its output and stores it glitches out due to some sort of misclick by a user. It distorts the fact that the patient has an arrhythmia. Or a service that reads off the medication dosages for a patient for a pharmacist is stuck on a single message.
It's always the product. It comes first. Then the business. If you're lucky you may become a pawn in a larger battle among giants and you'll get acquired before you attempt to make any profit.
If you end up in a place where your chosen architecture is no longer capable of supporting your scale - that's a happy place that very few teams get to experience. It means you've survived.
Given that, whatever allows you to quickly get things in the hands of real customers (which depends quite heavily on what the actual product is) is the best architecture.
We've hired some experienced engineers from giga-corp FAANG etc into tiny startups. The transition is hard, because there the opposite is true. You have a business already, and you have a well-defined goal you need to achieve with multi-year roadmaps etc. There, yeah you should probably decide on architecture first.
The moment you adopt service based teams with service based managers, say goodbye to engineers caring about working product. Say hello to cross team meetings and project management every time you want to ship a feature. It's pure vanity for a startup to think they will become the next AWS by adopting hard service-based contracts between teams.
I appreciate you qualified as for startups, but worked with plenty of former startups/scaleups that were bogging down rapidly due to infra or scaling issues. Since they were feature factories, no team or PMs were measured or cared about overall system health. This includes "majestic monolith" cough stacks with Rails.
Adding some services were clear wins and needed for things like external APIs, Auth, reporting, etc. - but this is a far cry from AWS microservice hell for simple UI/CRUD features.
Earlier quoted context omitted.
> Just design the software upfront for what you will need That assumes that you know upfront what you will need and what software design will best meet the need. Sometimes that is the case, but many times it isn't. Different strategies are needed to deal with the latter case.
If you need flexibility for unknowns, design for that. Specialize as the requirements become more clear.
I dunno, I think software engineers have neglected soft skills for too long.
"Philosophy X always leads to Y outcome."
"Framework Z does Q."
I bet a lot of software engineers are just bad with people. Coordinating a dozen teams takes work, but people do it all the time successfully.
I don't think the frameworks are as important as figuring out an approach that works for the people involved.
I've read a lot of these arguments. I dunno, I think software engineers have neglected soft skills for too long. "Philosophy X always leads to Y outcome." "Framework Z does Q." I bet a lot of software engineers are just bad with people. Coordinating a dozen teams takes work, but people do it all the time successfully. I don't think the frameworks are as important as figuring out an approach that works for the people…
Maybe that's a typical progression in most software careers, but I wouldn't have believed I'd be here 10 years ago, or maybe even 5. I was always very technical (and I still love that side of things). Now I see the people side of things as far more important and interesting.