6 ms·

OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks l

OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances. You can do most things with OOP or without OOP but each path has some upsides and downsides and most of the time it's good to use some things it provides where it makes sense and not get too religious about it. The great architect has the foresight on how the code will be used in five years and design it accordingly.

Nursie 8y ago
Yup, I like to think the religious war has subsided, and we're a little more free to do things in ways which work, are concise, readable and maintainable, even in previous bastions of enterprise OOP fervour like Java.
Waterluvian 8y ago
I think this relates to what you're saying. I've never felt any frustration that OOP feels like the wrong tool when I'm using languages that give me the choice to use it or not (like Python, and JavaScript). But when I'm using Java, as one example, it often feels like I'm really locking myself into a design up front. In Python, especially. I'll find myself starting off all experiments or simple projects with functions and basic data types. As something evolves and I want some semantic clarity I'll stop using dicts and start using namedtuples. And then at some point I may replace the namedtuples with classes. From there I may discover value in having subclasses so I'll add a few (but this is exceedingly rare in my line of work).
- Chabs 8y ago
  But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow. Sure, that limits creativity, but in many business contexts, the last thing you want is your programmers getting "cute". There's a straight line from requirements to implementation; no meandering involved. At least that's the theory. In practice...
  - Waterluvian 8y ago
    Yes. That may very well be. And I'm not saying Java is bad because of what I described. Just that I experience the, "ugh OOP isn't helping me do what I want to do here" with Java.
    - std_throwawayay 8y ago
      It probably is the right tool if you have an enterprise problem that needs an enterprise solution.
      - mikmoila 8y ago
        According to my experience "enterprise problems" are more related to scalability, data integrity, APIs, and workforce hiring than "what programming paradigm to use."
  - xapata 8y ago
    It was a hypothesis, not a theory. Usually a hypothesis is abandoned after so many counter examples.
  - madmax96 8y ago
    https://medium.com/stanford-d-school/want-some-creativity-crank-up-the-constraints-5728a988a635 https://medium.com/stanford-d-school/want-some-creativity-cr... It’s interesting - when you begin adding constraints, sometimes it helps solve the problem. You can’t be creative unless you’ve created a solution. It would be interesting to see the impact on this with programming languages.
  - jcoffland 8y ago
    I'm glad I don't work places that try to keep me from being "cute".
  - bunderbunder 8y ago
    > But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow. That may have been where Java wanted to go, but, when I'm working in Java, I don't feel like that's where I am. Ways of doing things in Java tend to be wildly inconsistent from project to project. Partially, I think, because so much core functionality in the Java ecosystem was allowed to be federated out to 3rd-party projects for so long. Take the long-standing popularity (and rivalry) of Guava and Apache Commons for handling even basic tasks that are hard to get done using the core Java APIs. If there's such a thing as a "platform smell", I'd say that certainly qualifies. With Python, on the other hand, there is a fairly consistent common understanding of what "Pythonic" means, and, even when there really is more than one way to do it, the question of which one to use can usually be quickly resolved to a predictable outcome by simply pointing out that one option is the more Pythonic way to do things. (edit: Though, to be fair, Java was first released into a world where languages like C, C++ and Common Lisp represented the status quo. Expectations were lower at the time.)
- std_throwawayay 8y ago
  My experience with Python is largely the same. I often start with local variables in a script, then put some parts into functions, then start putting some shared/persistent data into dicts. If after some time a pattern emerges where I think "gee, wouldn't it be useful to pack these three variables that always occur together and interact with each other into a class and use some methods to consistently modify them?". Then I create a class that does some specific thing. This transformation occurs gradually over the development process and the data shapes the design of the application. I would call this process a prototype development. At the end I would have the knowledge about the design where I could start implementing it in Java or C++. But the problem is already solved well enough in Python and you almost never need to take the leap to another programming language. The program is not good, the design is not well thought out and the implementation is not very clean. It is a design prototype that you use to write the real application. If only there were time for a fresh start. The solution that we have by that point is not perfect but it does three things: Actually solve the problem, solve it good enough for regular usage and it allows further modification with only minor pain. I wish I could tell the full story but most software stories end before the grand finale.
- ken 8y ago
  > I've never felt any frustration that OOP feels like the wrong tool when I'm using languages that give me the choice to use it or not (like Python, and JavaScript). Do you not miss more advanced features, like multiple dispatch? Do you just implement it ad-hoc when you need it? I don't know any way to say it that doesn't come off sounding condescending, but this looks like the Blub Paradox to me. Python's brand of OOP is better than most, but it still feels pretty limiting to me. It doesn't even offer syntactic abstraction to make it easy to work around. You have to hope (as the 'multimethod' package does) that other features accidentally allow you to.
  - Waterluvian 8y ago
    It's not something I've ever needed with such frequency that I wished it was in the core langauge. When I need it I just use a library that exposes it. I use a decorator based multidispatch.
mehrdadn 8y ago
> OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances. No... I think this is missing precisely what was exactly the point of the article (see "(B)" in the text). This post is not a fight over OOP religion. The point of it is if you misunderstand or mischaracterize "nuances" about some idea (if these are actually all nuances, which I think is debatable) and propagate them, then you shield other people from prior (edit: or even current) literature in the area, and hence prevent them from understanding what the relevant techniques really are and how to use them properly at all. This makes them lose a potentially powerful tool in their toolset, which you should agree is an awful thing regardless of what coding 'religion' you follow.
- jshowa1 8y ago
  Just because prior literature exists, does not mean it should not be superseded. For example, generics wasn't even a thing when OOP originally started and yet LINQ and basic list ADT's wouldn't be as powerful without it.
  - mehrdadn 8y ago
    > Just because prior literature exists, does not mean it should not be superseded. For example, generics wasn't even a thing when OOP originally started and yet LINQ and basic list ADT's wouldn't be as powerful without it. No, this not an example... generics did not "supercede" OOP.
    - jshowa1 8y ago
      My point is that earlier OOP documents did not implement generics. When they were finally implemented in OOP, it superseded the original intentions of OOP. The question is, are we now supposed to remove generics because they don't conform to the early literature of OOP? Looks like the OOP edited his comment though, so my point is irrelevant.
jshowa1 8y ago
How has the church of OOP failed? Nearly every used language is based almost entirely on OOP. OOP makes organizing software and code reuse incredibly easy. The only real downsides to OOP is that its arguably slower and has more overhead. But that's only a problem in niche applications (ie. embedded apps).
- std_throwawayay 8y ago
  It failed by teaching that every data structure should be put into classes using many levels of inheritance, interfaces, encapsulation, accessors and the whole shebang when the thing really is just a plain old integer. OOP is really useful and powerful in many areas and applications but it is not the only tool that has to be used for everything.
  - jpindar 8y ago
    That sounds like a failure of the teachers then, not of OOP.
- macintux 8y ago
  There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy. OOP-based languages are certainly more common, but definitely not the only game in town. Clojure, Erlang, Lisp, Perl 4, Forth, Fortran, Haskell...
- simongray 8y ago
  > OOP makes organizing software and code reuse incredibly easy. That is the big promise and the big lie of OOP. It, in fact, accomplishes the opposite. The medium used across systems today is data, not objects. Your objects are not compatible with systems across the wire, they need to be converted to data (JSON, XML, ...). They're not compatible with your data base, they need to be converted to data (SQL, ...). And if you want to use other people's objects (say from a library) you first have to make a layer that translates them for your own objects, since objects from other systems won't directly fit the model of your own object system, they always need to be engineered in. And if the objects are encapsulating data that you actually need, but doesn't offer ways to get it (private methods), you often have to jump through hoops to get it. Not to mention the fact that OOP often entails immutability which leads to problems while doing multithreaded processing. Clearly the answer is to use a more data-oriented perspective and use a programming language focused around data. Clojure gets it right and that's what I use. It's all concise functional code that skips all that class creation OOP loves, instead operating directly on immutable data (numbers, strings, maps, vectors, sets). I recommend watching some talks by Rich Hickey (the guy who made Clojure). They're almost all excellent.
pjmlp 8y ago
A specific church of OOP. OOP the Eiffel, Sather, Smalltalk, C+@, BETA, CLOS, SELF way isn't the same thing as most people learn in school as THE OOP. Just like there isn't a single way of doing FP or LP. Also lets not forget that all successful FP/LP languages are actually multi-paradigm and also include OOP concepts.
swagtricker 8y ago
>The great architect has the foresight on how the code will be used in five years and design it accordingly. Isn't he better off taking that crystal ball that gives him the foresight, using it to pick the correct lottery numbers and simply retiring?
- pvarangot 8y ago
  Predicting position and velocity of little plastic balls tumbling inside some rotating container is a very different problem to predicting the behaviour of future API consumers. Specially if those consumers work in the same company you do and have shared objectives. So no, he's not better using that "crystal ball" to predict the lottery.
- std_throwawayay 8y ago
  Many applications run maybe 10 times on real data and then their purpose is fulfilled. You don't need to design a microservice architecture with redundant servers when a simple shell script could do the job better. You need to foresee the scale of what you're building and how you would proceed to the next level. Some things must be solved right before the first deployment because you can never change them after the application is deployed. You must know what these things are and solve them right. You must also reduce their number ideally to zero if possible. You must use solutions that allow refactoring and later scaling in areas where your crystal ball is not sure. If the hard things are solved correctly you can use average workers to do the rest and it will work well.
grawprog 8y ago
I kind of like the way D handles oop. D gives you structs, classes and interfaces. Structs are stack allocated and have no inheritance. But are otherwise syntactically work like classes. Classes are heap allocated and allow single inheritance, unless the parent is an interface. Interfaces are similar to a class but it's member functions must be overridden. A class can inherit from multiple functions. I tend to use a mix of these and templates depending on the type of data i'm handling. I find it gives the best of whatever design pattern works well for different parts of a project without locking you into a certain paradigm throughout and still keeping everything fairly logical and coherent to read through and understand.
prophetjohn 8y 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?
- Fellshard 8y ago
  Consultant here, and I think that's a big blind spot we tend to have: we don't stick around for long enough to see the consequences of what we designed, usually.
  - prophetjohn 8y ago
    I have more experience at startups than as a consultant. I was the 6th hire at a company that grew to 130 over three years and I was never thinking more than a few months in advance. A lot changes in five years — your customers, the competitive landscape. It's an enormously long period of time in technology. It seems like such a waste of time when you have customers that have real, unsolved problems today
    - discreteevent 8y ago
      Unless it's some one off batch process or a prototype, if the codebase doesn't last at least six months then it's unlikely to be something that makes any money. In my experience, badly designed code tends to become a net loss after a couple of months because after that time someone is going to have to modify or fix it.
- ssijak 8y ago
  Companies that are here to stay and plan to stay for longer, not the hipster wannabe unicorn type
- PeterisP 8y ago
  Probably every company outside the startup domain? If you're working on product-market fit, then you can expect to discard lots of systems, however, that's a niche and even startups are only temporarily in that position (unless they fail). For any business where there is a clear product-market fit (which, employee-wise, is pretty much all businesses) the systems rarely go away, they accumulate - if you're not a startup, or if you have found your product-market fit, then you expect that your products and processes won't disappear after 5 months or 5 years, and neither will the code that supports them, unless it's so broken that it's prudent to invest in a full rewrite. 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.
Koshkin 8y ago
> everything is made of bits Bits are objects, too...

Nursie 8y ago

Yup, I like to think the religious war has subsided, and we're a little more free to do things in ways which work, are concise, readable and maintainable, even in previous bastions of enterprise OOP fervour like Java.

Waterluvian 8y ago

I think this relates to what you're saying. I've never felt any frustration that OOP feels like the wrong tool when I'm using languages that give me the choice to use it or not (like Python, and JavaScript). But when I'm using Java, as one example, it often feels like I'm really locking myself into a design up front. In Python, especially. I'll find myself starting off all experiments or simple projects with functions and basic data types. As something evolves and I want some semantic clarity I'll stop using dicts and start using namedtuples. And then at some point I may replace the namedtuples with classes. From there I may discover value in having subclasses so I'll add a few (but this is exceedingly rare in my line of work).

Chabs 8y ago
But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow. Sure, that limits creativity, but in many business contexts, the last thing you want is your programmers getting "cute". There's a straight line from requirements to implementation; no meandering involved. At least that's the theory. In practice...
- Waterluvian 8y ago
  Yes. That may very well be. And I'm not saying Java is bad because of what I described. Just that I experience the, "ugh OOP isn't helping me do what I want to do here" with Java.
  - std_throwawayay 8y ago
    It probably is the right tool if you have an enterprise problem that needs an enterprise solution.
    - mikmoila 8y ago
      According to my experience "enterprise problems" are more related to scalability, data integrity, APIs, and workforce hiring than "what programming paradigm to use."
- xapata 8y ago
  It was a hypothesis, not a theory. Usually a hypothesis is abandoned after so many counter examples.
- madmax96 8y ago
  https://medium.com/stanford-d-school/want-some-creativity-crank-up-the-constraints-5728a988a635 https://medium.com/stanford-d-school/want-some-creativity-cr... It’s interesting - when you begin adding constraints, sometimes it helps solve the problem. You can’t be creative unless you’ve created a solution. It would be interesting to see the impact on this with programming languages.
- jcoffland 8y ago
  I'm glad I don't work places that try to keep me from being "cute".
- bunderbunder 8y ago
  > But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow. That may have been where Java wanted to go, but, when I'm working in Java, I don't feel like that's where I am. Ways of doing things in Java tend to be wildly inconsistent from project to project. Partially, I think, because so much core functionality in the Java ecosystem was allowed to be federated out to 3rd-party projects for so long. Take the long-standing popularity (and rivalry) of Guava and Apache Commons for handling even basic tasks that are hard to get done using the core Java APIs. If there's such a thing as a "platform smell", I'd say that certainly qualifies. With Python, on the other hand, there is a fairly consistent common understanding of what "Pythonic" means, and, even when there really is more than one way to do it, the question of which one to use can usually be quickly resolved to a predictable outcome by simply pointing out that one option is the more Pythonic way to do things. (edit: Though, to be fair, Java was first released into a world where languages like C, C++ and Common Lisp represented the status quo. Expectations were lower at the time.)
std_throwawayay 8y ago
My experience with Python is largely the same. I often start with local variables in a script, then put some parts into functions, then start putting some shared/persistent data into dicts. If after some time a pattern emerges where I think "gee, wouldn't it be useful to pack these three variables that always occur together and interact with each other into a class and use some methods to consistently modify them?". Then I create a class that does some specific thing. This transformation occurs gradually over the development process and the data shapes the design of the application. I would call this process a prototype development. At the end I would have the knowledge about the design where I could start implementing it in Java or C++. But the problem is already solved well enough in Python and you almost never need to take the leap to another programming language. The program is not good, the design is not well thought out and the implementation is not very clean. It is a design prototype that you use to write the real application. If only there were time for a fresh start. The solution that we have by that point is not perfect but it does three things: Actually solve the problem, solve it good enough for regular usage and it allows further modification with only minor pain. I wish I could tell the full story but most software stories end before the grand finale.
ken 8y ago
> I've never felt any frustration that OOP feels like the wrong tool when I'm using languages that give me the choice to use it or not (like Python, and JavaScript). Do you not miss more advanced features, like multiple dispatch? Do you just implement it ad-hoc when you need it? I don't know any way to say it that doesn't come off sounding condescending, but this looks like the Blub Paradox to me. Python's brand of OOP is better than most, but it still feels pretty limiting to me. It doesn't even offer syntactic abstraction to make it easy to work around. You have to hope (as the 'multimethod' package does) that other features accidentally allow you to.
- Waterluvian 8y ago
  It's not something I've ever needed with such frequency that I wished it was in the core langauge. When I need it I just use a library that exposes it. I use a decorator based multidispatch.

mehrdadn 8y ago

> OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances. No... I think this is missing precisely what was exactly the point of the article (see "(B)" in the text). This post is not a fight over OOP religion. The point of it is if you misunderstand or mischaracterize "nuances" about some idea (if these are actually all nuances, which I think is debatable) and propagate them, then you shield other people from prior (edit: or even current) literature in the area, and hence prevent them from understanding what the relevant techniques really are and how to use them properly at all. This makes them lose a potentially powerful tool in their toolset, which you should agree is an awful thing regardless of what coding 'religion' you follow.

jshowa1 8y ago
Just because prior literature exists, does not mean it should not be superseded. For example, generics wasn't even a thing when OOP originally started and yet LINQ and basic list ADT's wouldn't be as powerful without it.
- mehrdadn 8y ago
  > Just because prior literature exists, does not mean it should not be superseded. For example, generics wasn't even a thing when OOP originally started and yet LINQ and basic list ADT's wouldn't be as powerful without it. No, this not an example... generics did not "supercede" OOP.
  - jshowa1 8y ago
    My point is that earlier OOP documents did not implement generics. When they were finally implemented in OOP, it superseded the original intentions of OOP. The question is, are we now supposed to remove generics because they don't conform to the early literature of OOP? Looks like the OOP edited his comment though, so my point is irrelevant.

jshowa1 8y ago

How has the church of OOP failed? Nearly every used language is based almost entirely on OOP. OOP makes organizing software and code reuse incredibly easy. The only real downsides to OOP is that its arguably slower and has more overhead. But that's only a problem in niche applications (ie. embedded apps).

std_throwawayay 8y ago
It failed by teaching that every data structure should be put into classes using many levels of inheritance, interfaces, encapsulation, accessors and the whole shebang when the thing really is just a plain old integer. OOP is really useful and powerful in many areas and applications but it is not the only tool that has to be used for everything.
- jpindar 8y ago
  That sounds like a failure of the teachers then, not of OOP.
macintux 8y ago
There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy. OOP-based languages are certainly more common, but definitely not the only game in town. Clojure, Erlang, Lisp, Perl 4, Forth, Fortran, Haskell...
simongray 8y ago
> OOP makes organizing software and code reuse incredibly easy. That is the big promise and the big lie of OOP. It, in fact, accomplishes the opposite. The medium used across systems today is data, not objects. Your objects are not compatible with systems across the wire, they need to be converted to data (JSON, XML, ...). They're not compatible with your data base, they need to be converted to data (SQL, ...). And if you want to use other people's objects (say from a library) you first have to make a layer that translates them for your own objects, since objects from other systems won't directly fit the model of your own object system, they always need to be engineered in. And if the objects are encapsulating data that you actually need, but doesn't offer ways to get it (private methods), you often have to jump through hoops to get it. Not to mention the fact that OOP often entails immutability which leads to problems while doing multithreaded processing. Clearly the answer is to use a more data-oriented perspective and use a programming language focused around data. Clojure gets it right and that's what I use. It's all concise functional code that skips all that class creation OOP loves, instead operating directly on immutable data (numbers, strings, maps, vectors, sets). I recommend watching some talks by Rich Hickey (the guy who made Clojure). They're almost all excellent.

pjmlp 8y ago

A specific church of OOP. OOP the Eiffel, Sather, Smalltalk, C+@, BETA, CLOS, SELF way isn't the same thing as most people learn in school as THE OOP. Just like there isn't a single way of doing FP or LP. Also lets not forget that all successful FP/LP languages are actually multi-paradigm and also include OOP concepts.

swagtricker 8y ago

>The great architect has the foresight on how the code will be used in five years and design it accordingly. Isn't he better off taking that crystal ball that gives him the foresight, using it to pick the correct lottery numbers and simply retiring?

pvarangot 8y ago
Predicting position and velocity of little plastic balls tumbling inside some rotating container is a very different problem to predicting the behaviour of future API consumers. Specially if those consumers work in the same company you do and have shared objectives. So no, he's not better using that "crystal ball" to predict the lottery.
std_throwawayay 8y ago
Many applications run maybe 10 times on real data and then their purpose is fulfilled. You don't need to design a microservice architecture with redundant servers when a simple shell script could do the job better. You need to foresee the scale of what you're building and how you would proceed to the next level. Some things must be solved right before the first deployment because you can never change them after the application is deployed. You must know what these things are and solve them right. You must also reduce their number ideally to zero if possible. You must use solutions that allow refactoring and later scaling in areas where your crystal ball is not sure. If the hard things are solved correctly you can use average workers to do the rest and it will work well.

grawprog 8y ago

I kind of like the way D handles oop. D gives you structs, classes and interfaces. Structs are stack allocated and have no inheritance. But are otherwise syntactically work like classes. Classes are heap allocated and allow single inheritance, unless the parent is an interface. Interfaces are similar to a class but it's member functions must be overridden. A class can inherit from multiple functions. I tend to use a mix of these and templates depending on the type of data i'm handling. I find it gives the best of whatever design pattern works well for different parts of a project without locking you into a certain paradigm throughout and still keeping everything fairly logical and coherent to read through and understand.

prophetjohn 8y 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?

Fellshard 8y ago
Consultant here, and I think that's a big blind spot we tend to have: we don't stick around for long enough to see the consequences of what we designed, usually.
- prophetjohn 8y ago
  I have more experience at startups than as a consultant. I was the 6th hire at a company that grew to 130 over three years and I was never thinking more than a few months in advance. A lot changes in five years — your customers, the competitive landscape. It's an enormously long period of time in technology. It seems like such a waste of time when you have customers that have real, unsolved problems today
  - discreteevent 8y ago
    Unless it's some one off batch process or a prototype, if the codebase doesn't last at least six months then it's unlikely to be something that makes any money. In my experience, badly designed code tends to become a net loss after a couple of months because after that time someone is going to have to modify or fix it.
ssijak 8y ago
Companies that are here to stay and plan to stay for longer, not the hipster wannabe unicorn type
PeterisP 8y ago
Probably every company outside the startup domain? If you're working on product-market fit, then you can expect to discard lots of systems, however, that's a niche and even startups are only temporarily in that position (unless they fail). For any business where there is a clear product-market fit (which, employee-wise, is pretty much all businesses) the systems rarely go away, they accumulate - if you're not a startup, or if you have found your product-market fit, then you expect that your products and processes won't disappear after 5 months or 5 years, and neither will the code that supports them, unless it's so broken that it's prudent to invest in a full rewrite. 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.

Koshkin 8y ago

> everything is made of bits Bits are objects, too...