3 ms·
Yeah, but 99% of projects aren't anywhere close to long lived. Most products fail to launch. Most products that launch shutter within a few years. Having a code
by musingsole 6y ago
Yeah, but 99% of projects aren't anywhere close to long lived. Most products fail to launch. Most products that launch shutter within a few years. Having a code base survive long enough in close enough to its original state for a commit message to be meaningful a year later is unlikely outside of a few cases.
Also, this is all predicated on the business case for the software being well understood that it could be written out beforehand by a entry level engineer. Which is not a situation I've seen outside of a processor design house. Otherwise, your thinking for this or that choice will be built on shifting sand anyway.
- yxhuvud 6y agoOn the other hand, most people don't work at those short-lived projects. The vast majority of people work for profitable companies that have plenty of long lived code.
- dredmorbius 6y agoShort-term coding practices produce short-lived code. Predetermining code longevity is challenging.
- u801e 6y ago> Yeah, but 99% of projects aren't anywhere close to long lived. Most products fail to launch. Most products that launch shutter within a few years. Having a code base survive long enough in close enough to its original state for a commit message to be meaningful a year later is unlikely outside of a few cases. A lot of companies run code in production that was written years if not decades ago. Being able to look at the commit history and blame output helps in terms of getting some context about what was done and why it was done they way it was when the original authors have long since left the company. In my company, we still have some code written back in 2005 still running in production.