4 ms·

The article is full of unjustified hatred for modern software practices. The author fails tô acknowledge the amount of failures of big projects and escalating c

The article is full of unjustified hatred for modern software practices. The author fails tô acknowledge the amount of failures of big projects and escalating costs, focusing only in the fact that today practices output less robust software.

crabbone 3y ago
Hatred for modern software practices is fully justified. Unfortunately we didn't have enough of historical evidence yet, nor did we have enough shifts in software development practices to tell if we had it much worse or much better before, but there are obvious shortcomings of what we do today compared to 20-30 years ago. The major shortcomings, the way I see them: 1. The overall software quality is on steady decrease since late 70's. This is, at least in part, due to more software being developed for less mission-critical systems and consequently by less qualified personnel. So, commercially, we don't need as much of higher-quality software as we did before. 2. Software industry is exceptional in the way it relies on multiple other players in the industry for individual production and as such is a lot more susceptible to trends and more influenced by majority than many others. I.e. of the majority of the industry decides they don't need long-term support, then the minority won't have it because the minority's survival is contingent on the policy and services (inadvertently) provided by the majority. 3. Software quality is exceptionally difficult to measure formally. This leads to big and small players, intentionally and unknowingly, mis-advertising and misunderstanding the quality of their own products. This makes it very hard to almost impossible to price your products or services based on quality. The realistic alternative to quality the companies are using is the ability of the product / service provider to support the customer in the case of failure. Which is a function of size of a company provider more than anything else. This leads to the situation where instead of focusing on understanding and improving software quality, companies develop reputation though marketing and customer support, which they later misrepresent as software quality. All the above is the result, at leas in the large part, of the modern software practices. We created the practices that emphasize speed of delivery over every other aspect of software because we don't know and don't want to figure out how to reliably increase any other metric. We created a lot of monopolies in software world by following the modern development practices which preach using commonly used third-party components, even of lower quality over bespoke alternatives. This is especially motivated by cost savings when it comes to human resources, which become more interchangeable (and cheaper in the short term for the employer) with this approach. Software monopolies stifle innovation and fix prices not only in the software field, but they also adversely affect the hardware field which has to adjust itself to the software practices. We could be doing better if we understand the shortcomings of our current process -- these aren't the necessary consequences of making software, but in order to effect a change initial good will is needed from multiple players, which is hard to accomplish w/o these multiple players, at least, first acknowledging the problems.

crabbone 3y ago

Hatred for modern software practices is fully justified. Unfortunately we didn't have enough of historical evidence yet, nor did we have enough shifts in software development practices to tell if we had it much worse or much better before, but there are obvious shortcomings of what we do today compared to 20-30 years ago. The major shortcomings, the way I see them: 1. The overall software quality is on steady decrease since late 70's. This is, at least in part, due to more software being developed for less mission-critical systems and consequently by less qualified personnel. So, commercially, we don't need as much of higher-quality software as we did before. 2. Software industry is exceptional in the way it relies on multiple other players in the industry for individual production and as such is a lot more susceptible to trends and more influenced by majority than many others. I.e. of the majority of the industry decides they don't need long-term support, then the minority won't have it because the minority's survival is contingent on the policy and services (inadvertently) provided by the majority. 3. Software quality is exceptionally difficult to measure formally. This leads to big and small players, intentionally and unknowingly, mis-advertising and misunderstanding the quality of their own products. This makes it very hard to almost impossible to price your products or services based on quality. The realistic alternative to quality the companies are using is the ability of the product / service provider to support the customer in the case of failure. Which is a function of size of a company provider more than anything else. This leads to the situation where instead of focusing on understanding and improving software quality, companies develop reputation though marketing and customer support, which they later misrepresent as software quality. All the above is the result, at leas in the large part, of the modern software practices. We created the practices that emphasize speed of delivery over every other aspect of software because we don't know and don't want to figure out how to reliably increase any other metric. We created a lot of monopolies in software world by following the modern development practices which preach using commonly used third-party components, even of lower quality over bespoke alternatives. This is especially motivated by cost savings when it comes to human resources, which become more interchangeable (and cheaper in the short term for the employer) with this approach. Software monopolies stifle innovation and fix prices not only in the software field, but they also adversely affect the hardware field which has to adjust itself to the software practices. We could be doing better if we understand the shortcomings of our current process -- these aren't the necessary consequences of making software, but in order to effect a change initial good will is needed from multiple players, which is hard to accomplish w/o these multiple players, at least, first acknowledging the problems.