4 ms·
A big problem is that software organization success largely depends on "soft sciences" like psychology and physiology. Science may find ways to make faster mach
by tabtab 7y ago
A big problem is that software organization success largely depends on "soft sciences" like psychology and physiology. Science may find ways to make faster machines, but being that the actual bottlenecks are the cost of humans reading code and designs and managing changes to systems, the human grokkability factor is usually the largest.
Software should be written mostly with humans (code readers) in mind, and not machines. The soft sciences are much harder to study; it's expensive to use trial and error on real projects in order to compare outcomes. Equations on a blackboard or chips in a lab are probably not where most real IT revelations will come from.
There are pet theories that focus on overly-narrow factors. For example, those who focus on linguistic parsonomy (less code) may conclude that functional programming is "better" because it usually can be made the most compact. However, a good many coders have a hard time working well with functional programming. Some take a Darwinian view and say "fire them all and hire elite functional coders". But so far that has rarely paid off in the market-place, barring a few grow-fast-at-all-costs startups. Short code is not always legible code to the majority of coders.
- instantnoodler 7y agoI mean no offense but this is a crap answer. They're asking for book recommendations.
- tabtab 7y agoI guess what I'm trying to say is that there are no books that address and "solve" the real issues of typical software design, and I am explaining the reason why there are no such books. It's kind of like asking for good books on Pluto before any probe had visited Pluto: you are only going to find a lot of speculation. The closest thing are books with specific examples that explain the trade-offs made and try to find general rules and apply them to the examples. But I find such to be either mostly opinions, or too vague to apply in practice. At best they exercise your brain in terms of questions to ask in exploring the different design options, but they don't give clear-cut rules for the final choice that stand up to scrutiny. They can tell you about the kinds of beasts you'll encounter in the dark forest, and give suggestions for defeating the beasts, but the recipes for success are either subjective or nebulus, yet to be subjected to real testable science. They could be if some research institution spent big bucks on it, but so far nobody has. Our field has a "science gap" which results in a book gap. The blunt truth is that IT is more about people than machines or math.