3 ms·

As other posters have said, I think there is somewhat too much nostalgia about how "easy" it was in the old days. I was reading about software dev in the 70s an

As other posters have said, I think there is somewhat too much nostalgia about how "easy" it was in the old days. I was reading about software dev in the 70s and it took like 4 years to write what we could do in a day today. Also, I think that relatively, we are still in the early days of software where lots of people are clamouring to invent the silver bullet to make it all work better, but after a bit longer, we will have more experience of what works and doesn't work and we will consign certain things to history. Think about what medicine was like in the first few centuries? Leeches, trepanning, toxic "medicines", they presumably had the same issues until they established a much better foundation of what works and what doesn't which has made medicine move on. We will keep some of our cool things but others (XML anyone!) will just die off as we realise they are a solution to a problem that most of us don't have.

v-erne 5y ago
>>Think about what medicine was like in the first few centuries ... I spend thinking about medicine quite a lot (health problems in my family run deep) and this does not give me great deal of hope for our industry at all. There is so much quackery everywhere - most of diagnostics is based on some magic guess work. If symptoms are non-specific than You are out of luck - You have to spend years visiting random doctors hoping that one of them will have fresh enough memory of some book that he read years ago to guess right. And even when the diagnosis is easy the therapy can be not that far away from leeches. Few years ago I had wart on my hand and dermatologist offered me three options: - freeze it to death - burn it to death with acid - cut it out If You look at this options closely they require some high tech to be possible but from medical point of view they are as primitive as leeches. I honestly belive that in 100 years time when nanorobots will be available to everyone the doctor will prescrabie therapy that is basically nanorobots attacking the wart with little flamethrowers.
fn1 5y ago
> We are still in the early days of software where lots of people are clamouring to invent the silver bullet to make it all work better [...] I have a feeling that (especially in devOps/kubernetes) often there is a wish to have a magic button/command that does everything. Like in a rube-goldberg machine. What is forgotten then is the cognitive overhead of templating YAML inside templating YAML which is needed for the magic-button to be configured. And if the buttons behaviour needs to be changed very few weeks, not much is gained.
rapjr9 5y ago
Using packages, frameworks, and libraries has made it easier to build complex applications and systems faster, but it has made maintaining and debugging them much more difficult. If you are using 10 libraries, each with 100,000 to 1,000,000 lines of code, interacting with an operating system and drivers that are another million lines of code, you can't possibly understand what it is all doing, even if you have all the source code. You don't have time to even read it all. Trying to debug something you don't understand turns into trail and error to find clues as to what is going wrong. Sometimes you never figure it out. Hopefully you find a workaround. My first experience of this was in writing a 3D visualization for evaluating an electronic warfare system which used a 3D library from a third party. My aircraft would always disappear after a few minutes. The people who wrote the 3D library couldn't help me. I couldn't figure it out since I didn't know what the 3D package was doing internally. However I found that popping up a helicopter at 2000 feet for a half second fixed the problem. So from that point on all demos would be disrupted once in a while due to a helicopter popping onto and off the screen. I eventually found a way to make the helicopter invisible. It was still being popped up, but nobody could see it. I suspect there is tons of software today that works because of hacks like this, which makes them very fragile and prone to break if you make changes, and makes them almost impossible to troubleshoot (in addition to the underlying complexity).

v-erne 5y ago

>>Think about what medicine was like in the first few centuries ... I spend thinking about medicine quite a lot (health problems in my family run deep) and this does not give me great deal of hope for our industry at all. There is so much quackery everywhere - most of diagnostics is based on some magic guess work. If symptoms are non-specific than You are out of luck - You have to spend years visiting random doctors hoping that one of them will have fresh enough memory of some book that he read years ago to guess right. And even when the diagnosis is easy the therapy can be not that far away from leeches. Few years ago I had wart on my hand and dermatologist offered me three options: - freeze it to death - burn it to death with acid - cut it out If You look at this options closely they require some high tech to be possible but from medical point of view they are as primitive as leeches. I honestly belive that in 100 years time when nanorobots will be available to everyone the doctor will prescrabie therapy that is basically nanorobots attacking the wart with little flamethrowers.

fn1 5y ago

> We are still in the early days of software where lots of people are clamouring to invent the silver bullet to make it all work better [...] I have a feeling that (especially in devOps/kubernetes) often there is a wish to have a magic button/command that does everything. Like in a rube-goldberg machine. What is forgotten then is the cognitive overhead of templating YAML inside templating YAML which is needed for the magic-button to be configured. And if the buttons behaviour needs to be changed very few weeks, not much is gained.

rapjr9 5y ago

Using packages, frameworks, and libraries has made it easier to build complex applications and systems faster, but it has made maintaining and debugging them much more difficult. If you are using 10 libraries, each with 100,000 to 1,000,000 lines of code, interacting with an operating system and drivers that are another million lines of code, you can't possibly understand what it is all doing, even if you have all the source code. You don't have time to even read it all. Trying to debug something you don't understand turns into trail and error to find clues as to what is going wrong. Sometimes you never figure it out. Hopefully you find a workaround. My first experience of this was in writing a 3D visualization for evaluating an electronic warfare system which used a 3D library from a third party. My aircraft would always disappear after a few minutes. The people who wrote the 3D library couldn't help me. I couldn't figure it out since I didn't know what the 3D package was doing internally. However I found that popping up a helicopter at 2000 feet for a half second fixed the problem. So from that point on all demos would be disrupted once in a while due to a helicopter popping onto and off the screen. I eventually found a way to make the helicopter invisible. It was still being popped up, but nobody could see it. I suspect there is tons of software today that works because of hacks like this, which makes them very fragile and prone to break if you make changes, and makes them almost impossible to troubleshoot (in addition to the underlying complexity).