161–170 of 304 posts
This is a problem I want to focus my life solving. I believe that software engineering can be made so simple and clear that it can be wielded by an extremely small team of engineers. I believe that there are finite and fundamental classes of problems, that underpin the vast majority of problems, that have a distinct visual representation, and that by representing these problems visually, you let your "visual coproces…
Earlier quoted context omitted.
I would disagree with that sentiment for every single item on that list. All those tools are amazing and have improved steadily over decades and I would absolutely put them in the “great engineering” category.
GNU utils are incredibly primitive and their text-driven APIs are fragile and cause tons of issues in shell scripting. I love Emacs, but it's a slow, crufty mess. Vim is a huge pile of code with a lot of complexity in its codebase and hilariously bad design decisions like VimScript. Apache is a mess from a security perspective (1.7k listed CVEs[1]), and still slower than Nginx. Want to guess at the amount of lost pro…
Earlier quoted context omitted.
> It mostly comes from businesses throwing a bunch of under-skilled labor at the problem, and demanding more and more too quickly. Even if you have plenty of skilled engineers, it doesn't mean that the business won't impose unrealistic timelines (and insist the timelines be met even if it means taking on loads of tech debt which never gets paid down) or change the requirements abruptly or even demand things that are…
Engineer induced complexity is also common. I've never heard about management pushing for a scalable, event-driven, microservice based architecture when a simple monolith serving a few thousand daily users would be just fine.
1. an engineer under management pressure couldn't easily take an expedient dependency on the private internals of another system
2. teams could deploy their changes on their own cadence, so they didn't feel additional pressure to squeeze poorly-conceived things into one less-frequent release (many frequent releases are theoretically possible for monoliths, but much rarer for pretty understandable reasons)
Moreover, reliability improves because of the aforementioned reduced complexity but also because the blast radius for a reliability issue is scoped to the service, and security improves for the same "blast radius" reason (an attacker who compromises a component can only access that component's secrets and can only talk to that component's collaborators).
My suspicion is that microservices work very well when an organization has a strong architecture/SRE capability irrespective of management or product development capabilities, whereas a monolith depends on all capabilities firing on all cylinders.
Earlier quoted context omitted.
I want to believe you, but there are just so many complicated problems IN REALITY that we have to model in software that I don't really see complexity going down. Just an example: around here, most people have a first (given) and a last (family) name. If I don't model that as separate, I have trouble interfacing with other software. If I do, I have trouble with people from other cultures that don't follow that conven…
> We haven't really found a way to reuse these among different technologies. Like, if you once figured out the perfect password reset workflow with Ruby on Rails, and your next job uses Python + Django, you're back to square one. C and C++ libraries with light language-specific wrappers largely serve this purpose, in practice. It's plausible that, say, a PHP postgres client lib and a Node postgres client lib will sha…
I feel like it's a bit backwards. The software complexity increases because people lack the patience to tackle the existing complexity, or learn why things are complex, and prefer to believe that it can be simple, or get job done somehow, and in order to do that, they (somewhat egoistically) go their own way, which actually - barring occasional good insight - mostly increases the total complexity. The same goes for s…
I believe many software developers often tend to write software which has precisely the segree of complexity they can just barely manage. There is not many people who have the guts to build a simple straightforward step for step script. Software developers that fall into love with the beauty of their own abstractions can be a real problem.
I don't think it's that easy. Building simple software is very hard, and often takes several iterations to ensure you even understand the problem. Most developers are under time pressure, and stop as soon as there's a working solution, even if it's more complex than it should be.
This "software grows too complex" is certainly a culture issue, and not a software problem. It mostly comes from businesses throwing a bunch of under-skilled labor at the problem, and demanding more and more too quickly. Of course it will outgrow the ability of that team to work with, reason about, keep clean, and extend. They will get frustrated and move on, and a new group comes in, re-writes it from scratch, and s…
I think nginx is a rewrite of apache, just as busybox is a rewrite of coreutils. Linux tends to rewrite itself but just keep the userspace ABI.
Earlier quoted context omitted.
Also, most of them have gotten a rewrite worth of upgrades during their life. The Linux kernel is a good example: most of the code you use today didn't exist in the kernel 15 years ago. A lot of code from back then still exists for compatibility purposes, but is rarely used in modern systems.
But that's an interesting facet in itself. The more common refrain you hear in corporate settings is "we need a ground-up rewrite" - how did these projects manage not to need that? I have my suspicions, but it's a very interesting question nonetheless.
Individual parts of Linux go through relatively frequent rewrites (eg filesystems), but not the overall framework.
I will tell you this. It's based on my 20+ years, 50 different teams and many hundreds, perhaps thousands of encounters with software developers. It's almost never the domain complexity that is high. Sending a rocket to Mars is complex. And perhaps complex every time. Dealing with people that has to work together can only be simplified when agreements are made and agreements are kept. Otherwise you cannot trust and h…
> Don't look into the future. Because you cannot. And you are both naive and arrogant if you believe you can. Deal with what is known now! NO! This mentality is short sighted by definition and leads to stagnation. It may work within large financially healthy companies that aren't trying to rock to the boat. Making assumptions about the future is incredibly important for us to move forward. But with these caveats: 1)…
But I believe the parent comment was talking about software abstractions. i.e., don't build abstractions because you might need them later. Instead, build the software in the simplest possible way to solve the problems it needs to handle now.
This is because you'll likely be wrong about your assumptions about which abstractions you'll need, and ripping those abstractions out is going to be more expensive than just modifying simple code to do new things.
Earlier quoted context omitted.
Engineer induced complexity is also common. I've never heard about management pushing for a scalable, event-driven, microservice based architecture when a simple monolith serving a few thousand daily users would be just fine.
Maybe. I've never worked in an organization where engineers were driving the complexity, nor have I worked in an organization where microservices introduced complexity (I've heard people complain in vague terms about microservices, but I don't relate to their experiences). However, I have worked in an organization that transitioned from monoliths to microservices, and the overall complexity was reduced because (I did…
So nice, working application after adding next 5,000 more lines here and there suddenly becomes too fragile to perform its main function.
Usual solution for such problems is composition/modularization. Software shall be made of simple but composable modules.
Like text editor (relatively simple) shall be composable with syntax analyzers to make IDE possible. The very same syntax analyzers should be usable as web server modules for the Web.
That dream requires design of (again) simple but powerful architectures of composition/modularization.
Seems like each generation of software philosophers approaching this task anew. Linux with its stdin/stdout modularization. MS Windows with OLE. COM and CORBA, and so on.
Probably it's time to evolve something like COM and CORBA into something new?