3 ms·

Not all code is critical and intended to maintained forever. Everyone is not working at Google, Amazon etc. most code I write is not run daily by 1000s of users

by wwn_se 7y ago

Not all code is critical and intended to maintained forever. Everyone is not working at Google, Amazon etc. most code I write is not run daily by 1000s of users.

ravenstine 7y ago
Maybe there are just lots of FAANG engineers on HN, but it's amusing how many people overestimate the size and scope of the projects most software developers work on. There's so much discouragement and pessimism if a software wasn't written to handle millions of requests, or intended to live on for 15+ years. On the contrary, there's software written all the time that has a realistic lifetime of a few years before it's either replaced with a 3rd party alternative or rewritten by some disgruntled programmer. Deadlines and business priorities often mean that foregoing what most of us would tout as "best practices" actually makes sense. Some software is only used by 10 people at a time, and can be maintained by one or two engineers. It probably makes more sense for the engineers to choose what's best for them and the company over what most people would say are the right things to do. There are people I know who don't write tests for their software(something I don't know that I would ever do), but each piece of software they write is small and has a lifespan of a few years at most, and the advantage to removing barriers to development is that they can make changes very quickly and get things done.
- mesaframe 7y ago
  But, how would the developer know about the lifetime of the code. How would the developer know if code will never be extended or will remain stale for the rest of the life?
  - Cthulhu_ 7y ago
    Exactly this. I'm working on a codebase right now that looks like it was written by someone who had barely finished school, figured out how to use a function in JS to produce the HTML for an input element inside of an XHR response callback, then just kept reusing that over the next eight years leading to multiple >10K LOC files. I'm not sure the original author ever intended the application to be around that long.
- jamil7 7y ago
  Yes and no, I'm guessing most of us here at some point have inherited a codebase that wasn't intended to live longer than a few years or serve 1000s users but nonetheless has. I'm not saying everything needs to be overengineered to be FAANG scale but don't go too far the otherway either, think of the person who might inherit the codebase.
izacus 7y ago
But those two things are not related - my experience shows is that a giant amount of code WILL run forever. That quick hack you did? In production for 6 years. That quick "demo" you thew together? People will curse you for next 10 years. If anything, FAANGs have resources and intertia to actually work on technical debt. Smaller companies will just churn and churn and churn until they bog down into unmaintainable mess of a code and can't respond to market changes anymore because their codebase is impossible to change or maintain. Then they'll usually call us to fix their issue and be angry when the answer is "there's no easy way out of the mess you caused" while their competition is moving ahead of them.
commandlinefan 7y ago
But... why not just write the best code you can anyway?

by wwn_se 7y ago

Not all code is critical and intended to maintained forever. Everyone is not working at Google, Amazon etc. most code I write is not run daily by 1000s of users.

ravenstine 7y ago

Maybe there are just lots of FAANG engineers on HN, but it's amusing how many people overestimate the size and scope of the projects most software developers work on. There's so much discouragement and pessimism if a software wasn't written to handle millions of requests, or intended to live on for 15+ years. On the contrary, there's software written all the time that has a realistic lifetime of a few years before it's either replaced with a 3rd party alternative or rewritten by some disgruntled programmer. Deadlines and business priorities often mean that foregoing what most of us would tout as "best practices" actually makes sense. Some software is only used by 10 people at a time, and can be maintained by one or two engineers. It probably makes more sense for the engineers to choose what's best for them and the company over what most people would say are the right things to do. There are people I know who don't write tests for their software(something I don't know that I would ever do), but each piece of software they write is small and has a lifespan of a few years at most, and the advantage to removing barriers to development is that they can make changes very quickly and get things done.

mesaframe 7y ago
But, how would the developer know about the lifetime of the code. How would the developer know if code will never be extended or will remain stale for the rest of the life?
- Cthulhu_ 7y ago
  Exactly this. I'm working on a codebase right now that looks like it was written by someone who had barely finished school, figured out how to use a function in JS to produce the HTML for an input element inside of an XHR response callback, then just kept reusing that over the next eight years leading to multiple >10K LOC files. I'm not sure the original author ever intended the application to be around that long.
jamil7 7y ago
Yes and no, I'm guessing most of us here at some point have inherited a codebase that wasn't intended to live longer than a few years or serve 1000s users but nonetheless has. I'm not saying everything needs to be overengineered to be FAANG scale but don't go too far the otherway either, think of the person who might inherit the codebase.

izacus 7y ago

But those two things are not related - my experience shows is that a giant amount of code WILL run forever. That quick hack you did? In production for 6 years. That quick "demo" you thew together? People will curse you for next 10 years. If anything, FAANGs have resources and intertia to actually work on technical debt. Smaller companies will just churn and churn and churn until they bog down into unmaintainable mess of a code and can't respond to market changes anymore because their codebase is impossible to change or maintain. Then they'll usually call us to fix their issue and be angry when the answer is "there's no easy way out of the mess you caused" while their competition is moving ahead of them.

commandlinefan 7y ago

But... why not just write the best code you can anyway?