6 ms·
Exactly, but banks aren't a good example. Some people here mention feature plateaus and completeness of the app. Obvious question is, what should the employer
by maficious 5y ago
Exactly, but banks aren't a good example.
Some people here mention feature plateaus and completeness of the app. Obvious question is, what should the employer then do? The software is complete, from now on there's only maintenance, which is relatively less work compared to building from scratch, so as a consequence I guess developers should be paid less then? Or like you said, fired?
Obviously the manpower could be just moved to the next project, but what if we look at the worst case scenario? What comes next?
Are there at all such mechanisms that could allow for, say, a team of engineers that maintains a bunch of projects in different companies. If such a team would take a maintenance of a few complete programs, the count of them would make up the difference in pay, e.g. a few mainted apps for a lower pay equal pay for building one app from scratch.
- grishka 5y agoWhat does a construction worker do when they complete a building?
- DougWebb 5y agoObviously they get started on redesigning the foundation.
- grishka 5y agoAnd then start rebuilding it while people live already live or work inside.
- emodendroket 5y agoA great many people are involved in maintaining existing buildings. This isn’t just a gotcha but reveals fundamentally faulty thinking underlying your analogy.
- actually_a_dog 5y agoI don’t think it does. Buildings aren’t maintained by construction crews. They’re maintained by facilities teams, and maintenance contractors, the latter of which are hired on an as-needed basis rather than on permanent retainer.
- emodendroket 5y agoIt happens to be the case that software maintenance requires essentially the same skills as software implementation, so we don’t differentiate between the two jobs. And besides that, the nature of what people demand is different: nobody expects a single-family home to suddenly accommodate 50 families, but the equivalent of this is not exactly rare in the world of software.
- actually_a_dog 5y agoYou forgot that maintenance contractors aren’t kept on permanent retainer. Why bother keeping software maintenance crews on permanently?
- oscardssmith 5y agoThe big difference is that if a competent plumber looks at a sink, it will take them 30 seconds to figure out. If a competent programmer looks at a new codebase with 30000 lines of code, it will take them 6 months to understand it, and then still be missing 80% of the details.
- grishka 5y agoYes, sure. For online services, that would be all the people involved with maintaining infrastructure. But my point is that construction workers are no longer needed for that particular building once it's completed. Yet, somehow, apps and websites are never completed. They're always changing for no good reason.
- emodendroket 5y agoBut there are all kinds of code-level changes that end up being necessary, even if you never want any new features. You can't just have sysadmins and expect to run a service over the Internet.
- grishka 5y agoWhat kinds of changes? Operating systems are also feature-complete and don't need that yearly release cycle. They only need updating if there are new hardware capabilities that need to be exposed to applications. And security patches don't change APIs.
- fma 5y agoI huge non-tech company, manufacturing company. Our software that is perfectly stable and have no new business requirements fall in this bucket. There's 2 scenarios 1) The entire dev team truly does move on...and the operations are in charge of the production app (they're in charge, anyways). There's no code changes...just OS, database security patching etc. If there are any code changes for security (i.e. upgrading Struts because Equifax got hacked...) then the business side that owns the app gets some resources. But otherwise it really isn't touched. It does cause some contention because no dev wants to be pulled in to work on those junk. But in the last few years, we have teams who's only job is to work on this kind of stuff. They work on apps that only need a dev team for a few months. 2) A stable app is part of a team. The team doesn't work on it anymore...For example my team previously owned ~8 systems. I think like 6 were mature where it had no new features. A lot of people actually left to other teams because of that - which is an issue in itself. What good dev would hang around? And when a new app or major feature is needed...you're left with stranglers and junior engineers who need to somehow step up.