|
|
|
|
|
by prophetjohn
2804 days ago
|
|
> The great architect has the foresight on how the code will be used in five years and design it accordingly Perhaps this is a function of me working in startups and consulting my whole career, but it seems extremely misguided, if not negligent for an experienced engineer trying to design for use cases five years in the future. Five months into the future is even pushing it. What kind of companies operate in this way? |
|
Even if a company fails, their products, processes (and code) usually get absorbed by some other company and need to be maintained - startups get acquihires that keep teams but discard products; "normal companies" get M&As that discard headcount but keep product lines, divisions and processes that require lots and lots of running code. The large companies often have multiple "inherited" codebases from all the other companies they have absorbed. And there is a lot of old code running; nothing is as permanent as temporary code - I have seen comments stating "this won't work properly on the boundary between fiscal years, but the system is scheduled to be replaced by then" that were made IIRC 6 years before I was looking at that system, so it obviously did not get replaced back then. In many industries a 10-year old company is a young company; heck, most of the current "internet startup unicorns" are 10, 20 or more years old; in established industries (you do know that the vast majority of software people work in non-software companies, right? most code is written for internal business needs, not sold as a service or product or consulting to others) there is a lot of mature code serving business processes that have been there for decades, will be there for decades, but often have some changes that require also code adaptations. The same goes for all the code that's inside industrial products - in the automotive industry, in home electronics industry, etc; you may have a new model of car every year, but most of the code in that car will be much older than that.
I mean, the trivial fact is that if we look across the whole industry, all the statistics show that the majority of programmer manpower is spent on maintenance. So the total costs of software are dominated by how easy it is to maintain it, and a lot of that comes from proper design that takes into account what the likely needs are going to be after a bunch of years.