@matt @glyph What many fail to reflect upon is whether the amount of effort to *learn* how to use the existing solution may exceed the amount of effort required to *write* a solution. The assumption is always that learning is free, but coding is expensive.

@grimalkina Optimizing for elegance, I would suggest either Mathematica ( https://www.wolfram.com/mathematica/ ) or Smalltalk ( https://squeak.org )

@grimalkina And, of course, I skipped over the "people is people" part -- because activities designed to affect team morale and alignment and diversity are clearly ( I hypothesize) unrelated to the role or industry those people are in.

@grimalkina The accounting rules cut across all industries, so to the extent that software development practices (like distinguishing capital activities from expense activities, or tracking hours spent by project) are driven by accounting rules — those management practices are not specific to software teams. Again, a catalog of “we do these things because accounting” would be helpful (e.g. development (capital) vs operations (expense) ).

@grimalkina Now that Section 174 has become effective, it reminds me that the whole "Object-Oriented” push in the 1980s was an attempt to change accounting practices by talking up “software reuse" and "objects” so that not-for-sale software could be capitalized. This resulted in FASB SOP 98-1 in 1998. which allowed such capitalization. Section 174 gives us another opportunity to observe whether software development practices are driven by accounting rules more than we are willing to admit.

@grimalkina Yet another is suggested by Eric von Hippel's book Democratizing Innovation -- in which he provides multiple examples of how “Open Source” is an instance of the kind of innovation practiced in various industries. Is there really something special about software and “open source”? (e.g. there might be more co-ordination amongst participants in open-source software than democratized innovation in other industries)

@grimalkina Yet another hypothesis centers on quality. The way Quality Assurance teams work in software, and ideas like Test-Driven Development and code review aim to reduce software faults. One rarely hears references to Deming and statistical quality control in regards to software. Is this because manufacturing software is inherently different? Or would adopting quality practices from other industries increase software quality? I don't know if there have been any experiments around this.

@grimalkina Another hypothesis is suggested by the observation that “agile methods" were borrowed from Toyota -- suggesting that managing a software development team is very similar to managing a team of auto workers. So which management methods for software teams are “bespoke” vs borrowed/shared with other professions/industries. In this case -- a catalog of methods and their provenance might prove sufficient.

@grimalkina That last observation aligns with the hiring practice of "coding interviews" which test for very specific skills rather than more general knowledge and ability.

@grimalkina Another one that I think about a lot is the requirement that lawyers (and auto mechanics) engage in continuing education. Software developers have no such requirement. Is this because 1) the field of software development does not evolve as rapidly as the law or auto technology? or 2) that software developers are expected to learn on their own time and resources? or 3) that turnover in technology is so rapid that it is more effective to hire new skills rather than grow them.