I’m an ex-software engineer.

Software technology and platforms change so rapidly that by the time you release software, it’s considered to be obsolete. While this varies on size of project and industry, as soon as implementation is complete, it’s usually time to start planning for upgrade to the latest software.

I worked in software industries that took years to roll out from contract to go-live. In those years, technological platforms, features from other installs, bugs, etc had changed the base software into something that would be unrecognizable from the initial sales software demo.

Sometimes, branches exist in which old software lives on for a decade with many installations, with large-scale upgrades taking years.

Yes, much of all of this drives revenue, which is the whole point of a software company. Service contracts with some of our clients were in the $ millions, and involved years of customizing and implementation via professional services, training, etc. It’s my understanding that current contracts and user fees fund future development to keep the software competitive and relevant in the industry.

Even smaller, non-customized off-the-shelf software needs to keep up with industry features, even if their own customers aren’t currently requesting these features.

Like all good capitalist enterprises, there is a fine line between meeting the customers’ need and creating that need.

My take is speed of loading pages and use of screen real estate. They haven’t sent me to the new page yet.

Maybe they know I’m old and and be grumpy.

I’m not a software engineer, but I worked on many software project teams alongside the engineers and graphics designers and others during my years as a technical editor. So I do have an opinion.

People get put on software project teams with some sort of assignment. They have to deliver something. Otherwise they don’t have a job. If they’re not doing something important, where are their names going to fall on the next staff cut list? So they’re not there to leave things alone.

I have seen project teams do brainstorming sessions on the features they needed to include in the next rev. (And later watched them prioritize features in order to remove some when they had to make cost-schedule-performance (CSP) tradeoffs once things started to fail or lag.) If I made a note of all the big changes coming in the next release, I could almost predict what were going to be called issues to be addressed in the one after that. Look at the list of new solutions on the whiteboard or in the PowerPoint today, and a year from now some of those will be the issues to be addressed in the following update.

For example, if Release 2.17 did X automatically, that might be a problem next time, and Release 2.18 would make X optional. If they marked something with little circles, I swear by the next release they’d have customer feedback that said they were too round, and so now they have to be square. Six new options? Pick two, and save the other four for next time.

And they’re always wanting to give the GUI a “fresh new look” because they’re bored with it. Never mind that we users want it to remain familiar so we can put our effort into using it rather than figuring out how to navigate it. If we’re occupied with the mechanics of operating it, we’re not productive.

Put more in one screen display? Looks too busy and confusing; cut it back. Put less on one screen? Too many clicks, takes too long; condense it.

I couldn’t help wondering if they did this on purpose.

Essentially they have to make something new or else change or remove something that’s there. That’s how they keep the project going.

And all those features cut or reduced to meet CSP limits? Blueprint for the team’s next release.

Oh, and Marketing: Marketing has promised a major customer that the next release will have Y, even though Y was not a top software priority. Meanwhile they have to keep selling the last release because it hasn’t broken even. And a big prospective customer wants to wait until they come out with Z, rather than buying the down-rev release with Y, even though that one isn’t out yet.

Now imagine working on this from your home in Silicon Valley while the kids are out of school and your bags are packed for a possible evacuation due to wildfires during a pandemic. We’re going to see some mistakes.

Just my opinion.

@Jeruba Yeah – and that’s pretty much what my son is doing. And he says they have some big deadlines in December.

@janbb, this is why, even though I still have a hopeless, go-nowhere wish list for Fluther, I love the fact that the interface and functionality don’t change. Stability does not equal peace, but it’s hard to have peace without stability.

I hope your son weathers this bizarre storm. Despite what I have to cope with, I do think some folks have it a lot harder.

Planned obsolescence. It keeps you buying. However, IMHO if it works don’t fix it.

Even though Facebook isn’t explicitly selling us software, their big teams of developers must feel some need to justify their existence in the company. If they’re designers, they have to design something. Yep, even if it isn’t actually needed, and even if the new design isn’t any better than the old design.
Personally, I despise the new ‘design’ of FB because it crowds the central section with useless blank space in the margins all around. This doesn’t matter if you run FB at full screen. <= who does that ?!?!?! I don’t run FB at full screen it sits in the corner where it belongs, and the new design is worse than useless.