3 ms·

The way I have thought about software's necessary complexity for a long time is by considering what software IS. Software, no matter what it does or how it is

The way I have thought about software's necessary complexity for a long time is by considering what software IS. Software, no matter what it does or how it is written, boils down to instructions and data that operate on transistor gates in a computers processor and memory. We must write code which orchestrates the flipping of millions or billions of switches, millions or billions of times a second, in exact perfect synchronicity. The machines these run on, if transistors are considered a 'part' are the most complex machines in terms of part count ever created by humanity, packing up to around a billion parts into about a square inch of space. Also, our software isn't the only thing running. It must coexist with an unknowable number of other pieces of software flipping the gates in unknowable ways. Also, we do not interact with the gates directly. We do so at a level which is many layers of abstraction removed from them, like building a car the size of North America from the moon with chopsticks long enough to reach. Oh, and if we, at that level of gates, get one thing out of sync or make a single mistake, it can effectively instantly cascade into taking the entire system down. So, yes, software is complex. And it will always remain complex. It is doing monstrously complex things under the hood, all abstractions are leaky, and we are definitely past the point at which one person can even reasonably understand the entire stack from transistors all the way up through OS, compiler, language, etc. We must accept this fact of complexity and formulate ways to deal with it, to contain it and reduce it when we can, but it will always be with us.

noir_lord 7y ago
> and we are definitely past the point at which one person can even reasonably understand the entire stack from transistors all the way up through OS, compiler, language, etc. We must accept this fact of complexity and formulate ways to deal with it, to contain it and reduce it when we can, but it will always be with us. Beautifully put and we definitely are, I think the trick now is knowing which bits of the layers underneath you need to know to interact with things well (in terms of your goal), I came up on computers in the 80's and used C and Pascal, those early experiences have been useful for 30 odd years because often I have a 'feel' for what the computer is doing underneath that younger (and really capable!) devs lack. Often when performance is really critical I'll go look in the source code for the tool to get a feel for what it is really doing (even though I haven't written C in a long time) which is regarded as voodoo. On the flip side of course is I can build things in an afternoon or a day or two that simply wouldn't have been possible with months or years of work and a dev team of dozens back then. My next side project is a tool for motorcyclists, you drop pins on a map where you are going to be at points in time and it then pulls the complete meterological data for those points and does some calculations (are the roads likely to be wet, icy, show the direction of the wind, show the windchill at 30mph, 40mph, 50mph etc) with the ability to set recurring routes and email you the day before something like "Tomorrow morning, there may be ice on the roads, wind chill will be 5C, feels like temperature at 40mph -2c, Sunny, low winter sun so wear your shades/visor" The data to do that didn't exist 30 years ago and the GIS tooling (I'm using open street maps) to process the entire UK would have cost millions.
dsego 7y ago
Have you seen the 30 million line problem* by Casey Muratori (of Handmade Hero fame)? There is an argument that a lot of today's complexity in software is an (unnecessary) byproduct of changes in hardware design. *https://youtu.be/kZRE7HIO3vk https://youtu.be/kZRE7HIO3vk

noir_lord 7y ago

> and we are definitely past the point at which one person can even reasonably understand the entire stack from transistors all the way up through OS, compiler, language, etc. We must accept this fact of complexity and formulate ways to deal with it, to contain it and reduce it when we can, but it will always be with us. Beautifully put and we definitely are, I think the trick now is knowing which bits of the layers underneath you need to know to interact with things well (in terms of your goal), I came up on computers in the 80's and used C and Pascal, those early experiences have been useful for 30 odd years because often I have a 'feel' for what the computer is doing underneath that younger (and really capable!) devs lack. Often when performance is really critical I'll go look in the source code for the tool to get a feel for what it is really doing (even though I haven't written C in a long time) which is regarded as voodoo. On the flip side of course is I can build things in an afternoon or a day or two that simply wouldn't have been possible with months or years of work and a dev team of dozens back then. My next side project is a tool for motorcyclists, you drop pins on a map where you are going to be at points in time and it then pulls the complete meterological data for those points and does some calculations (are the roads likely to be wet, icy, show the direction of the wind, show the windchill at 30mph, 40mph, 50mph etc) with the ability to set recurring routes and email you the day before something like "Tomorrow morning, there may be ice on the roads, wind chill will be 5C, feels like temperature at 40mph -2c, Sunny, low winter sun so wear your shades/visor" The data to do that didn't exist 30 years ago and the GIS tooling (I'm using open street maps) to process the entire UK would have cost millions.

dsego 7y ago

Have you seen the 30 million line problem* by Casey Muratori (of Handmade Hero fame)? There is an argument that a lot of today's complexity in software is an (unnecessary) byproduct of changes in hardware design. *https://youtu.be/kZRE7HIO3vk https://youtu.be/kZRE7HIO3vk