Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@magicMirror If requirements for bridges and other buildings were changing on weekly basis, nothing would get built.
That is the problem too, and the problem you brought up has some of its roots in it. -
We're not building. We're designing. You design a car, then give that design to a factory. The factory makes what you design.
People think of software engineering as manufacture because we're making the thing people use, there isn't a manufacturing stage because that's called "copy from one computer to another".
How long was it before cars had seat belts? 60 years? How old is software engineering? About that. You wanna compare us to architecture, we're still only able to design 2 story buildings, but we're already trying to design skyscrapers anyway. -
From the same people that brought you "taking people off a project is more likely to speed up progress than adding people".
https://t.co/3A6VwJxBtZ -
@magicMirror this quote is yours ?
-
@impune-pl i agree. but materials are evolving too. just not so fast. and also even if they could, we have no gain from it.
With the same mindset, we could stuck at cobol like many banks, but on the same time, C remains the king of OS system programming. So, some "materials" on programming are still better than others, and it would be nice if we could lead them to perfection than changing them all the time.
I wish i could be that smart to give work on it . I am just a passenger. -
@atheist i think the demand of the world seduced us. We could be more like priests in ancient time, giving the direction as we are holding the craft. But we are thirsty of approval weak mind nerds.
-
@gatoMalicioso I think we're slightly more at the behest of market powers. Because manufacturing is so fast, powers turn to speeding up design. Toyota could literally turn "stuff in the ground" into a car in 3 days. That's the very origin of agile, Toyota. So we try to make design faster. More agile. But we don't necessarily have a clear path from A to B, from ideas in our heads to a product.
In the mix, we lost some of the good practices. Like updates, "ABI" compatibility and "API" compatibility are 2 very different things, in theory you should almost never break ABI compatibility with updates, but languages have lost this concept to enable easier access to design.
We also don't push back enough. The point of agile is to change the way you work to make it better. Most companies "doing agile" are actually just assigning points to tasks, then using those points to track how productive people are, and to put pressure on them to be more productive. I've literally worked at a company where the management was pushing us to meet a deadline, do "more points", and so every ticket was "completed", then a new one added to write tests. That's not "agile". That's stupid. I didn't stay long. -
Software is fractally hard to reason about. And that is, what almost nobody gets.
And still, a lot of developers just refuse to automate one of the two easiest things to automate:
Either the don't use a language ensuring at compile time that there are no memory-access-related bugs.
Or they use a language with a crippled type system, so they have to sprinkle value checks all over their code.
Even a web frontend dev can make his life so much easier by configuring Typescript to not make anything nullable by default (also avoid "any")... -
@Oktokolo i did not understand your first example (compile time)
-
@gatoMalicioso OFC not.
Can't attribute it correctly, so just google the origins of it. -
@gatoMalicioso
Compile time as when the code is compiled. Everything checked by the compiler is known for sure at runtime. So chosing a compiled language (and/or using a static analyzer as they have gotten pretty good too) catches some bugs that would otherwise might or might not be found later (maybe by someone exploiting them for their profit and/or your loss).
For the term itself:
https://stackoverflow.com/questions...
A philosophical question about maintenance/updating.
There is no need to repeat the reasons we need to update our dependencies and our code. We know them/ especially regarding the security issues.
The real question is , "is that indicates a failure of automation"?
When i started thinking about code, and when also was a kid and saw all these sci fi universes with robots etc, the obvious thing was that you build an automation to do the job without having to work with it anymore. There is no meaning on automate something that need constant work above it.
When you have a car, you usually do not upgrade it all the time, you do some things of maintance (oil, tires) but it keeps your work on it in a logical amount.
A better example is the abacus, a calculating device which you know it works as it works.
A promise of functional programming is that because you are based on algebraic principles you do not have to worry so much about your code, you know it will doing the logical thing it supposed to do.
Unix philosophy made software that has been "updated" so little compared to all these modern apps.
Coding, because of its changeable nature is the first victim of the humans nature unsatisfying.
Modern software industry has so much of techniques and principles (solid, liquid, patterns, testing that that the air is air) and still needs so many developers to work on a project.
I know that you will blame the market needs (you cannot understand the need from the start, you have to do it agile) but i think that this is also a part of a problem .
Old devices evolved at much more slow pace. Radio was radio, and still a radio do its basic functionality the same war (the upgrades were only some memory functionalities like save your beloved frequencies and screen messages).
Although all answers are valid, i still feel, that we have failed. We have failed so much. The dream of being a programmer is to build something, bring you money or satisfaction, and you are bored so you build something completely new.
question