I don't know if I buy the idea that using the vendor parts as examples given in the article align with the analogy.
Architecture is not that; MEP trades aren't architecture. If she used prefabbed wall assemblies or didn't do her own structural for critical parts the analogy would hold (I so not know if she did or did not either way). Plumbing is a completely separate trade the way trading stocks is separate from computing; it just happens to live in the house.
> Ruben, Lou’s boyfriend, playfully pinches her, then playfully punches her, then seriously pinches her, then seriously punches her, and so on. Each time she convinces herself that her domestic abuse line wasn’t crossed, ultimately leading to her getting full-on abused.
If I start by not liking playful pinches and said so, you should stop doing them. That is the initial situation. But in this (made up) story, she moves then line and tolerates them, because he is not stopping and she does not see it as a red flag.
Presumably the usage of humans stays relatively constant and costs for infrastructure increase 5 to 10x.
Just means you just pay out 1/10th as much per traffic; you already had some estimator for signal to noise measuring buying likelihood. It's just gonna drop
I got sketches from architects probably weekly for a ~500 unit hotel (I'm on the electrician end). It worked out okay, but it didn't substitute for the BIM later
It's great to assert "we need" but I implore you to consider the downsides first.
I work for an electrical contractor and I don't think being annoyed by shitty UI is nearly the same problem as electrical fires. Why govern the whole set of software with 1 set of rules?
Software isn't safety critical until it is, but we already have code to regulate software on electrical equipment, planes, etc. Why do you recommend software have a code? I'd much rather each individual thing that's safety critical have regulations around software in place than have to learn a 4000 page manual that changes every time you cross a jurisdiction, where enforcement varies, etc.
Software engineers can't even agree on best practices as is.
Imo, put the code around the safety critical thing (e.g. cars, planes, buildings). Restricting "critical" software will only get abused the way essential workers did during covid.
Also keep in mind the way buulding code gets enforced: you get an inspection upon completion or milestones. Software has a tendency to evolve and need maintenance or add features after; I don't want to trust this to a bureacrat. I don't like google or apple getting involved on "their platform" and I certainly don't want an incompetent government getting involved.
Before we have a software code, let's make and adopt some guidelines we can agree to. In construction, plenty of builders have their own sets of internal rules that are de facto codes. When one of those gets popular enough for life safety software, let's consider pushing for that.
The solar power industry was born, rolled out products, learned from their failures, and implemented electrical and building code changes, in a third of the time that the software industry has existed.
We already know what the failures are. We already know what the solutions are. We know it because people have been born and died in the span of time we have been dealing with these same problems. There is no need to assemble guidelines (that no company would follow anyway without being forced to).
> Software engineers can't even agree on best practices as is.
I'm not talking about "best practice"; I'm talking about, before you ship a build to customers, you must at least run it once to look for errors. This is kid stuff, yet the companies don't do it, and subsequently half the flights in the USA are delayed for weeks. There is no need to argue about this, there is no question that there are basic practices that should be considered malpractice not to do. We must make this law or they will continue to disregard these basic practices and we will continue to suffer for it.
> Software has a tendency to evolve and need maintenance or add features after
That is a flaw in business practice, it has nothing to do with software itself. I can run a suite of Perl programs today that I wrote 20 years ago, and they run flawlessly. No need for maintenance, it just works. The reason is, we just happened to treat this one language as something that should not break, and should last a long time. No reason we couldn't treat other software the same way. The fact that other software doesn't is a choice by a lazy industry and uncaring business models, and this choice needs to be challenged, the way every industry has had to be challenged by codes (the reason codes exist is industry cannot be trusted to "do the right thing", they need to be forced).
But despite this, codes change all the time. The electrical code changes as solar progresses. Building codes change as we learn new things or new materials are introduced. The codes do change slowly, precisely so the work is well thought-out, coordinated, and safe, which nobody can say about modern software. The time for move fast and break things needs to end.
>That is a flaw in business practice, it has nothing to do with software itself
I don't think it's a flaw and throwing this away isn't worth a quarter of the hassle that comes with any enforcment implementation I can conceive of. Please think about what testing, safety, security is "enough", how you test it, and if it's worth the tradeoffs.
Who is at fault for code violations? The scope of software is generally too big that prearchitected designs don't work and you must assign life safety faults to a PE. Software doesn't work like that, it's not singularly done. You shouldn't need to file a permit for expansion to add a feature or plug a security hole.
You point to solar, but solar is less complicated than the things most of this website would deride as simple in software. The electrical codes. It has hardly changed at all since it's inception, and only inspired a handful (<12) of changes since the 2008 NEC. Most jurisdictions only update every 2 cycles or so, so we're talking 3 updates.
Move fast and break things is fine when it's okay to break things; software is fundamentally different than physical infrastructure and you paint with really broad strokes here when you just assert "need" and "right".
I work with building code every day and I fundamentally disagree that writing a "critical software code" would be net beneficial.
> Software doesn't work like that, it's not singularly done.
This is definitely a business practice problem, and not some intrinsic quality of software.
And even if your business decides that software is never done, nothing stops you from getting a particular build inspected and certified. It's physically possible. The problems are mostly cultural and in other areas: Governments are generally hesitant to regulate business. Software companies lobby extensively to keep it that way. Vendors and customers are generally not willing to pay the increased cost of software inspections. Developers don't like the idea of being held to a quality standard.
most subagent tool have in the tool the sub agent calls to notify completion the message to return and a good documentation about how to return things, so the orchesrtator can orchestrate.
the harness that don't have that mechanism can have it augmented by prompt
roo code has a good harness for that (but terrible default prompts for the agents), kiro does that well too, gemini has a few misses as it just send off things without really caring of returns by default (albeit very model dependent), meanwhile jules using the same models has a good harness with a good feedback loop.
Architecture is not that; MEP trades aren't architecture. If she used prefabbed wall assemblies or didn't do her own structural for critical parts the analogy would hold (I so not know if she did or did not either way). Plumbing is a completely separate trade the way trading stocks is separate from computing; it just happens to live in the house.
reply