51–60 of 65 posts
I like to think of it in algorithmical terms. Maintaining the code is O(n) on the size of the code
Think it should be logarithmic (n log(n)) or polynomial (n^2)
(Actually, n log(n) + a constant offset; i.e. partitioning the code has its limits where it becomes detrimental.)
Things break down and things eventually need to be replaced. This has been a fact of life since time immemorial. I do tire of programmers acting as if the necessity of maintenance is some novel and unexpected problem, unique to software development, presented with hyperbolic titles like "software is drowning the world". Is physical infrastructure "drowning the world" because it needs to be maintained?
To be fair, I don't agree with this point of view at all. Things in the physical world break down beacuse they are made of matter, and the entire concept of "working" is a very simplified modeling of their behaviour that doesn't include second-order effects like tear,consumption of materials etc. Code, on the other hand, is a social constrution but entirely confined in an abstract and mathematical world. The _only_ r…
Social constructs are not immutable any more than physical ones. They're more likely to change, from what I've seen.
Making software is about groups of people interacting, side effects of the software, and lossy interfaces more than it is about mathematics.
Things break down and things eventually need to be replaced. This has been a fact of life since time immemorial. I do tire of programmers acting as if the necessity of maintenance is some novel and unexpected problem, unique to software development, presented with hyperbolic titles like "software is drowning the world". Is physical infrastructure "drowning the world" because it needs to be maintained?
To be fair, I don't agree with this point of view at all. Things in the physical world break down beacuse they are made of matter, and the entire concept of "working" is a very simplified modeling of their behaviour that doesn't include second-order effects like tear,consumption of materials etc. Code, on the other hand, is a social constrution but entirely confined in an abstract and mathematical world. The _only_ r…
Hardware standards shift because of an Apple PR camopaign. We stopped using zeppelins only after one disaster of several dozens made very public by live radio coverage. Non-Sufficiently standardized rockets explode because countries can't pick a measurement system. The auto industry in a country changes overnight because a dictator decides that the roadside to travel on shall be switched on a whim.
Just like software, infrastructure/hardware/whatever is an unfathomably complex web made from science, faith, half-knowledge, geopolitics, coincidences, rules, dick moves, physics and random tweets.
I don't think we are winning anything by trying to lift software onto some kind of pedestal of specialness in every regard...
Testing / Certification: A table lamp will be UL/CE approved. This means it will be tested in such a manner that normal use and abuse will not cause unexpected side effects. Knocking a UL approved lamp off a table will not cause your house to get burned down. A light bulb of rated capacity will not cause a short circuit. Normal wear and tear will not cause it to become unsafe.
Outlets: A table lamp plugs into an outlet, of a standard size and characteristics. The outlets are a standard interface that is often nation or region wide. The voltage and current that can be delivered through an outlet are standardized, as is the nature of the loads which may be plugged into it. The outlet itself, and the housing, and wiring are well regulated.
The outlet is connected to a circuit, and a circuit breaker (or fuse). These devices completely and permanently interrupt the delivery of voltage for a number of standard conditions, including over-current, and also ground faults.
The circuit breaker, or fuse socket, is part of a standard and well understood panel, which is designed to allow a variety of options in deployment, with electricians able to configure them in a wide variety of applications. Yet, the user of a breaker of fuse panel is protected from the voltages and power inside, and given a standard and easy to understand model of how power is distributed, and controlled. In fact, some advanced users can use the panel to disable part of their local power network to allow maintenance and modification in a safe manner.
Breakers and fuse panels allow for lock out, which will physically prevent the reapplication of power, while maintenance is ongoing.
Power feeds include metering, and themselves are driven from a circuit, and the system is designed in much the same way as the residential and business circuits, but on a larger scale.
Not only all of those are true, but there is more
Circuit breakers and fuses on devices, etc.. are all designed to be coordinated. The smallest fuse/breaker in the chain from source to load should always trip first. This prevents a scenario such as the one where a person plugging a defective toaster into an outlet brings down the entire power grid.
Circuits and power routing have well separated areas of concern. There is no way that a power system problem can directly cause problems with the sewers or other infrastructure, other than failing to deliver power.
Our software infrastructure lacks all of this sophistication and standardization. You can plug in a fan made 100 years ago into a modern outlet, and it will work. You can't even run an MS-DOS program from the 1980s without resorting to an emulation layer.
You can know that same fan will not cause Russian bots to be able to control the power grid. Nothing plugged into an outlet can ever give you control over the grid. The same is not true of software, no matter how carefully constructed. We're still at the stage where a bad program can take out its host operating system, and then the network its on.
To say we need more skilled programmers, better aware of the security implications of their work, is to insist that we could run a power grid without circuit breakers in every home.
The operating system has the job of protecting the network and its users and applications from each other. There is no equivalent to circuits and breakers. You can't run a program, and know that it will only consume X amount of CPU, network I/O, or RAM, unlike the outlet limited to 15 amps.
You can't be sure that a program won't have side effects. Plugging in a bad toaster in the kitchen shouldn't effect a circuit in the garage. The damage should be limited by default. None of our Operating Systems do that.
Computation lacks maturity, especially our operating systems. We have no stable standards for anything important.
That, in my opinion.. is the real root issue.
Earlier quoted context omitted.
How about something new: release only backward-compatible updates unless absolutely necessary.
For real. If its not acting the same, then its not the same thing, give it a different name and release your 0.1. I guess maybe we run out of namespace with this methodology? Suddenly we end up with software named axsladkjfaksldjf, and then hackers start camping on axsladejfaksldjf
This is one of the reasons why statically typed languages have a big advantage when it comes to maintenance. Take Scala for example. There is now mature tooling for keeping your dependencies / libraries up-to-date automatically, using automatic migration-scripts (must be provided by the library author of course). See here: https://github.com/scala-steward-org/scala-steward/blob/mast... The difficult part here is of c…
That was basically my main reason to learn Rust (okay, mega-speed is another but it wasn't the first): no matter the syntax, no matter how hard it is to learn in general, no matter how hard to learn and use all the idioms is, you have a very strict language that makes it that much easier to automatically refactor. ...Or at least I hope that will be the case in the future. But like you, I believe it's much better posi…
Earlier quoted context omitted.
That was basically my main reason to learn Rust (okay, mega-speed is another but it wasn't the first): no matter the syntax, no matter how hard it is to learn in general, no matter how hard to learn and use all the idioms is, you have a very strict language that makes it that much easier to automatically refactor. ...Or at least I hope that will be the case in the future. But like you, I believe it's much better posi…
I'd say it's harder to refactor because you can only refactor to correct programs. Other, more lax languages are easier to refactor to a wrong new state.
Earlier quoted context omitted.
I'd say it's harder to refactor because you can only refactor to correct programs. Other, more lax languages are easier to refactor to a wrong new state.
But isn't that the goal? Namely to automatically (without human interference) refactor to a correct program?
Things break down and things eventually need to be replaced. This has been a fact of life since time immemorial. I do tire of programmers acting as if the necessity of maintenance is some novel and unexpected problem, unique to software development, presented with hyperbolic titles like "software is drowning the world". Is physical infrastructure "drowning the world" because it needs to be maintained?
> Things break down and things eventually need to be replaced. This has been a fact of life since time immemorial. That sounds a bit broad. In the general aviation world, engine designs from the 60's are still in widespread use.
> Every time you decide to solve a problem with code, you are committing part of your future capacity to maintaining and operating that code. Software is never done. I am clipping this for use in future internal discussions. I have trouble communicating this point, this sentence does so concisely.
> Every time you decide to solve a problem with code, you are committing part of your future capacity to maintaining and operating that code. Software is never done. Notice that this includes using code written by other people (e.g., dependencies).
But using off-the-shelf software that you simply install is certainly one form of "using code written by other people." If it is popular software offered by a stable company, I would always estimate it's likely future cost as less than anything written in-house. (Which doesn't mean it's risk free, the software can become unsupported or change in backwards incompat ways incurring costs. You can get unlucky. But I'm almost always going to advise that it's the safer choice with regard to future costs than in-house development).
If we're talking about in-house software projects to begin with, as you probably intended, but evaluating using a third-party dependency vs writing the functionality in-house, figuring out which of those paths will be likely to end up lower-cost is not at all easy to do, and dependent on a lot of context.
But certainly in all cases, not having any software will be lower-maintenance-cost than having any software. Well, at least lower software maintenance cost. :)