3 ms·

The majority of commercial software writers are banging out poorly designed, fragile, inadequately tested and often borderline-unmaintainable code. I feel that

The majority of commercial software writers are banging out poorly designed, fragile, inadequately tested and often borderline-unmaintainable code. I feel that people have a kind of double-think about this; they suspect this is the case, but they still expect software to work properly.

alok-g 10y ago
The same applies to hardware design at many companies, including reputed ones. I witnessed a case were they went from an R&D prototype to product with no quality control in the design process. Product failures in the market were followed by blame games.
slachance 10y ago
Amen. I work at one of the most well-reputed software product companies in the world. We pride ourselves in hiring the very best, and try to do so through an interviewing program that simulates real life coding instead of an academic whiteboard situation. Even amongst smart people, the bar for software quality is shockingly low. You will find ostensibly senior people again and again who given half a chance with espouse all day long the importance of high quality code, well-designed abstraction, separation of concerns, and good testing. You can then let these people operate for a few hours by themselves and examine the result. In all but a few situations, it'll be a pile of mud that's designed counter to every one of the values they talk about. Often they're not aware of this, but it's also very common that they know it's sloppy, and don't really care. People don't do what's right, they do what's easy. In a corporate environment, there is never a structure to identify the developers who are most likely to write good and maintainable code (it's too subjective) so that they can be put into a review capacity, and even if there were, there just isn't the bandwidth to review new additions to the depth that's required. In an ideal situation, many patches would be returned to author essentially asking for a complete rewrite, but that's difficult to justify given that building strong relationships inside the team needs to be considered. The result is that all software developed in industry trends towards bad over time, and it appears to be as absolute of a universal constant as entropy. You can find localized exceptions, but they're often only temporarily good as eventually more people contribute more features.

alok-g 10y ago

The same applies to hardware design at many companies, including reputed ones. I witnessed a case were they went from an R&D prototype to product with no quality control in the design process. Product failures in the market were followed by blame games.

slachance 10y ago

Amen. I work at one of the most well-reputed software product companies in the world. We pride ourselves in hiring the very best, and try to do so through an interviewing program that simulates real life coding instead of an academic whiteboard situation. Even amongst smart people, the bar for software quality is shockingly low. You will find ostensibly senior people again and again who given half a chance with espouse all day long the importance of high quality code, well-designed abstraction, separation of concerns, and good testing. You can then let these people operate for a few hours by themselves and examine the result. In all but a few situations, it'll be a pile of mud that's designed counter to every one of the values they talk about. Often they're not aware of this, but it's also very common that they know it's sloppy, and don't really care. People don't do what's right, they do what's easy. In a corporate environment, there is never a structure to identify the developers who are most likely to write good and maintainable code (it's too subjective) so that they can be put into a review capacity, and even if there were, there just isn't the bandwidth to review new additions to the depth that's required. In an ideal situation, many patches would be returned to author essentially asking for a complete rewrite, but that's difficult to justify given that building strong relationships inside the team needs to be considered. The result is that all software developed in industry trends towards bad over time, and it appears to be as absolute of a universal constant as entropy. You can find localized exceptions, but they're often only temporarily good as eventually more people contribute more features.