In my opinion: - The software architecture today is way more complex that was in the old days. And there is a lot more users paying attention to the bugs. So it's easier to spot bugs today. - The developers trust a lot of ready libs, and doing that they don't really need to learn how that libs work (or be capable to create it their own), and that normally cause devs to be lazier and "weaker". - The developers have a lot of hardware power, so they don't really pay attention on how to use the hardware in the better way, and even they want to, they are not prepared to do it, because the current culture is to create something closer library and framework users, than actually developers. - The focus in productivity over performance. Focusing on what is easy to do.
16:52 Operating systems, browsers, no matter how often you deploy these, they always have to stay stable and you can almost never remove something or cut something out (except internally), because there may be many independent third parties relying and building upon it, and changing anything (including effects caused by internal operations) could break stuff for lots and lots of people, so is essentially bound to be kept in and maintained forever. Windows can probably never safely remove any DOS or Win32 or COM or whatever, even if deprecated/discontinued, but there might be too much investments and old stuff out that's relying and is dependent on it, with no replacement/upgrade path or alternatives. Maybe a better approach is to be very reluctant to introduce anything new (but competitors may be more "innovative"), or not expose interfaces/internals much, or bake in some upgrade mechanism, which most of our older software and platforms do not really have.
Isn't it a bit off to take an open, libre-freely licensed software project as an example? Is not a cathedral/house project with a pre-defined scope and final target state, it's more of an always-growing bazaar/city, from just one person deciding on the features for this personal hobby project to more and more contributors, adding more and more things, and then busy too with supporting ever-increasing demands. Or what to do, feature-freeze? Forks are free to extend theirs. Or proprietary kernels done by only one company, can they just do a feature-freeze, no matter what their customers want or the hardware changing under them, or new improvements supplied by research? Also, for your exponential charts, consider: if it's just a small toy project in the beginning, there's not many people contributing, but the more and better it gets, the more people join and contribute. So the initial amount of lines of code at the start of the time-axis may be nowhere near the original author indents/hopes to get his/her project to, but simply can't add as much lines of code as wanted, in lack of contributions/capacity.
Around 7:00 - no, you're comparing lines of code vs. amount of code in these charts. These are not the same. Additional/added lines of code over time in your chart only increases slightly for the Linux kernel over time, it's not the total/sum/absolute, while you have the amount of work for say a construction project relative, not as the total/sum/absolute/compound/cumulation of all the work that went into the house so far, plus the later maintenance. A construction project would have an initial huge curve/increase, and then an ever-growing increase, probably similar to the Linux kernel lines of code, a construction project even similarly having the later increase growing as repairs become more frequent the longer it goes. Main difference is that software can start out with just one guy and be grown over time, while a house construction project requires a huge initial effort/investment. Also, consider, financing a house, that's lots of money somebody had to earn in advance or has to pay back later on loan, spending a lot of work/effort over time just as well.
Well, from 10:26 to , guess what: software is not natural/biological, it's not a "real world", but a virtual, artificial one, so no need to get all too tied up in an analogy with "evolution". You may propose the introduction of such, but often for the end user there's no apparent advantage/improvement/benefit to internal refactoring, and too the cost of doing it would involve/require capacity/intention/effort of probably whole teams, therefore effort unfortunately tends to rather get spent on what has an immediate, visible and often short-term advantage to the user/paying-customer, all too willingly at the expense of the long-term (because who knows who'll be still on board/ship in the long-term, if the project/company/customer will still be around, etc.).
Happy to see Richard Gabriel mentioned, nice video :)
In my opinion:
- The software architecture today is way more complex that was in the old days. And there is a lot more users paying attention to the bugs. So it's easier to spot bugs today.
- The developers trust a lot of ready libs, and doing that they don't really need to learn how that libs work (or be capable to create it their own), and that normally cause devs to be lazier and "weaker".
- The developers have a lot of hardware power, so they don't really pay attention on how to use the hardware in the better way, and even they want to, they are not prepared to do it, because the current culture is to create something closer library and framework users, than actually developers.
- The focus in productivity over performance. Focusing on what is easy to do.
16:52 Operating systems, browsers, no matter how often you deploy these, they always have to stay stable and you can almost never remove something or cut something out (except internally), because there may be many independent third parties relying and building upon it, and changing anything (including effects caused by internal operations) could break stuff for lots and lots of people, so is essentially bound to be kept in and maintained forever. Windows can probably never safely remove any DOS or Win32 or COM or whatever, even if deprecated/discontinued, but there might be too much investments and old stuff out that's relying and is dependent on it, with no replacement/upgrade path or alternatives.
Maybe a better approach is to be very reluctant to introduce anything new (but competitors may be more "innovative"), or not expose interfaces/internals much, or bake in some upgrade mechanism, which most of our older software and platforms do not really have.
Isn't it a bit off to take an open, libre-freely licensed software project as an example? Is not a cathedral/house project with a pre-defined scope and final target state, it's more of an always-growing bazaar/city, from just one person deciding on the features for this personal hobby project to more and more contributors, adding more and more things, and then busy too with supporting ever-increasing demands. Or what to do, feature-freeze? Forks are free to extend theirs. Or proprietary kernels done by only one company, can they just do a feature-freeze, no matter what their customers want or the hardware changing under them, or new improvements supplied by research?
Also, for your exponential charts, consider: if it's just a small toy project in the beginning, there's not many people contributing, but the more and better it gets, the more people join and contribute. So the initial amount of lines of code at the start of the time-axis may be nowhere near the original author indents/hopes to get his/her project to, but simply can't add as much lines of code as wanted, in lack of contributions/capacity.
Around 7:00 - no, you're comparing lines of code vs. amount of code in these charts. These are not the same. Additional/added lines of code over time in your chart only increases slightly for the Linux kernel over time, it's not the total/sum/absolute, while you have the amount of work for say a construction project relative, not as the total/sum/absolute/compound/cumulation of all the work that went into the house so far, plus the later maintenance. A construction project would have an initial huge curve/increase, and then an ever-growing increase, probably similar to the Linux kernel lines of code, a construction project even similarly having the later increase growing as repairs become more frequent the longer it goes. Main difference is that software can start out with just one guy and be grown over time, while a house construction project requires a huge initial effort/investment. Also, consider, financing a house, that's lots of money somebody had to earn in advance or has to pay back later on loan, spending a lot of work/effort over time just as well.
Well, from 10:26 to , guess what: software is not natural/biological, it's not a "real world", but a virtual, artificial one, so no need to get all too tied up in an analogy with "evolution". You may propose the introduction of such, but often for the end user there's no apparent advantage/improvement/benefit to internal refactoring, and too the cost of doing it would involve/require capacity/intention/effort of probably whole teams, therefore effort unfortunately tends to rather get spent on what has an immediate, visible and often short-term advantage to the user/paying-customer, all too willingly at the expense of the long-term (because who knows who'll be still on board/ship in the long-term, if the project/company/customer will still be around, etc.).