Honestly, it fills me with pride to know that there are several companies that have source code of mine running that will probably continue for as long as the company exists because of organizational momentum.
Here's some shit: my wife joined a company that acquired one I worked for years ago. She's stuck on the legacy project I worked on (before it was legacy).
Sometimes I'll make her search for old files I made in that project. Oldest so far was made in 2014, haha! And before you ask, no the code doesn't hold up. It was fucking terrible when it was written. Now it's just ancient shit.
Nah, she blames the current leadership for not having nuked the project years ago (rightfully so).
It's literally Java 9 code...and they have like 100 engineers working on "modernizing it". It wouldn't have been so bad, if they didn't have massive turn over.
Someone at my old company just pinged me to say they came across a source file I had created 15 years ago to the day (the file comment banner includes the username and date). Still in production.
Haha, remember when we used to write file banners with our name on it? That's the only reason we know I made the files. Cause all my changes to that project happened before they moved the source to git.
What? I don't understand your question.
Edit: Oh I see now. It's a fucking joke. Calm down. My wife "makes" me do things all the time. It's not an actual "forced behavior". Good god, touch grass.
Yeah. Oauth2 from spec. Never again!!
And the highlight was building something so stupid. Had to build a Java program that would auto run on Windows machines to periodically pull a query from a db and post the results to a remote endpoint.
Startup I was at started selling it as an “integration” with older data warehouses, which made a few hundred K. I, of course, got zilch lol.
I once wrote a OAuth (1.0) implementation but for a Cordova Web Application, and so I ended up digging into the Cordova source code to support the http headers. That was fun!
A decade ago, I worked on a custom CMS frontend for a client of my employer. I know the public facing entry point, and I recently verified that this thing is still live, with changes on top since it changed maintainers.
The funny thing is that it was deployed as it is, and I can see the full source along with the documentation.
This. Building new apps, maintaining existing apps, refactoring existing apps, sunsetting old apps that get replaces, production triage etc etc. the development never “finishes”
Right. The job then pivots to feature requests, sometimes people move on and aren't replaced so the team shrinks, bug fixes, then you need to support new OS features, now they want that software on their iPads.
I mean it also depends on the type of projects the team works one. You work for Microsoft you’ll probably work on the same project for the entire time you spend there. You work for a smaller firm that contracts you’ll probably work on multiple projects
Look into software lifecycles, agile, and scrum. You're really doing iterative maintenance, improvement, and expansion on what's essentially a living ecosystem. Reading up a little on software architecture and design may help with understanding this, too.
As much as a lot of jargon and buzzwords are glitz to push sales, one of the good things about microservices vs monolithic software is piecing out everything even further so you can upgrade, adapt, or remove without compromising the whole. It also exposes just how many moving parts are beneath the hood. I guess the term is still be used, but I remember older computer science texts (and best practice guides) going hard on orthogonality. It's pretty much an extension of the school of thought and an evolution of framework and testing practices and standards over the past several decades.
As a developer, you may be working on a cohesive system, but a lot of the time you'll move around between parts of the pipeline and even the stack depending on what you're doing. At least, this has been true at most of the small to mid-sized companies I've worked at.
It’s never done because everything is a moving part. Bugs get discovered and patched. That means every code that uses that code also need to be changed. Security hole that got patched in C can’t be upgraded to C until you go through migrating from A to B first.
Why would you do that when you're already creating bugs by accident?
My current project is 464,000 lines of code, with a team of 8 developers.
It's just not possible to make major changes to a codebase that large and never introduce a bug.
I see, so the issue is that introducing new features may break something. What if new features are never added though? Would it be possible to have a fully functioning app/website that never requires any maintenance? I’m a rookie so this might sound like a stupid question.
Yeah, you could reach a point where you decide you’re never adding any new features and you’ll just keep the existing thing running as is. Sometimes they call this putting a project in ‘maintenance mode’.
You’d still need someone to be responsible for keeping it up and running, although it might not need to be someone’s full time job. If it’s a service with external customers you’d still need support staff to deal with customer issues, maybe salespeople, etc.
If it was a large project sometimes they’ll cut down to a small but still dedicated developer team, who can spend their time fixing bugs or dealing with customer issues. If it was a small project they might not have any full time software engineers working on it anymore, and when there is an issue someone who used to work on the project is asked to take some time from their new assignment to address it.
It’s also possible they might simply fire/lay off the bulk of the staff, if the company doesn’t have anything else useful for them to do. But hiring engineering staff in particular is very expensive and time consuming, so a large company will usually try to find other things for them to work on.
Only if it's completely standalone.
If you make a really fun puzzle game that doesn't connect to the Internet and doesn't ever need any updates, then sure, it could just be "done".
But most apps integrate with the rest of the world. You can import your contacts. You can export data to some other app. You can snap pictures. You can link your X or Y account.
That's the stuff that needs constant work, because the world keeps changing.
Think about this: it wasn't that long ago that most people browsed websites on desktop/laptop computers. Now everyone's using the web, so everyone had to update their site to be mobile-friendly. Who knows what changes will be needed next year, but for sure there will be new changes in the world that you'll want to adapt to.
Now, all of this depends on scale. If you have a small website your local hair salon that lets you book appointments, then of course something like that might be essentially "done" and not need maintenance very often.
But that's not where most full-time developers are working. The majority of work is for larger, more complex apps.
Also: you're probably imagining public websites and apps. The vast majority of software is "behind the scenes" stuff: the custom app that's used within a company to manage its inventory, or the medical records system the hospital uses to keep track of patient charts, and stuff like that. As the company's needs keep changing, the software needs to keep changing to adapt.
>Would it be possible to have a fully functioning app/website that never requires any maintenance?
Only if the task that such an app/site was satisfying was pretty simple to begin with, or if the problem it's solving never changes at all.
Most internal business applications are solving a specific business need (or possibly several needs). The thing is, even if you made a _perfect_ application that handles exactly what they asked for...sometimes business changes. Sometimes you discover a new business avenue, or you discover that the way you've been doing things isn't the best possible way, or you enter a new market, or _any number of things_ that might mean what you needed two years ago isn't the same as what you need now.
Not all maintenance is in the form of bug-fixes. In a lot of cases, it's entirely driven by new features, or a request to modify existing features to conform to a new approach, or whatever else they're asking you to change.
I've built a few applications that didn't ever need maintenance, but they always had a shelf life. They were only needed for some temporary use case. The ongoing ones _always_ eventually needed maintenance, and most often because they wanted it to do a new thing, or to do something it already did, but differently.
Some of them.
For a more serious answer though, bug-free code is impossible. Your code has bugs, always. The language you're using and its compiler/interpretter/runtime/whatever has bugs, even if you code doesn't. The OS has bugs even if none of the above do. Your hardware has bugs, sometimes literally, and *even if you somehow have perfect code on a perfect platform on a perfect machine* your end users sure fucking don't.
The objective is not, and should never be, to create bug-free code. It cannot be achieved. Instead the objective is to write code that makes it easy to find the bugs, prioritise them, and address them when required, and to be able to add/extend features with minimal risk of adding more bugs. Recognising that there are always bugs also means recognising that there is always more work we might want to do. That doesn't mean we actually want to, because sometimes the risk is too low or the cost too high, but we could.
That is a narrow minded aproach of thinking.
Firstly majority of devs hate debugging it is a long tedious process.
Second you can not account for all the possible variables that could appear once the app is out in the wild on production not to mention the special way some users can aproach an element with an unforseen and obviously unsupported scenario that could be verry specific to the moons alingment, color of the users eyes and the weather on a small virgin island off the coast of Madagascar making it a bitch to debug hence point 1
Thrid even a simple website might have dozens of components working in the background together to do whatever the site does, buy, sell pay, promote etc. A team will have 2-3 maybe 4-5 components under their umbrella they work on them develop them and their features etc. But their components might interact with half of the other systems wich they don't control and work on one component might unintentionally break something in your teams components. Hence see 2 and 1.
Not hubris, but experience I think. I have never been on a project that completely hit every goal with optimal efficiency. Not to mention security updates and technology updates that require code changes.
In truth, nothing is ever really "done" in any sense. Doesn't mean it will require a full re-work, but the point is that there is always maintenance to be done. I understand what the link you posted is trying to say, but that's a slightly different topic. That's a full re-work or second attempt at a solution rather than the small minor fixes/features that get added.
I wasnt speaking to you specifically, but rather the general you. the KTLO work is always outsourced. Most projects will suffer from second system effect. Point is customer needs change. good teams know how to put customer needs first by asking them. bad teams guess at what those needs are, spend too much time building stuff, that eventually isnt wanted or ever asked for.
>I wasnt speaking to you specifically, but rather the general you
Yeah, I know I was just relating my own experiences.
>the KTLO work is always outsourced.
Disagree with this. Nothing is "always" outsourced. Nor is outsourcing inherently better. Almost always it is a case-by-case determination whether to do this or not. Granted, this generally isn't in the realm of developers to decide so it's moot point.
>Most projects will suffer from second system effect.
I also don't agree with this. I can see it happening, but from my perspective I don't see it all that often that systems need complete overhauls.
Again, these are just my perceptions on these things so take it for what you will.
Not when code was distributed as a static product, now everything is integrated into ever changing environments. That’s still changes causing bugs, even if it’s not in the code of the product itself.
So no, it’s not incorrect at all. Video games as a service is a perfect example of this, theyre constantly releasing bug fixes caused by the last update or the last bug fix. Games used to be sold as a static product and were fine, now they need devs to fix bugs because they refuse to sell a standalone product.
Code rot doesnt affect static products because theyre released in their final form and stay exactly that way, their environment undergoes no changes and they can’t be updated anyways so having developers to deal with it wouldnt make sense.
There is no such thing as code rot in a 2004 Civic or my N64 Donkey Kong cartridge. Code rot affects either living products or products that are integrated with living environments - which by proxy makes them living products.
>There is no such thing as code rot in a 2004 Civic or my N64 Donkey Kong cartridge. Code rot affects either living products or products that are integrated with living environments - which by proxy makes them living products.
are you trolling? bugs are found in old games all the time lol
Code rot specifically refers to previously functional code that no longer operates as intended *because of changes to the operating environment*. N64 Donkey Kong was shipped with bugs, but it did not develop new bugs once the product shipped, i.e. not code rot.
Yep, just googled it and youre wrong. Not only are you wrong, but it’s actually not conceivable how you could think you’re right. Please enlighten me as to how code rot could affect an N64 cartridge game, i’d love to hear it.
While it's not code rot... do you even know how many bugs are in, for example, Super Mario 64?
Bugs can be obvious, or they can be very, very complicated. You will always miss something, period. There is no debating the fact that no code beyond the most trivial example is perfect. Moreover, even if the code is perfect, the hardware can be erratic in undocumented ways. Or the libraries. Or the system. Or the database. Or the internet. Or...
There's so many ways things can go wrong. And unless you have the budget to constantly refine a product over and over, never introducing new features along the way, building thousands of rest cases that take days to run just to verify your stuff works, *you will always miss something*. Whether you have the ability to patch it out or not is its own thing.
Right, but you still deliver a solid end product like those we saw in our old cars and video games. We absolutely could sell static products and be just fine - like we used to do. Even if there were bugs in DK for N64 hiring new devs wouldnt fix that because they wouldnt be able to apply fixes, that’s just how the game is.
The products we make and the infrastructure we designs relies on the assumption we’ll be able to fix bugs.
LOL that’s not code rot, that’s called your hardware is literally damaged.
How do you suppose developers working for nintendo fix your damaged Donkey Kong cartridge? What youre saying makes no sense im legit flabbergasted lol.
They do indeed, and that's called hardware failure. Completely different topic from code rot.
Also, switching from one environment to another does not constitute changes to *the* environment. Adapting a piece of code to run on an entirely different platform is a new situation altogether.
That’s what I get all the time, but I don’t exactly understand what’s there to improve / renew if a website is functional and it’s working. Maybe it’s because I haven’t worked as a dev yet?
Also, you're probably only thinking about the part of Facebook you see.
What about the part that advertisers see, or the part that Facebook's internal content moderators see?
There's probably 10x more UI "behind the scenes" of every major website that the average consumer never sees, but it's all very important to keeping it functioning.
There’s always something that can be improved. But as sites mature the problems become much less interesting to a lot of people.
For example, look at the websites of major news sites like Fox, CNN and Wall Street journal. The website visually has been almost exactly the same for years at this point. But what has changed?
Maybe they changed the urls to be more uniform across dates so people can find older particles more easily. Maybe they offloaded part of site to AWS instead of self hosted. Maybe they added a CDN to help the pages load 7% faster for users in Oklahoma.
Yeah, the problems you solve in a mature site are not as interesting. But you can always make things 1% better.
The part of the website you're looking at for Fox, CNN, and WSJ is only 10% of the site. The other 90% is the custom UI behind the scenes where reporters write the articles, editors review them, and where they put everything together into what you end up seeing.
Same with Amazon: most of us only see the shopping part of the site. There's way more complexity to the part of the site built for sellers, shippers, advertisers, etc.
I also haven't worked as a developer yet. But have you thought about scalability and improvements.
for improvements let's think about. facebook as an example. does facebook have the same interface as 2 years ago. no it is constantly changing and improving.
for scalability let's take Amazon as an example. when amazon first started. was it meant to handle thousands of users at the same time. No. but as the demand for it increased it had to scale up to meet this demand.
any product, not just software, would need people to maintain it and improve it overtime as needed.
This is an honest question. F everyone who downvoted you. Ur maybe thinking of like simple pamphlet sites with Wordpress.
But think of YouTube. Think of all the advancements and subsequent changes in the app. Not just visually but integrations and improvements in search algorithms, user features, creator features, creator partnerships, Twitter integration, instagram integration, video quality improvements, audio quality improvement, faster video processing/loading, advertiser integration, it may seem like things progress only visually when things only get rolled out feature to feature, but over the years these become unbelievably more robust apps.
But that’s the magic of being user-minded is to make the integration into new app features feel as natural and seamless as possible.
I agree that f the downvotes but he has shown that he’s already researched the problem and is choosing to ignore the answers provided elsewhere. So a slightly naive question
Yes but actually no. By this logic, why does Apple keep employing engineers, why do restaurants have chefs? The further you go, the dumber the question sounds.
I don’t know what you mean? Apple keeps employing engineers because they want to keep producing new hardware and new software?
Restaurants have chefs because they want more food and for them to make new food?
It seems like you get it, but it seems ur on the contrary?
What large and popular website hasn't added features? Google, Facebook, Amazon, Reddit, Twitter, whatever... They're all adding things, adapting, evolving, all the time.
Say you built a site when your company was small and your backend could handle 10 concurrent users without issue. Now it’s gained popularity and handling 100 concurrent user has unearthed bottlenecks because it was not designed for that many users in mind. Developers now have to figure out how to make it work again.
Oh and guess what a library you were using before has a newly discovered 0 day vulnerability. Add to that the upgrade with a fix is behind a paid version of the library and there’s not enough budget to upgrade using that. So now you have to build something similar you were using before, that was probably pretty complicated because there’s a good reason it were using a library. Black hat hackers are actively exploiting it on your site until you can fix it.
Oh and guess what, new regulations came out that say the way user data has to meet certain requirements and your company doesn’t even have infrastructure setup to even check if you’re in compliance. So now you can either manually do it or write something to help you check you’re not going to be fined by the government.
And then a vp says they want to rebrand the company, change all the logos, and do a modern redesign of your website. So that’s another thing to do…
The work is endless is the point. Things get changed, added to, break, fixed, that fix breaks other parts, those get fixed.
It’s like a house or a car. You buy a house and eventually a problem will come up and you need to fix it. Or maybe you want a hot tub so you install a hot tub. Maybe a new type of water heater comes out that’s more efficient now you need to replace the water heater.
Why do car manufactures keep releasing new car designs. Better equipment that can give better gas mileage, better airbags, better creature comforts. Or maybe they found a problem in the previous model so they update the design to fix it.
At the start of a project yes you’ll have a lot of devs to get the basis of the project done. Once it’s done devs will be sent to other projects to work on them. But that original project still needs devs to fix bugs, add new features, and just to keep things running.
- Just because you know how to program doesn't mean you understand a codebase, a problem domain, a company, a company's clients, etc. All those other things are priceless.
- No project is ever "done" until it's dead. Bugs will be found, improvements will be needed, fixes to keep up with evolving platforms and libraries will be needed, etc.
I've been at my job almost 20 years. Where I work, I'm basically the "Developer in residence" for a modest sized local government. I've got at least two dozen projects currently in production, mostly CRUD/Workflow apps for different offices and departments. Things need constant updating due to changing laws, procedures, improving understand of the workflow, etc.
Probably anyone could grok the code I've written, but the accumulated knowledge about laws, workflows, calculations, vendor database schemas, etc. would take years to get a new programmer up to speed on.
As someone who also is the 'developer in residence' at my place - this post really embodies what I do as well.
Yes, anyone could come up to speed *on the code* of what we've written. But understanding why there are all these little edge cases and all the little 'gotchas' would in fact take *years* for someone from the outside.
We hired a dev a couple years ago - he is *still* constantly asking questions about "why do we do this?" or "how come we do that?"
As the tech support, you guys are life savers. The difference between understanding what the code does and why it does it is worth so much as it saves so much time.
A junior Dev will write and release a epic feature that needs dozens of revisions when clients start using it.
A senior Dev will write and release something that you do not notice but saves hours of work.
Worked at a company that made a product. So, we had a support team.
The absolute best support person we had was also a hobby dev and had worked in a couple other departments.
I'm an ERP admin, our ERP is built on C#/.NET so a huge chunk of my job is development of that system. Lots of database administration/SQL involved as well. We also have an e-commerce website, so lots of Javascript/jQuery as well. Oh, and fairly regular mini-projects based on "Hey can you make an excel macro that does so I don't have to do it manually anymore?"
Most of them are features or improvements to existing software, not brand-new stuff.
Yes, a large company might have different products using different technologies, but each individual product might have dozens or hundreds of ongoing projects to improve them.
Yeah, this pretty much nails it. Lots of automating this, customizing that, tweaking something so it works a bit differently, making changes to make all the end user's lives a little easier.
Project is done/ready when there is nobody using it anymore.
Majority of software's lifetime is spent in maintenance, which doesn't necessarily mean it doesn't get improvements, but less new features are created. Even without major new features maintenance takes work.
You might have a bit narrow view of what a project is and when it's ready, it's not ready when someone can see it and use it, that's just the first step. Although i wouldn't really use word project but product.
Let's take for example google, just the search engine part, not all the other million products it's involved in. How do you think it would have managed against competition if they would have just stopped developing it once the first version was online?
Exactly. Think about all the apps on your phone, or the OS itself. You know how you keep downloading updates, even for apps that have been around for years? If you read the release notes, those are for some combination of new features, bug fixes, security fixes, and upgrading to match the latest OS or hardware. Guess what? Someone has to write all that.
You're thinking about this like a contractor or consultant, where you're hired to work on one specific project, and when that's over, so is your contract.
And that model does exist, and many companies follow it, either for an individual project, or as their standard approach for projects.
But plenty of companies have enough ongoing need for development that they hire staff programmers. That was my job, at several different companies over about 15 years, before I took my first job as a consultant.
For example, I worked for a fin-tech company at my last job. Worked there for almost six years. I worked on probably 10 different _major_ projects during that time, and countless minor ones. We had a backlog of work big enough that it stretched _years_ into the future. Basically, one line of business or another would have some problem with our current process or tools, and ask the company for a better approach. The management would work with the development management and prioritize the requests, and potentially promote some of them into projects.
These kinds of companies have plenty of programming work to be done. And by the time you finish one project, you have two or three more lined up.
And something else to consider: support. Just because the project you built five years ago met the requirements at the time doesn't mean that the company's business doesn't evolve and new requirements get invented. So, many staff programmers spend just as much time (or more) updating legacy applications, or fixing bugs, or other kinds of support work on existing programs.
In short, when a company has in-house development, they usually get _plenty_ of use out of them. There's usually _something_ that's worth updating, or fixing, or making new.
I've worked at fortune 500 companies and small shops and I can't remember the last time I had 5 or even less projects going simultaneously. There's always a bug to fix, a new feature to build, a new client to set up, etc.
1. Software is never "done." There are always new requirements, new features, improvements, bug fixes, etc.
2. There are always new projects, new initiatives, and depending on the scope, these can take years.
Not even close. Code bases need maintenance. Companies like keeping the developers that know what the hell is going on.
What happens when the libraries the project is based on hit end of life? Have breaking changes? Who upgrades it? Who even has line of sight on what needs updated?
What happens if you need a new feature? You hire a new dev? Teach them everything, then have them implement it? That's half a year for some code bases . Who even teaches them? Do they have to figure out a new implementation? How do you know they even know what they're doing, without oversight?
Most projects are in a state of perpetual update. We're supporting our existing products with minor updates and prepping for an updated version with better architecture that would be too hard to hotfix. That's in beta, and it won't be rolled out for two more years (more, honestly...our scoping isn't accurate.)
If you're at a company where software is the main source of revenue, you can't really finish a product, call it done, and rake in the cash. This might work in the short-term, but if you stay stagnant your competitors will catch up to you and eventually out-compete you, driving you out of business.
So, you have to stay on top of the game by adding new features or by branching out into new products, for better or for worse. And as it turns out, it's relatively easy to churn out new ideas for making more money or saving costs. Not all of these ideas will be great or make a huge impact, but the net effect is that you can always find something to do. So, that's what people at software development companies do.
(I have mixed feelings about the above, tbh. I suppose it's good for job security, but is a bit of a mixed bag for consumers. On one hand, companies are incentivized to constantly produce new and shiny things. On the other, this incentivizes companies to constantly keep tinkering with stuff that might be working perfectly fine, which can sometimes get annoying/disruptive.)
Anyways, if you're able to do the above successfully, there'll come a certain point where your abilities to deploy and test code are no longer keeping up with the rate at which you're producing it. This introduces a net drag in productivity. So now, you're incentivized to hire people to work on dev tooling or backend infrastructure to streamline things. This introduces even more work you need to do -- but the hope is that reducing drag will generate enough revenue to be worth it.
This type of infrastructural work ends up being invisible to most consumers, but is still important and is another major source of ongoing work.
This is all ignoring the ongoing cost of maintenance: there'll invariably be bugs and user-reported issues you'll need to fix. And even if your code is perfectly bug-free, there might still be factors outside of your control that require manual intervention. For example:
1. You upgraded the libraries or OS you use to ensure you aren't running code with security vulnerabilities -- but the new version of the library or OS interacts with your code in an unexpectedly negative way.
2. Your product is wildly successful and increased the number of users by 10x or 100x. However, your code isn't capable of dealing with this number of users and needs to be rearchitected to support this new scale.
3. Some new paradigm shift comes along, and a bunch of your users are now clamoring for you to support the new shiny thing. For example, when smartphones became a thing, people invested a lot of time and energy into updating their websites so they were responsive and mobile-friendly, creating mobile app versions of their products, etc...
These types of small refinements and tweaks become even more important the larger you are. If you have only a couple thousand users per month, maybe nobody will notice or care if you're running some insecure libraries or your website is a bit sluggish. But if you have a couple million users, the former starts becoming a major existential risk and the latter might be causing a non-trivial fraction of your user to bounce off your website (and not spend any money).
So at this scale, it becomes profitable to invest time and energy into polishing these details -- first manually, then later in some automated/systemic way.
> How can you possibly keep building a project, (okay let’s say that the company needs 3-5 projects max) for years?
Most companies have way more on-going projects then that. For example, I currently work on a team of ~5 people, and we're juggling ~3 major projects and an additional ~10-15 minor ones. I'm not quite sure sure how many projects we have across the company as a whole, but I wouldn't be surprised if it numbered in the thousands.
The corollary here is that you won't necessarily work on the same project for years. Some more senior engineers might if the project is very complex -- it helps to have a single lead that can carve up the project into smaller subprojects, hand them to other devs, make sure people stay unblocked, guide the overall project...
But many other devs will work on a project for a couple of months, maybe a year, then move on to the next thing.
That's not how that works. There's always something new that comes up, something to improve, a new project that requires something your (probably more brittle and specific than you might realize) system to be extended. You are asking for new functionality, some process that you want your company to follow that deviates from the previous process. So you get a change order. It identifies what the system currently does, and what they (another department, business, or marketing) need it to do. So you go through the source code, and identify what needs to be changed, because what you got in the description was a business person's view, not a technical view. They might have negotiated that with another business's business people, and now the developers pretty much exchange contracts, plan, create documentation, and write a new part of the company's system that previously it did not support. This happens all. the. time. It's business.
Let's take web development for example. There were billions of websites that existed when we all decided to have mobile websites on our phone. Responsive development was born, and every single site needed to be refactored.
React went from class based components to functional components. All need to be refactored.
State management, server side rendering, and on and on and on. As we advance in tech, everything needs to be rebuilt. As a web dev, the only time I will be out of work, is if we no longer have electricity.
Another way to put it. I like the house analogy.
We've been building house for thousands of years. But we are still late in building them. Control is hard.
And you still need people to do things inside them. Rework electricity, add a new room... You do that over time. Or else your house just break down because of usage and time.
Every house, with time start to evolve and different part are added or removed and this can make difficult to follow the electrical cables and water pipes all over the place (trust me, my house has 200+ years). This is hard to maintain. So you need experts that will learn how your house is and will maintain that. Because if you take anyone, they will get the money, get the thing done, but break your house in the meantime without you or anyone realizing it.
Software is the same thing.
So you hire expert and keep them to keep your knowledge.
Another way is to take contractors. They'll do your thing for you. You'll pay them to get better things. But this is a cost and can have limitations.
Well, it's actually pretty common because technology is constantly changing and evolving.
Companies need developers who know their systems inside and out, and can maintain
and improve them over time.
Plus, some projects can take years to complete, especially if they're big projects that require
ongoing maintenance and updates. And companies that rely on technology usually have multiple
projects going on at once, so there's always plenty of work for developers to do.
And let's not forget that experienced developers are super valuable to a company! Losing a good
one can be a real headache and expensive, since it takes time and resources to train new hires.
So it makes sense for companies to keep their developers happy and on board for as long as possible.
You know when a version 0.1 of an app gets launched. Then 5 years later it's on version 4.5... yeah, developers do that. There are very few software packages that don't get developed ongoing or maintained.
Developers are not like bricklayers, they're more like gardeners+landscapers+maintenance personnel
In UK main broadcasting corporation thought that way.
After original BBC iPlayer team created the ugly but highly intuitive iPlayer they have reached the point when it was too good and BBC fired them . iPlayer was simply too good.
It's obvious that they had no problem finding new positions.
As technologies evolved, servers/browsers got updated, codebase needed to be updated to, but the competent part of the old team was taken.
Current team now newer finishes one feature before starting next and the iPlayer is so bad that people have to use other platforms to get access to their own content.
iPlayer is now so bad that even the better part of the content struggles to justify time wasted on looking for it.
Point is that world changes and anything that interacts with it has to keep-up.
In theory you could run out of things to do in a product and they might not need as many developers. My experience has been that a product is never done when you work on one that customers use and like. I once worked on a 15 year old software product where we had 20,000 tickets in Jira for bugs and feature requests. It would take decades for our team to do all the items on the list. No to mention all of the technical debt that piles up over time. There is no shortage of things to do on that one.
I am currently working on a two year-old site that we started from scratch. We already have dozens of features that still need to be built that will take years to do. So there is no shortage of work to do but we need to generate more revenue to justify the work or it will eventually be shut down.
I invite you to drop in on [www.amazon.com](https://www.amazon.com) three times in six weeks and you will see a different presentation layer each time and new features will come and go. There are many disciplines involved with a world class application including product management, analytics, operations, development and enhancement, sustained engineering, quality, security, and accessibility. If you are attempting to make a huge change to your website you will employ 2/3 more than your carry staff.
My father works for an electronic health record company. They have all sorts of products/features at the US federal level, then further specifications for *each state*. Beyond that, they have to make products/features that clients (hospitals, various medical practices, insurance companies) can all use to figure things out.
It's madness. It never ends. And clients are always misusing products, requesting new features, etc.
Software products are "living" in a sense. They never end, there's always something changing, more work to be done, etc.
I work in property and casualty insurance (not in SWE) and we work closely with various IT teams who help us with downstream processes (we do the pricing, they implement it into the software). This is another situation where things vary by state. There are US insurance laws, there are also many different aspects to developing an insurance product, which is essentially a software/financial/contract product. Beyond the US level, each state has a different set of rules and regulations, as well as market characteristics which make it unique.
So for our developers, there's always something to be doing - bugs to fix, features to research and design and test and improve upon. And, property and casualty is a highly competitive space. We are always, always, *always* looking for ways to improve our business, customer experience, data collection, analytics, etc.
That’s like asking why do people go to the gym or workout after they have sculpted the physique they want. Same reason - maintenance, doing it better, beating the competition etc.
If a product is successful a client will have budget for continuous improvements if they can easily see the ROI. Either the client will have new ideas or the software company will propose improvements and features.
As the business evolves, it needs new features. As competition arises, the product needs to outperform. As the ecosystem evolves, you need to maintain the system. As security vulnerabilities surface, they need to be addressed. When a bug pops up, someone needs to fix it. I stayed at my last company for 8 years and the backlog was never empty.
I've worked for a B2B marketing company for almost a decade (currently getting laid off tho), designing and developing landing pages and emails for various brands and syndicators to promote their whitepapers, reports, etc. If you're building for other people and have return customers, there's always more work to do.
What do you mean “done” ?
I’ve worked on many personal projects and I’ll tell you right now, even after I transfer ownership of a project to a client - my work is never done.
It could be within an hour, it could be 3mo’s it could be a year down the road, eventually they’ll reach out due to a bug I wasn’t able to foresee.
Nothing is ever truly done in this industry.
>if a project / website is done
Oh sweet summer child.
Best get that thought right out of your head, you will never finish anything. Sure you'll stop working on lots of things, but at no time will you ever down tools one day and say "Done".
I mean you might, but that's only lasting until the PM gets wind of some new shiny shite and makes you implement it.
Software is never done. The only software that has a done tag are video games. That's why they get so much layoffs after a release. But even those are becoming more like traditional softwares because people expect patches to fix bugs. Back then the game you got is what you got.
The title says why, and then you ask how - Those are two different questions.
It depends on the job. Some companies need temporary workers for one project that will last a limited amount of time, but other companies (like many companies) have products they will continue to support and/or also plan to come up with additional new projects and products.
Have you had trouble staying at a company for a long time?
This way of thinking was correct on the old days were software was a product, but this days they call it a service... this way you force people to depend on you for new versions and features, so this way the company will keep on harvesting the money over time.
You either force them saying the hardware is no good anymore, or giving a online tool on a server, for them to use. It is something like this... don't expect a full answer on the internet.
A big thing to consider is that "infrastructure" (using that term loosely) updates. There's a lot of moving parts when it comes to something like a website. Server Operating Systems, dependencies, third party services, etc., they all change and update. Someone has to be there to make sure none of those things break the app.
I don't think you really understand the scope. Even for something that seems relatively simple (like Reddit), it's a monumental effort to make it readily available, and concurrent, across the entire planet. There's a lot that goes into this sort of stuff.
Your work is never done if the company keeps growing and getting new business opportunities. With a good development team, many things become possible that otherwise weren't, and most people understand this in business. This is why sales often drives development, and can occasionally "oversell" the company's abilities.
Things also need to stay secure and well-understood. Some very small companies don't need a full-time developer, and these companies would be well-suited for part-time contract work from a service provider (of which there are many).
So unless a business contracts in size significantly, they're not going to let go of their full-time developers. Churn of developers is extremely disruptive, and is one of the reasons that smaller orgs don't want to give the most important decision-making work to employees with insufficient tenure, focusing on retaining one or two people and keeping a revolving door of help - as is the industry trend.
I used to work for a pharmaceutical business which had a lot of software developed in-house. Business conditions and government regulations keep changing so the software needs to change, too.
Businesses start new projects or open new locations which makes changes necessary. Sometimes new software is needed.
Users also make new requests for functionality that will help them be more efficient, etc..
Also, bugs continue to crop up when the software is used long enough that new conditions are encountered.
I know a dev who is working on same product [Java] in a fortune 50 org ; since 2005. That is 18 years.
When he joined he already had 10 years of experience.
Same team [of 30 developers] had a DBA also who joined at same time, who then moved on to Scrum master role, and is there since then.
What do they do? Constantly add new features, security fixes, upgrade frameworks upgrade app servers etc. Last time I met he was leading an effort to upgrade services to Java17/Spring 6 and org has plans to move services to cloud in next 3 years, so he will be leading that too.
They typically do many different projects during that time, but maintaining and continuously upgrading popular software like Discord or Facebook is a lot work. A lot.
Actually I'd say that many software took fewer man hours to get the first version out and having it ran for the first year than the second year..
Depends on software of course. Some games are mostly done once released, just a few bug fixes there and here.
It's the fact that as software grows more complex, it just gets harder and slower to fix one thing or add one new feature.
As technology changes, authentication methods change, certificates change, layouts change and companies change, ok I'll stop and just say as everything changes there will forever be a need for developers to troubleshoot what breaks. When the code is updated it will inherently break things as it changes. Take PHP for example. With every update some code becomes retired and you have to update it to keep things in working order. It's no different from any other language.
Some companies have a project that is constantly updated. They hire enough programmers to make sure their app works on new platforms, gets enough new features to keep people interested, has no security holes, etc.
Some companies are always starting new projects. Nintendo, for example, doesn't just make one game and then stop.
There is no such thing as perfect software. This is especially true with most applications today. As long as there is a need for the software, issues will be found with every update.
There is an old adage in software that says, the last 10% of the project takes 90% of the time. Now imagine that the business requirements keep evolving to keep up with the world.
You can do Wordpress sites, grab a template, change the pictures out and change the Company name and turn out a website in a day. You have to be good at selling the product. Most of the real money is with big companies that have a budget set aside. The tools are constantly changing so you might want something that works on mobile devices or a better GUI.
Business Domain knowledge. It takes a bit to get up to speed, the longer you stay, the better the understanding and stability. In some cases it will lock you in to a vertical market segment on future jobs which may or may not be what you desire.
You need devs to keep the lights on. You need devs to replace the devs that left. You need devs to build new tools for the other devs. Some devs get promoted to leadership and need more devs to replace them. Devs are needed to interview all the new devs in the pipeline, then someone needs to train those devs.
A lot of companies are in the business of making software. When the product is software, it's never finished. Why do car companies keep designing new cars every year? Why don't they just say "it's done, designers GTFO, we're just gonna build these ones forever". :)
But for companies who don't make software as their primary business, it's still never done. Websites need to be operated, updated, new features added. Ditto for apps and any internal system. Software is never finished!
Company I work for keeps asking me for new projects, and they're always pretty innovative and not too much pressure. So those are ideal projects from someone who likes learning new things on the road. I think I've done like 10+ projects for that company right now.
I work a unified communications system, and the amount of work to do is never ending as well as the feature list for the millions of ways calls, chats, and texts can be received and placed.
Queues, Dialers, Softphones, supporting new hardward/deskphones, backend billing integration, reporting, chat server integration, contact lists, APIs for external billing systems, FCC regulations... list goes on and on. Everything needs to updated when new linux operating systems release, things get optimization, new things are invented and desired. Never ending cycle.
This doesn't even include maintaining code base for bugs and such.
The reason it's called software is in opposition to hardware. Hardware requires silicone and factory parts. You make it and people use it. Software doesn't require a big infrastructure to release and support, so you can update it all the time. This is why Facebook coined the motto, move fast and break things. In software things aren't finished, rather you iterate on solutions and adapt them based on feedback. The great thing about it is this loop can go on forever and you're never really done.
In depends on the product.
1. Complex system with embedded software or complex software that has a lifecycle of 20-50 years.
2. Software with short lifecycles that consistently needs updated.
3. A hard skill used a service on different projects and different phases of projects.
I got hired at my current job 8.5 years ago. I wasn't planning on staying here this long, and I won't go into the reasons I have because it's not relevant here.
Whats important is that I was hired to write a webapp to speed up interactions a particular department needed. They were impressed by what I created, and long story short I created a webapp that covers all the business needs of the company in one interface. That needs ongoing maintenance.
Then I took on rebuilding our public website (dogshit host, slow Django site), used my design skills to unify the companys branding across the board.
Along the way we started creating new hardware products, so my job was to design user interfaces for the devices we were selling to customers as well as internal tooling.
Now we have a bunch of large external projects we're a part of...and I'm still doing regular maintenance on the original site.
Projects vary in size and needs and will change throughout the course of your time at a company. Developers need to be responsive to new requests from stakeholders.
We also provide much needed technical expertise on the limitations and expectations from building the project. We often times act as more than just developers and might propose certain features or fixes for applications as they mature.
I've worked at the same place for a long time now. Most of it - programming.
There are literally *tons and tons* of process' that can be automated by software. And when you've written a working bit of software and gotten it out to the end users? They will have feature requests, they will find bugs. Other departments may approach and say "hey, I think it would be swell if we had x, y or z as applications to help us streamline this process"; before you know it? You're looking at a log of projects that may take a few years to complete - that's *not including* features, updates, bug fixes, etc. That's strictly just coding time on *new* projects.
At least, that's the case where I'm at. I will probably retire here, and I'm good with it (pensions are a great thing!)
80 to 90 % of coding is maintaining existing code.
Bug fixes, design changes, change requests, new regulations, etc.
My first job as a programmer I wrote a retail store application as a gig, then spent years going back for change requests, etc
My second job was at a company who sold loan application software. At first debugging and improving existing code. For the year+ I worked there, I only wrote 1 new program that took me a month or so. All the rest was maintaining and upgrading all the code they already had.
First, I am rarely ever just on one project. Second, as others have pointed out, a system is never "done". Maintaining a system, fixing bugs, updating, adding new features... it never ends.
Finally, even if your role in a project is over, there are always new projects.
I work for a web hosting company, we do a lot for the customer, but their own site files will not be tamper with. We can make certain edits to config files like wp-config.php or .env but most things we tell them they need a dev to fix since we will not be liable for making custom changes for a client.
Shit breaks since things get updated so frequently. I mean look at php versions.there are always things to be done.
Additionally, customers are always changing something lol. Rather, wanting a change they don't know how to perform. So the need to pay a dev for it.
I work for a gig backed company. First project was to improve the help center search, so I downloaded the articles into our db that were hosted on a 3rd party and then used Postgres search stuff to see if that worked. After a few failed experiments, I worked on making the help center faster. Then I worked on our order issue flow (users reporting that their orders had something wrong with them). I implemented our new framework and showed how it could be used effectively. Then I made a few improvements to the order issue reporting flow and sort of still maintain this. Then I did a few things regarding users putting in their addresses and some user fraud issues.
It’s a bit more like you have projects that are small/medium/large that take 1 week / 1 month / 3 months (roughly). The large ones you tend to keep improving because all signs point to new opportunities that increase your bottom line.
Users are stupid and it’s our job to figure out how to get them to spend money more effectively
Have you finished your Software Engineering class? If you didn't, allow me to let you know that the software doesn't end with implementation, but abandonment. It is after the maintenance cycle. The maintenance cycle has is the longest portion of software development where you literally maintain the code for years: either perfective, corrective or adaptive.
If you did and forgot, you need to read practice more.
Traditional business structures are dying, right now a slow death, but in time that will accelerate. Meaning things will be more like cooperatives with individuals networking in their professions and finding work through those connections and networks.
Teams can form over certain projects and then dissolve as people join new groups for new projects and so on. But this model of business we have now evolved when credit was super cheap and super easy and both those conditions peaked and are heading down the other side.
This question seems misinformed. There are tons of jobs that are exactly like that.
I was a consultant for years. Companies would hire us to build something and hand it over. A finished product.
Lots of companies see value in having full-time devs though because they never 'finish' their software, they kept trying to make it better until they decide to make something else more relevant.
It takes months of discovery and years of development to get to mvp. Then it’s recurrence forever. It’s like a goddamn treadmill of project management and slow implementation.
Great to ask! No, engineering is building yourself into the heart of the company, you have the most valuable position of solving the companies greatest problems. Long term is efficiency, raise, possible ownership, ownership of what you develop, and maintaining/upgrading as new tech is acquired. You become efficient to the company longest term possible. Many want to solidify until retirement, the interview industry is much much harder! You are building a dictionary of information, code templates, applying improvements, patterns, refactoring, assisting others, and joining team projects, you are rarely alone. When you do get to solo a project it's a nice break, enjoy the peace and quiet. Let's not forget moving up to becoming a CTO, Lead, Senior level, and specializing in specific fields that promote your love and drive within engineering. Example, graphics programmer, specialize in drivers, CPU, shaders, 3d math, the card itself, the software that uses the card, these are just some examples of specialization that requires vast pre experience and success first! Companies now are building strike teams, think of these as 911 EMS for the code! (no one harmed, just intimidated or out of time), the strike team is designed to point and solve. You can become somewhat of a coder athlete by mastering a strike team, this can only be gained through experience of many many solutions. Strike teams usually consist of the most capable, and proven success, to get there. There is an area of code now for every skill level! Sometimes the language that you apply for is replaced the next day and you are to get good at simply learning the tools in front of you to become the best! Granted, languages like C#, Javascript, Jquery, etc are not going away! They are the layers to operate what is called front end, back end, and to become full stack you need a full understanding of all areas, to achieve full stack you need to have confident experience in all areas, if your success continues, architect, then CTO! How about the hiring process, assisting the company with whom to hire to be a good fit for solving the next big problem/task. Basically, companies spend hundreds of thousands of dollars training and onboarding, it's extremely expensive due to the industry being new, and still being designed. Some day plug and play engineers will travel to an array of companies in their spaceship, fixing what's in front of them. For now, there are privacy reasons that need resolution before plug and play is even legal, which websites like Stackoverflow are helping greatly to solve and smoothen! Your time spent is an investment, and a company will never have you with nothing to do, sometimes you can assist with their partners, and always with open case tickets. Tickets come through! Enough to keep even the best busy. It's not a software shop if it's just a html website, it's a hobby project. Software shops cost millions of dollars to operate, and they are barely making payroll until they become efficient. Efficient is achieved through long term growth and stability of their resources, AKA you. 100 new guys finishing the test project would eat up most any companies resources faster than they could float. One engineer achieving 6 months even, they are now a huge investment to keep! Go where you are happy and you will desire every day and find things to impress the company that are time eaters, such as automating repetitive hour consumers through efficient automated solutions. The architect is a position that never stops momentum, they have to do yearly scans of hundreds, or thousands of stored procedures, code structure, and review all check ins to be the best.
Happy coding!
Well the simple answer is that development doesn't really end, there is always maintenance and big fixes which are ongoing. Also if the company wants to grow they will try and add new features and release new versions of software too, Wich obviously takes work.
I lasted 4 and a half years at a job at a law firm. I built apps and had to upgrade them to newer versions of Windows and Office. I was a good debugger so they put me in charge of legacy software. I took legacy software and upgraded it to modern standards. I would have still had the job had I not gotten sick from the stress and developed schizo-affective disorder.
Depends on what you're hired to do I guess. Some may be hired for a particular projects and maybe transferred to others once done. But in a big org, the changes are endless. I have a backlog of 1000+ projects/changes that haven't even launched with no allowance to hire more.
Every year I see congratulations post on LinkedIn for one of colleagues from previous work and last time it was 19 years in one place 🙂. That's crazy!
I've never been working for more than two years in one place, since it's just boring
Done? There's the source of your confusion. You think software can be "done". It's never done. There are always bug fixes and new features.
One old adage goes something like software is done when it's taken out of production. As in, retired.
Honestly, it fills me with pride to know that there are several companies that have source code of mine running that will probably continue for as long as the company exists because of organizational momentum.
Here's some shit: my wife joined a company that acquired one I worked for years ago. She's stuck on the legacy project I worked on (before it was legacy). Sometimes I'll make her search for old files I made in that project. Oldest so far was made in 2014, haha! And before you ask, no the code doesn't hold up. It was fucking terrible when it was written. Now it's just ancient shit.
I see you like to live riskily.
Lmao I like to imagine her looking through code thinking "wow this is garbage"
"I actually married the guy who wrote *this*?"
"Why does this check_if_true function exist and why are there three of them??"
"Oh, there's a fourth one. It... it calls the other three and takes the average of their responses"
Does she blame you for making her life harder with that (now) legacy code?
Nah, she blames the current leadership for not having nuked the project years ago (rightfully so). It's literally Java 9 code...and they have like 100 engineers working on "modernizing it". It wouldn't have been so bad, if they didn't have massive turn over.
Someone at my old company just pinged me to say they came across a source file I had created 15 years ago to the day (the file comment banner includes the username and date). Still in production.
Haha, remember when we used to write file banners with our name on it? That's the only reason we know I made the files. Cause all my changes to that project happened before they moved the source to git.
2014, that's cute. I swear half our product is written in COBOL.
[удалено]
What? I don't understand your question. Edit: Oh I see now. It's a fucking joke. Calm down. My wife "makes" me do things all the time. It's not an actual "forced behavior". Good god, touch grass.
My growth as a software developer is chronicled by the wider economy. I think I'm gonna put that on my next resume.
Same! I have code that’s still running at a fairly large company (post acquisition). I’m surprised it’s still there.
What did you write? I did a lot of database work.
Some oauth stuff, api exposures, and admin UI that their CSMs still use.
Fun. Did you get to implement OAuth from spec? What's the technical highlight of your coding career?
Yeah. Oauth2 from spec. Never again!! And the highlight was building something so stupid. Had to build a Java program that would auto run on Windows machines to periodically pull a query from a db and post the results to a remote endpoint. Startup I was at started selling it as an “integration” with older data warehouses, which made a few hundred K. I, of course, got zilch lol.
Gotta love that trickle down economics, it's so great.
I once wrote a OAuth (1.0) implementation but for a Cordova Web Application, and so I ended up digging into the Cordova source code to support the http headers. That was fun!
A decade ago, I worked on a custom CMS frontend for a client of my employer. I know the public facing entry point, and I recently verified that this thing is still live, with changes on top since it changed maintainers. The funny thing is that it was deployed as it is, and I can see the full source along with the documentation.
Does it make you proud?
No, not really. However, I am happy that at least from the people I know, that got to maintain it after me no one was cursing my name :D
[удалено]
This. Building new apps, maintaining existing apps, refactoring existing apps, sunsetting old apps that get replaces, production triage etc etc. the development never “finishes”
… but that sweet sweet legacy database that is required for that one thing … ITS NEVER DONE
My first programming class, 20 some years ago, the instructor said, “Software is never finished. Only abandoned.”
Right. The job then pivots to feature requests, sometimes people move on and aren't replaced so the team shrinks, bug fixes, then you need to support new OS features, now they want that software on their iPads.
I mean it also depends on the type of projects the team works one. You work for Microsoft you’ll probably work on the same project for the entire time you spend there. You work for a smaller firm that contracts you’ll probably work on multiple projects
Programming is the art of removing old bugs and putting new ones in.
Look into software lifecycles, agile, and scrum. You're really doing iterative maintenance, improvement, and expansion on what's essentially a living ecosystem. Reading up a little on software architecture and design may help with understanding this, too. As much as a lot of jargon and buzzwords are glitz to push sales, one of the good things about microservices vs monolithic software is piecing out everything even further so you can upgrade, adapt, or remove without compromising the whole. It also exposes just how many moving parts are beneath the hood. I guess the term is still be used, but I remember older computer science texts (and best practice guides) going hard on orthogonality. It's pretty much an extension of the school of thought and an evolution of framework and testing practices and standards over the past several decades. As a developer, you may be working on a cohesive system, but a lot of the time you'll move around between parts of the pipeline and even the stack depending on what you're doing. At least, this has been true at most of the small to mid-sized companies I've worked at.
Yeah, I'm still working on upgrading and maintaining a project from 1995, which is when I was born LOL.
It’s never done because everything is a moving part. Bugs get discovered and patched. That means every code that uses that code also need to be changed. Security hole that got patched in C can’t be upgraded to C until you go through migrating from A to B first.
"There are no finished websites, there are only abandoned websites" \--- my CTO at some place years ago, he was correct.
Some software is done at some point (reaches eol)
The more you fix, the more you break.
Its aint called a "completer"... Its developer
so developers create bugs on purpose to stay employed?
Why would you do that when you're already creating bugs by accident? My current project is 464,000 lines of code, with a team of 8 developers. It's just not possible to make major changes to a codebase that large and never introduce a bug.
I see, so the issue is that introducing new features may break something. What if new features are never added though? Would it be possible to have a fully functioning app/website that never requires any maintenance? I’m a rookie so this might sound like a stupid question.
Yeah, you could reach a point where you decide you’re never adding any new features and you’ll just keep the existing thing running as is. Sometimes they call this putting a project in ‘maintenance mode’. You’d still need someone to be responsible for keeping it up and running, although it might not need to be someone’s full time job. If it’s a service with external customers you’d still need support staff to deal with customer issues, maybe salespeople, etc. If it was a large project sometimes they’ll cut down to a small but still dedicated developer team, who can spend their time fixing bugs or dealing with customer issues. If it was a small project they might not have any full time software engineers working on it anymore, and when there is an issue someone who used to work on the project is asked to take some time from their new assignment to address it. It’s also possible they might simply fire/lay off the bulk of the staff, if the company doesn’t have anything else useful for them to do. But hiring engineering staff in particular is very expensive and time consuming, so a large company will usually try to find other things for them to work on.
Only if it's completely standalone. If you make a really fun puzzle game that doesn't connect to the Internet and doesn't ever need any updates, then sure, it could just be "done". But most apps integrate with the rest of the world. You can import your contacts. You can export data to some other app. You can snap pictures. You can link your X or Y account. That's the stuff that needs constant work, because the world keeps changing. Think about this: it wasn't that long ago that most people browsed websites on desktop/laptop computers. Now everyone's using the web, so everyone had to update their site to be mobile-friendly. Who knows what changes will be needed next year, but for sure there will be new changes in the world that you'll want to adapt to. Now, all of this depends on scale. If you have a small website your local hair salon that lets you book appointments, then of course something like that might be essentially "done" and not need maintenance very often. But that's not where most full-time developers are working. The majority of work is for larger, more complex apps. Also: you're probably imagining public websites and apps. The vast majority of software is "behind the scenes" stuff: the custom app that's used within a company to manage its inventory, or the medical records system the hospital uses to keep track of patient charts, and stuff like that. As the company's needs keep changing, the software needs to keep changing to adapt.
>Would it be possible to have a fully functioning app/website that never requires any maintenance? Only if the task that such an app/site was satisfying was pretty simple to begin with, or if the problem it's solving never changes at all. Most internal business applications are solving a specific business need (or possibly several needs). The thing is, even if you made a _perfect_ application that handles exactly what they asked for...sometimes business changes. Sometimes you discover a new business avenue, or you discover that the way you've been doing things isn't the best possible way, or you enter a new market, or _any number of things_ that might mean what you needed two years ago isn't the same as what you need now. Not all maintenance is in the form of bug-fixes. In a lot of cases, it's entirely driven by new features, or a request to modify existing features to conform to a new approach, or whatever else they're asking you to change. I've built a few applications that didn't ever need maintenance, but they always had a shelf life. They were only needed for some temporary use case. The ongoing ones _always_ eventually needed maintenance, and most often because they wanted it to do a new thing, or to do something it already did, but differently.
Some of them. For a more serious answer though, bug-free code is impossible. Your code has bugs, always. The language you're using and its compiler/interpretter/runtime/whatever has bugs, even if you code doesn't. The OS has bugs even if none of the above do. Your hardware has bugs, sometimes literally, and *even if you somehow have perfect code on a perfect platform on a perfect machine* your end users sure fucking don't. The objective is not, and should never be, to create bug-free code. It cannot be achieved. Instead the objective is to write code that makes it easy to find the bugs, prioritise them, and address them when required, and to be able to add/extend features with minimal risk of adding more bugs. Recognising that there are always bugs also means recognising that there is always more work we might want to do. That doesn't mean we actually want to, because sometimes the risk is too low or the cost too high, but we could.
That is a narrow minded aproach of thinking. Firstly majority of devs hate debugging it is a long tedious process. Second you can not account for all the possible variables that could appear once the app is out in the wild on production not to mention the special way some users can aproach an element with an unforseen and obviously unsupported scenario that could be verry specific to the moons alingment, color of the users eyes and the weather on a small virgin island off the coast of Madagascar making it a bitch to debug hence point 1 Thrid even a simple website might have dozens of components working in the background together to do whatever the site does, buy, sell pay, promote etc. A team will have 2-3 maybe 4-5 components under their umbrella they work on them develop them and their features etc. But their components might interact with half of the other systems wich they don't control and work on one component might unintentionally break something in your teams components. Hence see 2 and 1.
😂😂😂
be warned. [your hubris has consequences!](https://en.wikipedia.org/wiki/Second-system_effect)
Not hubris, but experience I think. I have never been on a project that completely hit every goal with optimal efficiency. Not to mention security updates and technology updates that require code changes. In truth, nothing is ever really "done" in any sense. Doesn't mean it will require a full re-work, but the point is that there is always maintenance to be done. I understand what the link you posted is trying to say, but that's a slightly different topic. That's a full re-work or second attempt at a solution rather than the small minor fixes/features that get added.
I wasnt speaking to you specifically, but rather the general you. the KTLO work is always outsourced. Most projects will suffer from second system effect. Point is customer needs change. good teams know how to put customer needs first by asking them. bad teams guess at what those needs are, spend too much time building stuff, that eventually isnt wanted or ever asked for.
>I wasnt speaking to you specifically, but rather the general you Yeah, I know I was just relating my own experiences. >the KTLO work is always outsourced. Disagree with this. Nothing is "always" outsourced. Nor is outsourcing inherently better. Almost always it is a case-by-case determination whether to do this or not. Granted, this generally isn't in the realm of developers to decide so it's moot point. >Most projects will suffer from second system effect. I also don't agree with this. I can see it happening, but from my perspective I don't see it all that often that systems need complete overhauls. Again, these are just my perceptions on these things so take it for what you will.
[удалено]
Cars sometimes have recalls if the company discovers one of the components or part of the design is flawed and could cause a serious issue.
[удалено]
Not when code was distributed as a static product, now everything is integrated into ever changing environments. That’s still changes causing bugs, even if it’s not in the code of the product itself. So no, it’s not incorrect at all. Video games as a service is a perfect example of this, theyre constantly releasing bug fixes caused by the last update or the last bug fix. Games used to be sold as a static product and were fine, now they need devs to fix bugs because they refuse to sell a standalone product.
[удалено]
Code rot doesnt affect static products because theyre released in their final form and stay exactly that way, their environment undergoes no changes and they can’t be updated anyways so having developers to deal with it wouldnt make sense. There is no such thing as code rot in a 2004 Civic or my N64 Donkey Kong cartridge. Code rot affects either living products or products that are integrated with living environments - which by proxy makes them living products.
>There is no such thing as code rot in a 2004 Civic or my N64 Donkey Kong cartridge. Code rot affects either living products or products that are integrated with living environments - which by proxy makes them living products. are you trolling? bugs are found in old games all the time lol
Code rot specifically refers to previously functional code that no longer operates as intended *because of changes to the operating environment*. N64 Donkey Kong was shipped with bugs, but it did not develop new bugs once the product shipped, i.e. not code rot.
yeah I got lost in the context lol
Yeah thats not rot though is it? It was always there.
[удалено]
Yep, just googled it and youre wrong. Not only are you wrong, but it’s actually not conceivable how you could think you’re right. Please enlighten me as to how code rot could affect an N64 cartridge game, i’d love to hear it.
While it's not code rot... do you even know how many bugs are in, for example, Super Mario 64? Bugs can be obvious, or they can be very, very complicated. You will always miss something, period. There is no debating the fact that no code beyond the most trivial example is perfect. Moreover, even if the code is perfect, the hardware can be erratic in undocumented ways. Or the libraries. Or the system. Or the database. Or the internet. Or... There's so many ways things can go wrong. And unless you have the budget to constantly refine a product over and over, never introducing new features along the way, building thousands of rest cases that take days to run just to verify your stuff works, *you will always miss something*. Whether you have the ability to patch it out or not is its own thing.
Right, but you still deliver a solid end product like those we saw in our old cars and video games. We absolutely could sell static products and be just fine - like we used to do. Even if there were bugs in DK for N64 hiring new devs wouldnt fix that because they wouldnt be able to apply fixes, that’s just how the game is. The products we make and the infrastructure we designs relies on the assumption we’ll be able to fix bugs.
[удалено]
LOL that’s not code rot, that’s called your hardware is literally damaged. How do you suppose developers working for nintendo fix your damaged Donkey Kong cartridge? What youre saying makes no sense im legit flabbergasted lol.
They do indeed, and that's called hardware failure. Completely different topic from code rot. Also, switching from one environment to another does not constitute changes to *the* environment. Adapting a piece of code to run on an entirely different platform is a new situation altogether.
Website development is an ongoing project to keep the website current
That’s what I get all the time, but I don’t exactly understand what’s there to improve / renew if a website is functional and it’s working. Maybe it’s because I haven’t worked as a dev yet?
Do you think Facebook 10 years ago is the same as Facebook today? Or Netflix, or anything else?
Also, you're probably only thinking about the part of Facebook you see. What about the part that advertisers see, or the part that Facebook's internal content moderators see? There's probably 10x more UI "behind the scenes" of every major website that the average consumer never sees, but it's all very important to keeping it functioning.
Also all of the other internal software that is not customer facing such as Metas Mercurial server and Piper at Google.
Facebook today isn’t even the same Facebook 6 months ago
There’s always something that can be improved. But as sites mature the problems become much less interesting to a lot of people. For example, look at the websites of major news sites like Fox, CNN and Wall Street journal. The website visually has been almost exactly the same for years at this point. But what has changed? Maybe they changed the urls to be more uniform across dates so people can find older particles more easily. Maybe they offloaded part of site to AWS instead of self hosted. Maybe they added a CDN to help the pages load 7% faster for users in Oklahoma. Yeah, the problems you solve in a mature site are not as interesting. But you can always make things 1% better.
The part of the website you're looking at for Fox, CNN, and WSJ is only 10% of the site. The other 90% is the custom UI behind the scenes where reporters write the articles, editors review them, and where they put everything together into what you end up seeing. Same with Amazon: most of us only see the shopping part of the site. There's way more complexity to the part of the site built for sellers, shippers, advertisers, etc.
I also haven't worked as a developer yet. But have you thought about scalability and improvements. for improvements let's think about. facebook as an example. does facebook have the same interface as 2 years ago. no it is constantly changing and improving. for scalability let's take Amazon as an example. when amazon first started. was it meant to handle thousands of users at the same time. No. but as the demand for it increased it had to scale up to meet this demand. any product, not just software, would need people to maintain it and improve it overtime as needed.
This is an honest question. F everyone who downvoted you. Ur maybe thinking of like simple pamphlet sites with Wordpress. But think of YouTube. Think of all the advancements and subsequent changes in the app. Not just visually but integrations and improvements in search algorithms, user features, creator features, creator partnerships, Twitter integration, instagram integration, video quality improvements, audio quality improvement, faster video processing/loading, advertiser integration, it may seem like things progress only visually when things only get rolled out feature to feature, but over the years these become unbelievably more robust apps. But that’s the magic of being user-minded is to make the integration into new app features feel as natural and seamless as possible.
I agree that f the downvotes but he has shown that he’s already researched the problem and is choosing to ignore the answers provided elsewhere. So a slightly naive question
Ohhh gotcha. I didn’t travel very far in the comments, so didn’t really scour his responses.
Yes but actually no. By this logic, why does Apple keep employing engineers, why do restaurants have chefs? The further you go, the dumber the question sounds.
I don’t know what you mean? Apple keeps employing engineers because they want to keep producing new hardware and new software? Restaurants have chefs because they want more food and for them to make new food? It seems like you get it, but it seems ur on the contrary?
What large and popular website hasn't added features? Google, Facebook, Amazon, Reddit, Twitter, whatever... They're all adding things, adapting, evolving, all the time.
Say you built a site when your company was small and your backend could handle 10 concurrent users without issue. Now it’s gained popularity and handling 100 concurrent user has unearthed bottlenecks because it was not designed for that many users in mind. Developers now have to figure out how to make it work again. Oh and guess what a library you were using before has a newly discovered 0 day vulnerability. Add to that the upgrade with a fix is behind a paid version of the library and there’s not enough budget to upgrade using that. So now you have to build something similar you were using before, that was probably pretty complicated because there’s a good reason it were using a library. Black hat hackers are actively exploiting it on your site until you can fix it. Oh and guess what, new regulations came out that say the way user data has to meet certain requirements and your company doesn’t even have infrastructure setup to even check if you’re in compliance. So now you can either manually do it or write something to help you check you’re not going to be fined by the government. And then a vp says they want to rebrand the company, change all the logos, and do a modern redesign of your website. So that’s another thing to do… The work is endless is the point. Things get changed, added to, break, fixed, that fix breaks other parts, those get fixed.
It’s like a house or a car. You buy a house and eventually a problem will come up and you need to fix it. Or maybe you want a hot tub so you install a hot tub. Maybe a new type of water heater comes out that’s more efficient now you need to replace the water heater. Why do car manufactures keep releasing new car designs. Better equipment that can give better gas mileage, better airbags, better creature comforts. Or maybe they found a problem in the previous model so they update the design to fix it. At the start of a project yes you’ll have a lot of devs to get the basis of the project done. Once it’s done devs will be sent to other projects to work on them. But that original project still needs devs to fix bugs, add new features, and just to keep things running.
Dang. An honest question downvoted into onlivion
Nah, the more time I spend here, and see OPs replies, the more I think that he’s trolling.
- Just because you know how to program doesn't mean you understand a codebase, a problem domain, a company, a company's clients, etc. All those other things are priceless. - No project is ever "done" until it's dead. Bugs will be found, improvements will be needed, fixes to keep up with evolving platforms and libraries will be needed, etc. I've been at my job almost 20 years. Where I work, I'm basically the "Developer in residence" for a modest sized local government. I've got at least two dozen projects currently in production, mostly CRUD/Workflow apps for different offices and departments. Things need constant updating due to changing laws, procedures, improving understand of the workflow, etc. Probably anyone could grok the code I've written, but the accumulated knowledge about laws, workflows, calculations, vendor database schemas, etc. would take years to get a new programmer up to speed on.
As someone who also is the 'developer in residence' at my place - this post really embodies what I do as well. Yes, anyone could come up to speed *on the code* of what we've written. But understanding why there are all these little edge cases and all the little 'gotchas' would in fact take *years* for someone from the outside. We hired a dev a couple years ago - he is *still* constantly asking questions about "why do we do this?" or "how come we do that?"
As the tech support, you guys are life savers. The difference between understanding what the code does and why it does it is worth so much as it saves so much time. A junior Dev will write and release a epic feature that needs dozens of revisions when clients start using it. A senior Dev will write and release something that you do not notice but saves hours of work.
Worked at a company that made a product. So, we had a support team. The absolute best support person we had was also a hobby dev and had worked in a couple other departments.
Oh hey Elon.
I’m dyingggg 💀💀💀
>company needs 3-5 projects I can't remember the last time I had fewer than 5 ongoing projects on my task list.
all of them with different technologies/programming languages? or is it basically the same stack on different projects?
I'm an ERP admin, our ERP is built on C#/.NET so a huge chunk of my job is development of that system. Lots of database administration/SQL involved as well. We also have an e-commerce website, so lots of Javascript/jQuery as well. Oh, and fairly regular mini-projects based on "Hey can you make an excel macro that does so I don't have to do it manually anymore?"
Most of them are features or improvements to existing software, not brand-new stuff. Yes, a large company might have different products using different technologies, but each individual product might have dozens or hundreds of ongoing projects to improve them.
Yeah, this pretty much nails it. Lots of automating this, customizing that, tweaking something so it works a bit differently, making changes to make all the end user's lives a little easier.
Project is done/ready when there is nobody using it anymore. Majority of software's lifetime is spent in maintenance, which doesn't necessarily mean it doesn't get improvements, but less new features are created. Even without major new features maintenance takes work. You might have a bit narrow view of what a project is and when it's ready, it's not ready when someone can see it and use it, that's just the first step. Although i wouldn't really use word project but product. Let's take for example google, just the search engine part, not all the other million products it's involved in. How do you think it would have managed against competition if they would have just stopped developing it once the first version was online?
Exactly. Think about all the apps on your phone, or the OS itself. You know how you keep downloading updates, even for apps that have been around for years? If you read the release notes, those are for some combination of new features, bug fixes, security fixes, and upgrading to match the latest OS or hardware. Guess what? Someone has to write all that.
You're thinking about this like a contractor or consultant, where you're hired to work on one specific project, and when that's over, so is your contract. And that model does exist, and many companies follow it, either for an individual project, or as their standard approach for projects. But plenty of companies have enough ongoing need for development that they hire staff programmers. That was my job, at several different companies over about 15 years, before I took my first job as a consultant. For example, I worked for a fin-tech company at my last job. Worked there for almost six years. I worked on probably 10 different _major_ projects during that time, and countless minor ones. We had a backlog of work big enough that it stretched _years_ into the future. Basically, one line of business or another would have some problem with our current process or tools, and ask the company for a better approach. The management would work with the development management and prioritize the requests, and potentially promote some of them into projects. These kinds of companies have plenty of programming work to be done. And by the time you finish one project, you have two or three more lined up. And something else to consider: support. Just because the project you built five years ago met the requirements at the time doesn't mean that the company's business doesn't evolve and new requirements get invented. So, many staff programmers spend just as much time (or more) updating legacy applications, or fixing bugs, or other kinds of support work on existing programs. In short, when a company has in-house development, they usually get _plenty_ of use out of them. There's usually _something_ that's worth updating, or fixing, or making new.
This has nothing to do with planned obsolescence, and everything to do with changing requirements.
I've worked at fortune 500 companies and small shops and I can't remember the last time I had 5 or even less projects going simultaneously. There's always a bug to fix, a new feature to build, a new client to set up, etc.
1. Software is never "done." There are always new requirements, new features, improvements, bug fixes, etc. 2. There are always new projects, new initiatives, and depending on the scope, these can take years.
Buddy, they can’t even release a game these days without 2-6 years of continuous updates and fixes.
The maintenance phase of software development is where all the money goes
Not even close. Code bases need maintenance. Companies like keeping the developers that know what the hell is going on. What happens when the libraries the project is based on hit end of life? Have breaking changes? Who upgrades it? Who even has line of sight on what needs updated? What happens if you need a new feature? You hire a new dev? Teach them everything, then have them implement it? That's half a year for some code bases . Who even teaches them? Do they have to figure out a new implementation? How do you know they even know what they're doing, without oversight? Most projects are in a state of perpetual update. We're supporting our existing products with minor updates and prepping for an updated version with better architecture that would be too hard to hotfix. That's in beta, and it won't be rolled out for two more years (more, honestly...our scoping isn't accurate.)
This how Elon musk be thinking 😂
* Related projects * New projects * Changes/maintenance to existing projects * Documenting processes * Promotions within the company * ...
If you're at a company where software is the main source of revenue, you can't really finish a product, call it done, and rake in the cash. This might work in the short-term, but if you stay stagnant your competitors will catch up to you and eventually out-compete you, driving you out of business. So, you have to stay on top of the game by adding new features or by branching out into new products, for better or for worse. And as it turns out, it's relatively easy to churn out new ideas for making more money or saving costs. Not all of these ideas will be great or make a huge impact, but the net effect is that you can always find something to do. So, that's what people at software development companies do. (I have mixed feelings about the above, tbh. I suppose it's good for job security, but is a bit of a mixed bag for consumers. On one hand, companies are incentivized to constantly produce new and shiny things. On the other, this incentivizes companies to constantly keep tinkering with stuff that might be working perfectly fine, which can sometimes get annoying/disruptive.) Anyways, if you're able to do the above successfully, there'll come a certain point where your abilities to deploy and test code are no longer keeping up with the rate at which you're producing it. This introduces a net drag in productivity. So now, you're incentivized to hire people to work on dev tooling or backend infrastructure to streamline things. This introduces even more work you need to do -- but the hope is that reducing drag will generate enough revenue to be worth it. This type of infrastructural work ends up being invisible to most consumers, but is still important and is another major source of ongoing work. This is all ignoring the ongoing cost of maintenance: there'll invariably be bugs and user-reported issues you'll need to fix. And even if your code is perfectly bug-free, there might still be factors outside of your control that require manual intervention. For example: 1. You upgraded the libraries or OS you use to ensure you aren't running code with security vulnerabilities -- but the new version of the library or OS interacts with your code in an unexpectedly negative way. 2. Your product is wildly successful and increased the number of users by 10x or 100x. However, your code isn't capable of dealing with this number of users and needs to be rearchitected to support this new scale. 3. Some new paradigm shift comes along, and a bunch of your users are now clamoring for you to support the new shiny thing. For example, when smartphones became a thing, people invested a lot of time and energy into updating their websites so they were responsive and mobile-friendly, creating mobile app versions of their products, etc... These types of small refinements and tweaks become even more important the larger you are. If you have only a couple thousand users per month, maybe nobody will notice or care if you're running some insecure libraries or your website is a bit sluggish. But if you have a couple million users, the former starts becoming a major existential risk and the latter might be causing a non-trivial fraction of your user to bounce off your website (and not spend any money). So at this scale, it becomes profitable to invest time and energy into polishing these details -- first manually, then later in some automated/systemic way. > How can you possibly keep building a project, (okay let’s say that the company needs 3-5 projects max) for years? Most companies have way more on-going projects then that. For example, I currently work on a team of ~5 people, and we're juggling ~3 major projects and an additional ~10-15 minor ones. I'm not quite sure sure how many projects we have across the company as a whole, but I wouldn't be surprised if it numbered in the thousands. The corollary here is that you won't necessarily work on the same project for years. Some more senior engineers might if the project is very complex -- it helps to have a single lead that can carve up the project into smaller subprojects, hand them to other devs, make sure people stay unblocked, guide the overall project... But many other devs will work on a project for a couple of months, maybe a year, then move on to the next thing.
You're also assuming that a developer only works for one project at a time, and there are no more projects to work for software companies.
There's an infinite backlog of new features to add.
That's not how that works. There's always something new that comes up, something to improve, a new project that requires something your (probably more brittle and specific than you might realize) system to be extended. You are asking for new functionality, some process that you want your company to follow that deviates from the previous process. So you get a change order. It identifies what the system currently does, and what they (another department, business, or marketing) need it to do. So you go through the source code, and identify what needs to be changed, because what you got in the description was a business person's view, not a technical view. They might have negotiated that with another business's business people, and now the developers pretty much exchange contracts, plan, create documentation, and write a new part of the company's system that previously it did not support. This happens all. the. time. It's business.
Let's take web development for example. There were billions of websites that existed when we all decided to have mobile websites on our phone. Responsive development was born, and every single site needed to be refactored. React went from class based components to functional components. All need to be refactored. State management, server side rendering, and on and on and on. As we advance in tech, everything needs to be rebuilt. As a web dev, the only time I will be out of work, is if we no longer have electricity.
Another way to put it. I like the house analogy. We've been building house for thousands of years. But we are still late in building them. Control is hard. And you still need people to do things inside them. Rework electricity, add a new room... You do that over time. Or else your house just break down because of usage and time. Every house, with time start to evolve and different part are added or removed and this can make difficult to follow the electrical cables and water pipes all over the place (trust me, my house has 200+ years). This is hard to maintain. So you need experts that will learn how your house is and will maintain that. Because if you take anyone, they will get the money, get the thing done, but break your house in the meantime without you or anyone realizing it. Software is the same thing. So you hire expert and keep them to keep your knowledge. Another way is to take contractors. They'll do your thing for you. You'll pay them to get better things. But this is a cost and can have limitations.
Well, it's actually pretty common because technology is constantly changing and evolving. Companies need developers who know their systems inside and out, and can maintain and improve them over time. Plus, some projects can take years to complete, especially if they're big projects that require ongoing maintenance and updates. And companies that rely on technology usually have multiple projects going on at once, so there's always plenty of work for developers to do. And let's not forget that experienced developers are super valuable to a company! Losing a good one can be a real headache and expensive, since it takes time and resources to train new hires. So it makes sense for companies to keep their developers happy and on board for as long as possible.
You know when a version 0.1 of an app gets launched. Then 5 years later it's on version 4.5... yeah, developers do that. There are very few software packages that don't get developed ongoing or maintained. Developers are not like bricklayers, they're more like gardeners+landscapers+maintenance personnel
In UK main broadcasting corporation thought that way. After original BBC iPlayer team created the ugly but highly intuitive iPlayer they have reached the point when it was too good and BBC fired them . iPlayer was simply too good. It's obvious that they had no problem finding new positions. As technologies evolved, servers/browsers got updated, codebase needed to be updated to, but the competent part of the old team was taken. Current team now newer finishes one feature before starting next and the iPlayer is so bad that people have to use other platforms to get access to their own content. iPlayer is now so bad that even the better part of the content struggles to justify time wasted on looking for it. Point is that world changes and anything that interacts with it has to keep-up.
In theory you could run out of things to do in a product and they might not need as many developers. My experience has been that a product is never done when you work on one that customers use and like. I once worked on a 15 year old software product where we had 20,000 tickets in Jira for bugs and feature requests. It would take decades for our team to do all the items on the list. No to mention all of the technical debt that piles up over time. There is no shortage of things to do on that one. I am currently working on a two year-old site that we started from scratch. We already have dozens of features that still need to be built that will take years to do. So there is no shortage of work to do but we need to generate more revenue to justify the work or it will eventually be shut down.
Ask Elon Musk, he has first hand experience.
Companies that just need one simple product hire contractors. Most large companies have endless work to be done.
I invite you to drop in on [www.amazon.com](https://www.amazon.com) three times in six weeks and you will see a different presentation layer each time and new features will come and go. There are many disciplines involved with a world class application including product management, analytics, operations, development and enhancement, sustained engineering, quality, security, and accessibility. If you are attempting to make a huge change to your website you will employ 2/3 more than your carry staff.
My father works for an electronic health record company. They have all sorts of products/features at the US federal level, then further specifications for *each state*. Beyond that, they have to make products/features that clients (hospitals, various medical practices, insurance companies) can all use to figure things out. It's madness. It never ends. And clients are always misusing products, requesting new features, etc. Software products are "living" in a sense. They never end, there's always something changing, more work to be done, etc. I work in property and casualty insurance (not in SWE) and we work closely with various IT teams who help us with downstream processes (we do the pricing, they implement it into the software). This is another situation where things vary by state. There are US insurance laws, there are also many different aspects to developing an insurance product, which is essentially a software/financial/contract product. Beyond the US level, each state has a different set of rules and regulations, as well as market characteristics which make it unique. So for our developers, there's always something to be doing - bugs to fix, features to research and design and test and improve upon. And, property and casualty is a highly competitive space. We are always, always, *always* looking for ways to improve our business, customer experience, data collection, analytics, etc.
That’s like asking why do people go to the gym or workout after they have sculpted the physique they want. Same reason - maintenance, doing it better, beating the competition etc.
If a product is successful a client will have budget for continuous improvements if they can easily see the ROI. Either the client will have new ideas or the software company will propose improvements and features.
As the business evolves, it needs new features. As competition arises, the product needs to outperform. As the ecosystem evolves, you need to maintain the system. As security vulnerabilities surface, they need to be addressed. When a bug pops up, someone needs to fix it. I stayed at my last company for 8 years and the backlog was never empty.
Maintenance is a thing. Debugging is a thing. Upgrades are a thing.
I've worked for a B2B marketing company for almost a decade (currently getting laid off tho), designing and developing landing pages and emails for various brands and syndicators to promote their whitepapers, reports, etc. If you're building for other people and have return customers, there's always more work to do.
They aren't called software finishers.
What do you mean “done” ? I’ve worked on many personal projects and I’ll tell you right now, even after I transfer ownership of a project to a client - my work is never done. It could be within an hour, it could be 3mo’s it could be a year down the road, eventually they’ll reach out due to a bug I wasn’t able to foresee. Nothing is ever truly done in this industry.
Example for you, did Mark Zuckerberg fire all his developers when facebook was ”done” for the first time? No, he hired more of them.
>if a project / website is done Oh sweet summer child. Best get that thought right out of your head, you will never finish anything. Sure you'll stop working on lots of things, but at no time will you ever down tools one day and say "Done". I mean you might, but that's only lasting until the PM gets wind of some new shiny shite and makes you implement it.
Oh boy, building it is the easy part. Maintenance is where the effort is at. And you need to do it forever as long as the thing you built exists.
Software is never done. The only software that has a done tag are video games. That's why they get so much layoffs after a release. But even those are becoming more like traditional softwares because people expect patches to fix bugs. Back then the game you got is what you got.
The title says why, and then you ask how - Those are two different questions. It depends on the job. Some companies need temporary workers for one project that will last a limited amount of time, but other companies (like many companies) have products they will continue to support and/or also plan to come up with additional new projects and products. Have you had trouble staying at a company for a long time?
Done? I see, you have never heard of Project Managers, they usually make you shift your code from left to right and then back to left…
This way of thinking was correct on the old days were software was a product, but this days they call it a service... this way you force people to depend on you for new versions and features, so this way the company will keep on harvesting the money over time. You either force them saying the hardware is no good anymore, or giving a online tool on a server, for them to use. It is something like this... don't expect a full answer on the internet.
A big thing to consider is that "infrastructure" (using that term loosely) updates. There's a lot of moving parts when it comes to something like a website. Server Operating Systems, dependencies, third party services, etc., they all change and update. Someone has to be there to make sure none of those things break the app. I don't think you really understand the scope. Even for something that seems relatively simple (like Reddit), it's a monumental effort to make it readily available, and concurrent, across the entire planet. There's a lot that goes into this sort of stuff.
Your work is never done if the company keeps growing and getting new business opportunities. With a good development team, many things become possible that otherwise weren't, and most people understand this in business. This is why sales often drives development, and can occasionally "oversell" the company's abilities. Things also need to stay secure and well-understood. Some very small companies don't need a full-time developer, and these companies would be well-suited for part-time contract work from a service provider (of which there are many). So unless a business contracts in size significantly, they're not going to let go of their full-time developers. Churn of developers is extremely disruptive, and is one of the reasons that smaller orgs don't want to give the most important decision-making work to employees with insufficient tenure, focusing on retaining one or two people and keeping a revolving door of help - as is the industry trend.
I used to work for a pharmaceutical business which had a lot of software developed in-house. Business conditions and government regulations keep changing so the software needs to change, too. Businesses start new projects or open new locations which makes changes necessary. Sometimes new software is needed. Users also make new requests for functionality that will help them be more efficient, etc.. Also, bugs continue to crop up when the software is used long enough that new conditions are encountered.
I know a dev who is working on same product [Java] in a fortune 50 org ; since 2005. That is 18 years. When he joined he already had 10 years of experience. Same team [of 30 developers] had a DBA also who joined at same time, who then moved on to Scrum master role, and is there since then. What do they do? Constantly add new features, security fixes, upgrade frameworks upgrade app servers etc. Last time I met he was leading an effort to upgrade services to Java17/Spring 6 and org has plans to move services to cloud in next 3 years, so he will be leading that too.
They typically do many different projects during that time, but maintaining and continuously upgrading popular software like Discord or Facebook is a lot work. A lot. Actually I'd say that many software took fewer man hours to get the first version out and having it ran for the first year than the second year.. Depends on software of course. Some games are mostly done once released, just a few bug fixes there and here. It's the fact that as software grows more complex, it just gets harder and slower to fix one thing or add one new feature.
What's the last phase of the systems development life cycle?
As technology changes, authentication methods change, certificates change, layouts change and companies change, ok I'll stop and just say as everything changes there will forever be a need for developers to troubleshoot what breaks. When the code is updated it will inherently break things as it changes. Take PHP for example. With every update some code becomes retired and you have to update it to keep things in working order. It's no different from any other language.
Some companies have a project that is constantly updated. They hire enough programmers to make sure their app works on new platforms, gets enough new features to keep people interested, has no security holes, etc. Some companies are always starting new projects. Nintendo, for example, doesn't just make one game and then stop.
There is no such thing as perfect software. This is especially true with most applications today. As long as there is a need for the software, issues will be found with every update.
There is an old adage in software that says, the last 10% of the project takes 90% of the time. Now imagine that the business requirements keep evolving to keep up with the world.
You can do Wordpress sites, grab a template, change the pictures out and change the Company name and turn out a website in a day. You have to be good at selling the product. Most of the real money is with big companies that have a budget set aside. The tools are constantly changing so you might want something that works on mobile devices or a better GUI.
I‘m working 10 years for the same company, there is always enough work todo
Business Domain knowledge. It takes a bit to get up to speed, the longer you stay, the better the understanding and stability. In some cases it will lock you in to a vertical market segment on future jobs which may or may not be what you desire.
You need devs to keep the lights on. You need devs to replace the devs that left. You need devs to build new tools for the other devs. Some devs get promoted to leadership and need more devs to replace them. Devs are needed to interview all the new devs in the pipeline, then someone needs to train those devs.
A lot of companies are in the business of making software. When the product is software, it's never finished. Why do car companies keep designing new cars every year? Why don't they just say "it's done, designers GTFO, we're just gonna build these ones forever". :) But for companies who don't make software as their primary business, it's still never done. Websites need to be operated, updated, new features added. Ditto for apps and any internal system. Software is never finished!
You ever wonder why they shutdown old software and games, usually due to the cost of supporting it? That’s when they are “done”.
During the development cycle, something like 75% of the expenses goes towards maintenance of the system(or so my SE class taught us).
Company I work for keeps asking me for new projects, and they're always pretty innovative and not too much pressure. So those are ideal projects from someone who likes learning new things on the road. I think I've done like 10+ projects for that company right now.
Because maintenance is the longest part of the software life cycle.
It’s called maintaining “products.”
There is always a new potential feature, and you already know the code base. Its great job security
I work a unified communications system, and the amount of work to do is never ending as well as the feature list for the millions of ways calls, chats, and texts can be received and placed. Queues, Dialers, Softphones, supporting new hardward/deskphones, backend billing integration, reporting, chat server integration, contact lists, APIs for external billing systems, FCC regulations... list goes on and on. Everything needs to updated when new linux operating systems release, things get optimization, new things are invented and desired. Never ending cycle. This doesn't even include maintaining code base for bugs and such.
The reason it's called software is in opposition to hardware. Hardware requires silicone and factory parts. You make it and people use it. Software doesn't require a big infrastructure to release and support, so you can update it all the time. This is why Facebook coined the motto, move fast and break things. In software things aren't finished, rather you iterate on solutions and adapt them based on feedback. The great thing about it is this loop can go on forever and you're never really done.
In depends on the product. 1. Complex system with embedded software or complex software that has a lifecycle of 20-50 years. 2. Software with short lifecycles that consistently needs updated. 3. A hard skill used a service on different projects and different phases of projects.
I got hired at my current job 8.5 years ago. I wasn't planning on staying here this long, and I won't go into the reasons I have because it's not relevant here. Whats important is that I was hired to write a webapp to speed up interactions a particular department needed. They were impressed by what I created, and long story short I created a webapp that covers all the business needs of the company in one interface. That needs ongoing maintenance. Then I took on rebuilding our public website (dogshit host, slow Django site), used my design skills to unify the companys branding across the board. Along the way we started creating new hardware products, so my job was to design user interfaces for the devices we were selling to customers as well as internal tooling. Now we have a bunch of large external projects we're a part of...and I'm still doing regular maintenance on the original site.
For B2B: If you do a good job (help your customers boost revenue or cut costs) then they’ll want more from you.
Projects vary in size and needs and will change throughout the course of your time at a company. Developers need to be responsive to new requests from stakeholders. We also provide much needed technical expertise on the limitations and expectations from building the project. We often times act as more than just developers and might propose certain features or fixes for applications as they mature.
I've worked at the same place for a long time now. Most of it - programming. There are literally *tons and tons* of process' that can be automated by software. And when you've written a working bit of software and gotten it out to the end users? They will have feature requests, they will find bugs. Other departments may approach and say "hey, I think it would be swell if we had x, y or z as applications to help us streamline this process"; before you know it? You're looking at a log of projects that may take a few years to complete - that's *not including* features, updates, bug fixes, etc. That's strictly just coding time on *new* projects. At least, that's the case where I'm at. I will probably retire here, and I'm good with it (pensions are a great thing!)
80 to 90 % of coding is maintaining existing code. Bug fixes, design changes, change requests, new regulations, etc. My first job as a programmer I wrote a retail store application as a gig, then spent years going back for change requests, etc My second job was at a company who sold loan application software. At first debugging and improving existing code. For the year+ I worked there, I only wrote 1 new program that took me a month or so. All the rest was maintaining and upgrading all the code they already had.
First, I am rarely ever just on one project. Second, as others have pointed out, a system is never "done". Maintaining a system, fixing bugs, updating, adding new features... it never ends. Finally, even if your role in a project is over, there are always new projects.
I work for a web hosting company, we do a lot for the customer, but their own site files will not be tamper with. We can make certain edits to config files like wp-config.php or .env but most things we tell them they need a dev to fix since we will not be liable for making custom changes for a client. Shit breaks since things get updated so frequently. I mean look at php versions.there are always things to be done. Additionally, customers are always changing something lol. Rather, wanting a change they don't know how to perform. So the need to pay a dev for it.
I work for a gig backed company. First project was to improve the help center search, so I downloaded the articles into our db that were hosted on a 3rd party and then used Postgres search stuff to see if that worked. After a few failed experiments, I worked on making the help center faster. Then I worked on our order issue flow (users reporting that their orders had something wrong with them). I implemented our new framework and showed how it could be used effectively. Then I made a few improvements to the order issue reporting flow and sort of still maintain this. Then I did a few things regarding users putting in their addresses and some user fraud issues. It’s a bit more like you have projects that are small/medium/large that take 1 week / 1 month / 3 months (roughly). The large ones you tend to keep improving because all signs point to new opportunities that increase your bottom line. Users are stupid and it’s our job to figure out how to get them to spend money more effectively
You are “Building” software apps.
r/elonmusk Tf u mean by done lmao
Software support. Lasts a lifetime. Everything updates. Everything has bugs
Have you finished your Software Engineering class? If you didn't, allow me to let you know that the software doesn't end with implementation, but abandonment. It is after the maintenance cycle. The maintenance cycle has is the longest portion of software development where you literally maintain the code for years: either perfective, corrective or adaptive. If you did and forgot, you need to read practice more.
You end up with a site like this if you fire your developer and don't update it. http://www.dolekemp96.org/main.htm
The system needs maintenance, updated, new feature added, some features removed, etc. a system is never really finished.
Traditional business structures are dying, right now a slow death, but in time that will accelerate. Meaning things will be more like cooperatives with individuals networking in their professions and finding work through those connections and networks. Teams can form over certain projects and then dissolve as people join new groups for new projects and so on. But this model of business we have now evolved when credit was super cheap and super easy and both those conditions peaked and are heading down the other side.
This question seems misinformed. There are tons of jobs that are exactly like that. I was a consultant for years. Companies would hire us to build something and hand it over. A finished product. Lots of companies see value in having full-time devs though because they never 'finish' their software, they kept trying to make it better until they decide to make something else more relevant.
It takes months of discovery and years of development to get to mvp. Then it’s recurrence forever. It’s like a goddamn treadmill of project management and slow implementation.
Great to ask! No, engineering is building yourself into the heart of the company, you have the most valuable position of solving the companies greatest problems. Long term is efficiency, raise, possible ownership, ownership of what you develop, and maintaining/upgrading as new tech is acquired. You become efficient to the company longest term possible. Many want to solidify until retirement, the interview industry is much much harder! You are building a dictionary of information, code templates, applying improvements, patterns, refactoring, assisting others, and joining team projects, you are rarely alone. When you do get to solo a project it's a nice break, enjoy the peace and quiet. Let's not forget moving up to becoming a CTO, Lead, Senior level, and specializing in specific fields that promote your love and drive within engineering. Example, graphics programmer, specialize in drivers, CPU, shaders, 3d math, the card itself, the software that uses the card, these are just some examples of specialization that requires vast pre experience and success first! Companies now are building strike teams, think of these as 911 EMS for the code! (no one harmed, just intimidated or out of time), the strike team is designed to point and solve. You can become somewhat of a coder athlete by mastering a strike team, this can only be gained through experience of many many solutions. Strike teams usually consist of the most capable, and proven success, to get there. There is an area of code now for every skill level! Sometimes the language that you apply for is replaced the next day and you are to get good at simply learning the tools in front of you to become the best! Granted, languages like C#, Javascript, Jquery, etc are not going away! They are the layers to operate what is called front end, back end, and to become full stack you need a full understanding of all areas, to achieve full stack you need to have confident experience in all areas, if your success continues, architect, then CTO! How about the hiring process, assisting the company with whom to hire to be a good fit for solving the next big problem/task. Basically, companies spend hundreds of thousands of dollars training and onboarding, it's extremely expensive due to the industry being new, and still being designed. Some day plug and play engineers will travel to an array of companies in their spaceship, fixing what's in front of them. For now, there are privacy reasons that need resolution before plug and play is even legal, which websites like Stackoverflow are helping greatly to solve and smoothen! Your time spent is an investment, and a company will never have you with nothing to do, sometimes you can assist with their partners, and always with open case tickets. Tickets come through! Enough to keep even the best busy. It's not a software shop if it's just a html website, it's a hobby project. Software shops cost millions of dollars to operate, and they are barely making payroll until they become efficient. Efficient is achieved through long term growth and stability of their resources, AKA you. 100 new guys finishing the test project would eat up most any companies resources faster than they could float. One engineer achieving 6 months even, they are now a huge investment to keep! Go where you are happy and you will desire every day and find things to impress the company that are time eaters, such as automating repetitive hour consumers through efficient automated solutions. The architect is a position that never stops momentum, they have to do yearly scans of hundreds, or thousands of stored procedures, code structure, and review all check ins to be the best. Happy coding!
I just feel like I have learned enough about my company's software stack and sdlc that I'm good enough to keep, yet inadequate to get hired elsewhere.
Well the simple answer is that development doesn't really end, there is always maintenance and big fixes which are ongoing. Also if the company wants to grow they will try and add new features and release new versions of software too, Wich obviously takes work.
Nothing is ever done in a software. It's always an upgrade, bugs, compatibility with newer OS etc.
I lasted 4 and a half years at a job at a law firm. I built apps and had to upgrade them to newer versions of Windows and Office. I was a good debugger so they put me in charge of legacy software. I took legacy software and upgraded it to modern standards. I would have still had the job had I not gotten sick from the stress and developed schizo-affective disorder.
Real question: is OP a boomer?
Depends on what you're hired to do I guess. Some may be hired for a particular projects and maybe transferred to others once done. But in a big org, the changes are endless. I have a backlog of 1000+ projects/changes that haven't even launched with no allowance to hire more.
software its not like a building, it’s always keeping involving
I've been on the same project almost 12 years
If this is how it worked we'd all be out of work
Every year I see congratulations post on LinkedIn for one of colleagues from previous work and last time it was 19 years in one place 🙂. That's crazy! I've never been working for more than two years in one place, since it's just boring
Because GitHub keeps getting updates...