Foreflight - major layoffs

Ed Haywood said:
You lost me there.
Click to expand...
I asked if Facebook treats its customers well, and the answer was, "Ha ha, you don't even know who Facebook's customers are because you must think it's the users."

But the joke's on him because I know that no matter how you define Facebook's "customers," it doesn't treat them well. Users are manipulated, exploited, and lied to. And Meta's advertisers and content partners are, well, the same, mostly. Advertisers and partners use Meta for advertising because they pretty much have to. Same with Google.

Remember when a bunch of apps broke because FB arbitrarily changed it's third-party auth policies with no notice (even to very large customers)? Pepridge Farms remembers. And any marketer who's used Meta or Google for any significant length of time can tell you stories of getting f***** over randomly by policies that either don't actually exist, spring up arbitrarily, or are unevenly and confusingly enforced. And the lack of support is legendary.

So, "You just don't understand FB's business model, dummy," isn't the own that some people seem to think. FB's business model is being too big to care what anyone thinks.
 
The main draw to foreflight for me was its stability. For XC, flight instruction, personal local flights, even IFR GA, I have found the tiny tap areas and multiple nested menus frustrating. I used iFly and FlyQ for years before and it was easier, quicker and more intuitive to find the information one needs, especially in flight, than using foreflight.
I hope those other EFB companies snatch up the former foreflight developers and make their products eat foreflight's lunch.
 
farangutan said:
I hope those other EFB companies snatch up the former foreflight developers and make their products eat foreflight's lunch.
Click to expand...
What would that look like? Of all the apps out there, FF is one of the most polished intuitive and easy to use. For the GA IFR pilot, it does everything one could want. So to eat their lunch, what would the other sort-of-there EFBs enable? Straight copy for cheaper? Maybe, but for most heavy duty users, a 50% discount wouldn't move people away from FF. That said, their former developers will find work easily in the EFB space, hopefully with Garmin so their product becomes equally as good. Competition and choice is always best.

Never underestimate first mover advantage - probably some of the UI elements in FF could be better, but for the tens of thousands of users from J3 to 777, the interface is learnt by now and more than adequate. Now if it stops working, or FF updates are no longer in sync with the numerous and essentially useless iPadOS updates, then they may slowly lose their advantage.
 
Steamflyer said:
Never underestimate first mover advantage
Click to expand...
Just so history doesn't get rewritten too firmly. FF wasn't first. Airlines had been creating solutions for 10-15 years and, even in GA, there were dedicated hardware solutions and software like AirGator running on tablets.

People like to romanticize first mover, but it's a tough position to be in. This is another example of that. FF executed extremely well, but they also benefited by learning from mistakes they didn't have to make. The market had already shown that it was possible to do EFBs, that heavyweight solutions like those at the airlines really only worked in that environment, that tablets were evolving rapidly and getting to a point of being able to support the needs of EFBs and many of the UI idioms still used today.

Now, don't get me wrong, the FF people did amazing things including keeping the hammer down and adding functionality on a relentless cadence during the early days. But, also, let's respect that they were fast followers, not first movers.

Now they are the 800 lb gorilla and will have to mess up pretty badly to give up the advantage. Since I use FF and don't have any reason to want to switch, I hope they manage to navigate this period successfully.
 
Steamflyer said:
What would that look like? Of all the apps out there, FF is one of the most polished intuitive and easy to use.
Click to expand...

I prefer iFly's UI in flight, but FF has a better briefing presentation. Also, iFly is not limited to iOS. If iFly would improve the briefings, for me it would be considerably superior to FF.
 
172andyou said:
Just so history doesn't get rewritten too firmly. FF wasn't first. Airlines had been creating solutions for 10-15 years and, even in GA, there were dedicated hardware solutions and software like AirGator running on tablets.

People like to romanticize first mover, but it's a tough position to be in. This is another example of that. FF executed extremely well, but they also benefited by learning from mistakes they didn't have to make. The market had already shown that it was possible to do EFBs, that heavyweight solutions like those at the airlines really only worked in that environment, that tablets were evolving rapidly and getting to a point of being able to support the needs of EFBs and many of the UI idioms still used today.

Now, don't get me wrong, the FF people did amazing things including keeping the hammer down and adding functionality on a relentless cadence during the early days. But, also, let's respect that they were fast followers, not first movers.

Now they are the 800 lb gorilla and will have to mess up pretty badly to give up the advantage. Since I use FF and don't have any reason to want to switch, I hope they manage to navigate this period successfully.
Click to expand...
All good points. But they were really the first that was worth anything. I used JeppView or whatever it was called on both Motion tablets (yes a hard drive really will crash above 18k) and later Samsung SSD based tablets. It was better than paper but nowhere near the seamless experience of FF. Also spent a fair amount of time early on going between FF and WingX.

Any dedicated solutions that airlines had (not familiar, and several friends are captains at legacy airlines) were drop kicked for FF quickly.

Never understood the need to avoid buying a $500 tablet that runs iOS to be a FF participant - the little I've seen of the Google OS tablets leaves me wanting and the scruff last time looked was amazing. Sometimes a closed ecosystem is a good thing. Note the assumption is that the FF tablet is used for only that, nothing else.
 
Steamflyer said:
What would that look like? Of all the apps out there, FF is one of the most polished intuitive and easy to use. For the GA IFR pilot, it does everything one could want. So to eat their lunch, what would the other sort-of-there EFBs enable? Straight copy for cheaper? Maybe, but for most heavy duty users, a 50% discount wouldn't move people away from FF. That said, their former developers will find work easily in the EFB space, hopefully with Garmin so their product becomes equally as good. Competition and choice is always best.

Never underestimate first mover advantage - probably some of the UI elements in FF could be better, but for the tens of thousands of users from J3 to 777, the interface is learnt by now and more than adequate. Now if it stops working, or FF updates are no longer in sync with the numerous and essentially useless iPadOS updates, then they may slowly lose their advantage.
Click to expand...
I disagree with it being among the most intuitive and easy to use. Many of my private through commercial students struggle to use it. After trying out most of the other EFBs out there, foreflight could benefit from implementing some UI ideas from others. There are really only two reasons I use it. It is more stable in my experience. I have had app crashes during flights with the other EFBs. And most of my students already have it and I need to be familiar with it to be a better teacher.
 
Steamflyer said:
Never understood the need to avoid buying a $500 tablet that runs iOS to be a FF participant
Click to expand...

I have an iPad mini. But I want to be able to use my EFB on my Android phone also, since I always have it with me. Plus I want a backup device in the air. I repurposed my old phone as a dedicated nav device, so now I have 3 EFBs. The phones are more stable and have longer life than the tablet, so I rarely carry the iPad anymore.
 
Last edited:
farangutan said:
I disagree with it being among the most intuitive and easy to use. …
Click to expand...

Concur.
I think that’s a primacy or preference thing. I’ve never found Foreflight to be particularly intuitive, but my exposure to electronic flight planning was first thru FalconView. On the .civ side, Avare and iFly were much easier to adapt to than FF.

I’ve tried on several occasions to make the switch over to FF, but for me it just hasn’t clicked. I also feel like FF is overwhelming in the amount of info pushed to you as a new user. I also think there’s many users who don’t fully exploit the features that come with whatever subscription level includes georeferenced charts. That may contribute to why I feel overwhelmed by it.

I’m working on adopting GP since we just added a plane that does two way push with flight plans and it’s been an easier transition, but I attribute it to being familiar with Garmin’s route input formate. My primary reason for the swap was SmartCharts. Garmin just did it better for me than FF.
 
TCABM said:
I’m working on adopting GP since we just added a plane that does two way push with flight plans and it’s been an easier transition, but I attribute it to being familiar with Garmin’s route input formate.
Click to expand...

Seems like flying Garmin glass or a newer Garmin IFR navigator would be a pretty strong incentive to use GP.
 
Steamflyer said:
Never understood the need to avoid buying a $500 tablet that runs iOS to be a FF participant
Click to expand...

The problem is being locked into a single hardware solution that overheats and has poor daylight readability.

Android has multiple hardware choices, included ruggedized tablets with bright displays.
 
Half Fast said:
The problem is being locked into a single hardware solution that overheats and has poor daylight readability.
Click to expand...
Speaking for myself, I've not had problems reading it is daylight although I tend to fly high wing aircraft.
Half Fast said:
Android has multiple hardware choices, included ruggedized tablets with bright displays.
Click to expand...
And this makes programming for Android more difficult because a good commercial program needs to account for these differences gracefully. Apple has always made "WYSIWYG" a priority at the expense of other factors. The PC world, for example, still doesn't do it right after all of these years. If I send a word document to a colleague it gets paginated differently depending on their default printer.
 
farangutan said:
I disagree with it being among the most intuitive and easy to use. Many of my private through commercial students struggle to use it. After trying out most of the other EFBs out there, foreflight could benefit from implementing some UI ideas from others. There are really only two reasons I use it. It is more stable in my experience. I have had app crashes during flights with the other EFBs. And most of my students already have it and I need to be familiar with it to be a better teacher.
Click to expand...
After several decades leading teams that develop firmware/SW devices with UIs, I've learned that everyone in the world is an expert at UI. Line pilots complain about Honeywell Primus, Collins 21, and so forth, but they all learn to use it and make peace with it. There is no perfect UI - I wish FF would not put the "Direct To" button in different places depending on the context - sometimes on the left, sometimes in the middle, sometimes... And I wish there was a button that would turn the screen black save for the traffic and return all the layers immediately on the next press.

None of that matters. What does matter is that in 15 years and probably 3000 hours of using FF, it has never crashed. Not once. Once early on, I was was still using JeppView on a Samsung tablet as there was no small iPad yet. It died on an approach, but FF in my pocket was still good. Wasn't that important, since was already on the ILS and vis was enough above mins to be reasonably sure of completing the approach, but FF was there for the missed and anything else were it needed.

Since it's a tool, the iPad minis on which FF resides is bare bones - it has nothing else loaded but FF. Maybe that helps. I wouldn't dream on running an Android EFB on a dark and rainy night on an approach. But that's me. Each to their own. For reference, probably load/fly about 100 approaches a year, about 20-30 of them in IMC.

Again, it's a tool, not a passion, not an interest, and don't make a dime from it. So as long as the new owners keep it working, will keep using it.
 
Cap'n Jack said:
And this makes programming for Android more difficult because a good commercial program needs to account for these differences gracefully. Apple has always made "WYSIWYG" a priority at the expense of other factors.
Click to expand...
People keep saying this, but I'm on the beta team for iFly, and while yes, there are occasional hiccups with different Android devices (right now they're chasing one down that only affects foldable phones, for instance), there have been at least as many hiccups with iOS devices as well. If anything, I feel like Adventure Pilot (maker of iFlyEFB) has had more trouble over the years stamping out bugs (including display/rendering bugs) that only affect the odd iOS device.

At any rate, AP has been pretty successful in maintaining their iFly product across the whole fleet of Android devices as well as the whole fleet of iOS devices. Whether that's "difficult" for them or not, I dunno, but that's their problem, not mine.
 
Last edited:
Jim_R said:
People keep saying this, but I'm on the beta team for iFly, and while yes, there are occasional hiccups with different Android devices (right now they're chasing one down that only affects foldable phones, for instance), there have been at least as many hiccups with iOS devices as well. If anything, I feel like Adventure Pilot (maker of iFlyEFB) has had more trouble over the years stamping out bugs (including display/rendering bugs) that only affect the odd iOS device.

At any rate, AP has been pretty successful in maintaining their iFly product across the whole fleet of Android devices as well as the whole fleet of iOS devices. Whether that's "difficult" for them or not, I dunno, but that's their problem, not mine.
Click to expand...
Unfortunately, what "people keep saying" is the truth. There is much more variation between the hardware and implementation of the Android OS between vendors than within the iOS environment. There is much less variation simply because there are fewer versions of iOS (phones and tablets). I don't mean upgrades, but rather variations of iOS. I've written lab software using the tablet or phone as a display device (my experience is as valid as anyone else's). There are more variations of the Android OS due to the vendors- Verizon and the other phone companies customize their version of the OS. Let's not forget Samsung, Pixel, Motorola, HTC, Xiaomi, etc.

It does take more testing to maintain their iFly product across the different manufacturers and phone suppliers. While it's their problem, it doesn't refute my assertion that it is easier to test and maintain code in a closed operating system compared to one that is open such as android.

I agree that if they can keep iFly working, that's good. They appear to be doing it well if there is little difference in the user experience between platforms.
 
Cap'n Jack said:
There are more variations of the Android OS due to the vendors- Verizon and the other phone companies customize their version of the OS. Let's not forget Samsung, Pixel, Motorola, HTC, Xiaomi, etc.
Click to expand...
Can you give an example from your personal development experience where you had a carrier-unique problem? In the 10 years I've been part of the iFly beta team and the numerous weird little bugs I've seen reported, exactly zero were related to a carrier-unique customization. That's not even something they ask for in their bug reports. But I only see it from the user perspective, and have no idea what the real sausage-making looks like.

Cap'n Jack said:
It does take more testing to maintain their iFly product across the different manufacturers and phone suppliers. While it's their problem, it doesn't refute my assertion that it is easier to test and maintain code in a closed operating system compared to one that is open such as android.
Click to expand...
Maybe so. But Adventure Pilot has a VERY small development staff. I don't know how many folks were/are coding Foreflight, but whatever it was, iFly has a fraction of that manpower for development. Yet they have a comparable, high-quality product that runs solidly and consistently on Android and iOS. So...it can't be THAT much harder.
 
Last edited:
Steamflyer said:
What would that look like? Of all the apps out there, FF is one of the most polished intuitive and easy to use. For the GA IFR pilot, it does everything one could want. So to eat their lunch, what would the other sort-of-there EFBs enable? Straight copy for cheaper? Maybe, but for most heavy duty users, a 50% discount wouldn't move people away from FF. That said, their former developers will find work easily in the EFB space, hopefully with Garmin so their product becomes equally as good. Competition and choice is always best.

Never underestimate first mover advantage - probably some of the UI elements in FF could be better, but for the tens of thousands of users from J3 to 777, the interface is learnt by now and more than adequate. Now if it stops working, or FF updates are no longer in sync with the numerous and essentially useless iPadOS updates, then they may slowly lose their advantage.
Click to expand...

I think this is an issue that will happen. But which apps will have it is hard to say.

From what I've seen, it looks like pretty much all of the apps are suffering greatly due to their age. From looking at their job listings, it looks like ForeFlight could have a lot of Objective-C code. While others like iFly, may be using old, cross platform tools like Xamarin. If thats accurate, then it makes sense why a lot of their UI looks the way it does. Because as software has progressed, they've been limited by the frameworks they are using. And from my own experience working on enterprise software, it's not an easy thing to get away from.

For perspective, there's been 2 new UI frameworks released by Apple since the iPhones release in 2007. And Xamarin launched around 2011 and was officially deprecated in May 2024.


Half Fast said:
The problem is being locked into a single hardware solution that overheats and has poor daylight readability.

Android has multiple hardware choices, included ruggedized tablets with bright displays.
Click to expand...

I think Apple will continue to invest in better daylight readability. They been highlighting that for the last few years now among various products like the watch. They tend to work slowly, put the R&D into one product, then go mass market once they've perfected it and have their margins make sense.

The problem with supporting Apple + Android is that you're running two independent different code bases to do so. And requires 2 different independent teams. With the desire for feature parity for both platforms, your Android team typically slows down your iOS team.

Primarily due to the configurations of devices. Apple has a few hundred combinations between device, and software version. But they've also invested heavily to minimize that disruption so that you can focus on just testing each individual product. Android last I had to check, had about 60,000. And due to the open source nature, each device manufacturer adds their own code into the phone. Which goes about as well as you would guess
 
Last edited:
And yet iFly works just fine on both my Pixel phones and my iPad mini.

:dunno:
 
Ed Haywood said:
And yet iFly works just fine on both my Pixel phones and my iPad mini.

:dunno:
Click to expand...
I'm sorry, but I don't understand your point. I didn't see that anyone claimed it didn't work reasonably well on both iOS or most Android. Garmin Pilot is also cross-platform and works reasonably well. I only say it takes more effort (and cost) to support the two platforms, more so to support the Android ecosystem well due to the greater variation in Android software and hardware. Companies can, and do, make good software on iOS and Android. That was never in dispute.

Jim_R said:
Can you give an example from your personal development experience where you had a carrier-unique problem? In the 10 years I've been part of the iFly beta team and the numerous weird little bugs I've seen reported, exactly zero were related to a carrier-unique customization. That's not even something they ask for in their bug reports. But I only see it from the user perspective, and have no idea what the real sausage-making looks like.
Click to expand...
The user perspective is very different from the coding, quality control, and support perspective. You are only running stuff on your own, relatively few, devices. A user perspective doesn't translate well into a programmer/ analyst perspective.

To answer your question, Teledyne makes a number of instruments for measuring water flow and for sampling. Some of the instruments use cellular modems for data and could send a text to report a problem. The Teledyne software would pick up the text to keep it from being lost in other texts, and to keep all of the flowmeter information in one place. One major carrier, on their android devices only, would intercept those texts in their own own software so the Teledyne software never saw the texts to log them properly. Now much of the data just goes to Amazon Web Services which replaces one set of headaches with others. AWS works well until it doesn't, and then everyone is down.

Data & Communications | Teledyne ISCO

www.teledyneisco.com www.teledyneisco.com
Jim_R said:
Maybe so. But Adventure Pilot has a VERY small development staff. I don't know how many folks were/are coding Foreflight, but whatever it was, iFly has a fraction of that manpower for development. Yet they have a comparable, high-quality product that runs solidly and consistently on Android and iOS. So...it can't be THAT much harder.
Click to expand...
Please look at post 181 by @RedundancyTanner as he explains it well. iFly may well be running cross platform tools such as the Xamarin mentioned, which reduces the number of programmers- as the name suggests, Xamarin as one example allows a single codebase for multiple operating systems. This has been deprecated into .Net MAUI. However, the quality control still needs to be done on both platforms and at least the most common variants.

I note the statement about not knowing how many people were/are coding foreflight, so I'm curious how one would logically know that iFly had fewer or more programmers then Foreflight. Using cross-platform frameworks, the same number of programmers could be used however, there would need to be more people testing the programs for the reasons I mentioned. No one ever said that iFly doesn't have a good product. Again, look at post 181.
 
Cap'n Jack said:
The user perspective is very different from the coding, quality control, and support perspective. You are only running stuff on your own, relatively few, devices. A user perspective doesn't translate well into a programmer/ analyst perspective.
Click to expand...
Yes, I'm well aware. That's why I've reiterated that same point in almost every reply, as a caveat to my experience/awareness, and also why I specifically asked for an example from the development side to improve my education on the matter.

Cap'n Jack said:
To answer your question, Teledyne makes a number of instruments for measuring water flow and for sampling. Some of the instruments use cellular modems for data and could send a text to report a problem. The Teledyne software would pick up the text to keep it from being lost in other texts, and to keep all of the flowmeter information in one place. One major carrier, on their android devices only, would intercept those texts in their own own software so the Teledyne software never saw the texts to log them properly. Now much of the data just goes to Amazon Web Services which replaces one set of headaches with others. AWS works well until it doesn't, and then everyone is down.
Click to expand...
Thank you. That is a very good example. It is also specifically touching the cellular function of the phone, which may be relevant.

Cap'n Jack said:
I note the statement about not knowing how many people were/are coding foreflight, so I'm curious how one would logically know that iFly had fewer or more programmers then Foreflight.
Click to expand...
Okay, I admit: I have zero clue how many coders there are at Foreflight. However, this whole thread began because someone who presumably worked at Foreflight reported that "40-50%" of the staff was let go, including "entire engineering teams", which implies that there were enough people involved that they could not be easily enumerated. I do have some awareness of iFly's staffing levels, and can say that they do not have any "engineering teams" to speak of, and if they laid off "40%" of their staff it would be quicker and simpler to just type the exact number. So yes, I am making an assumption, but my point stands: I know how much manpower it takes AP to develop and maintain iFly on multiple platforms, and it's not exactly an entire office park's-worth.
 
Jim_R said:
Okay, I admit: I have zero clue how many coders there are at Foreflight. However, this whole thread began because someone who presumably worked at Foreflight reported that "40-50%" of the staff was let go, including "entire engineering teams", which implies that there were enough people involved that they could not be easily enumerated. I do have some awareness of iFly's staffing levels, and can say that they do not have any "engineering teams" to speak of, and if they laid off "40%" of their staff it would be quicker and simpler to just type the exact number. So yes, I am making an assumption, but my point stands: I know how much manpower it takes AP to develop and maintain iFly on multiple platforms, and it's not exactly an entire office park's-worth.
Click to expand...
I have no idea of the numbers, either, but one of the jobs of Foreflight’s engineering teams is to generate performance data and engine-out escape procedures. Given the number of airframes and airports supported for that, I can see the engineering department being fairly substantial, and something I’m not aware of iFly doing.
 
Jim_R said:
Okay, I admit: I have zero clue how many coders there are at Foreflight. However, this whole thread began because someone who presumably worked at Foreflight reported that "40-50%" of the staff was let go, including "entire engineering teams", which implies that there were enough people involved that they could not be easily enumerated. I do have some awareness of iFly's staffing levels, and can say that they do not have any "engineering teams" to speak of, and if they laid off "40%" of their staff it would be quicker and simpler to just type the exact number. So yes, I am making an assumption, but my point stands: I know how much manpower it takes AP to develop and maintain iFly on multiple platforms, and it's not exactly an entire office park's-worth.
Click to expand...

Software teams are small by design. The more people you have on a team, the less productive it becomes. Larger companies make that trade off in speed for stability.

Depending on how critical the systems the team supports are, they will pay 3-5 people to do the work of 1-2 just so they can have coverage. - Be it an overnight/on call situation, someone to work on holidays, or to maintain tribal knowledge in relation to turnover. Due to the size of ForeFlight, I think they likely had that sort of redundancy.


PE firms have all been following the same playbook, so the layoffs are not really a surprise. Buy up or start as many related business as you can, figure out who the high achievers are, then distribute your workforce into teams that write reusable “packages” across your portfolio.

It works because there’s a lot of development that is practically the same, and required in every app. For example, the sign in and paywall screens. If you have a team that is handling 90% of the work required to maintain those screens, you’re going to have a better product because you’re able to invest more time in the team.

And it works because even if you invest 3x the amount of resource you would for an individual app, you’re already saving on the development time alone because you're distributing it across more than 3 apps. A non-aviation related example of this is CoStar Group. They have 17 brands, and at least 4 of them have apps on the App Store.


MauleSkinner said:
I have no idea of the numbers, either, but one of the jobs of Foreflight’s engineering teams is to generate performance data and engine-out escape procedures. Given the number of airframes and airports supported for that, I can see the engineering department being fairly substantial, and something I’m not aware of iFly doing.
Click to expand...
Overall, the people who write software are manipulating the data into a useful format, not collecting or doing the data entry.

The team here would likely be a business or data team thats rarely supported by an engineering team, as their job is already complete. - They are only needed when things break or a new feature is added.

To give a real life example, it took me all of December to put a pipeline together to download, process, and distribute a couple of spreadsheets worth of data from the FAA’s NASR into my EFB. Because I had to create each system for the workflow. Last week, I added the 3 spreadsheets related to Fixes AND did the UI work needed make it useable in app all in a single day.
 
Last edited:
RedundancyTanner said:
Overall, the people who write software are manipulating the data into a useful format, not collecting or doing the data entry.
Click to expand...
But the performance engineers are identifying obstacles, changes in obstacles, and changing procedural requirements for clearing obstacles.
 
Bob Noel said:
Ah, yes, the mythical man-year





730 people working feverishly until noon
Click to expand...
That's a slightly different thing. The mythical man month didn't say that the maximum people working on a project was 5. It said that there was a optimal size for the total effort and if you hired enough people to double that, it wouldn't move the needle.

I'm talking about the fact that you can have ten teams working on different parts of the system. For example, there could be a right-sized 3-5 person team working on the FAA adsb daq module and another working on the UI for traffic data. That's ten people working efficiently on a single feature because the feature was chunked into independent pieces. In a product like FF you can repeat that pattern a bunch of times. A few people working on flight planning. A few working on weather feeds. A few working on realtime flight logging. A few working on the data downloader. A few working on the application update. etc. etc. etc.
 
that works if the teams are truly independent.
 
MauleSkinner said:
But the performance engineers are identifying obstacles, changes in obstacles, and changing procedural requirements for clearing obstacles.
Click to expand...

Here's the job description. It highly favors data science over app development.
www.linkedin.com

ForeFlight hiring Performance Engineer in Austin, TX | LinkedIn

Posted 8:02:33 AM. The Aircraft Performance Engineer will play a key role in advancing the design, validation, and…See this and similar jobs on LinkedIn.
www.linkedin.com www.linkedin.com


172andyou said:
But you can have ten small teams, right?
Click to expand...
Of course. Thats where PE is making margin. Instead of 10 apps each with 10 teams, you have 15 teams working across 10 apps doing the repetitive requirements, and 15 teams dedicated to the required domain stuff.
 
172andyou said:
But you can have ten small teams, right?
Click to expand...
Are you saying 10 small teams, all working on the same project? That would be one of the luxuries of large, established firms, but not small or startup companies.

At one point, I worked for a Fortune 500 company that actually did have three teams working independently to continue developing and supporting a large business application. Those three teams were further broken down into various other groups including Software Development, Hardware architecture and tech support.

We had the "Digital Equipment Corp" team that worked on VAX and Alpha VMS.
We had the "Unix" team that worked on Unix systems.
We had the Mainframe" teams" that worked in the IBM Mainframe world. As an aside, it was a big deal when that team installed a washing machine sized disk drive that gave them a "FULL TERABYTE" of disk storage that practically filled a data center about half the size of a football stadium. Now we have two terabytes on thumb drives.

When management had some bright idea of a new product, or a new enhancement, each team would design and present their solution. The Digital Equipment team (of which I was in charge) had the most success, until VMS just sort of withered on the vine, which eventually lead to me leaving that environment and starting my own small business.

But small/startups would not be able to support such a structure.
 
Cap'n Jack said:
Speaking for myself, I've not had problems reading it is daylight although I tend to fly high wing aircraft.

And this makes programming for Android more difficult because a good commercial program needs to account for these differences gracefully. Apple has always made "WYSIWYG" a priority at the expense of other factors. The PC world, for example, still doesn't do it right after all of these years. If I send a word document to a colleague it gets paginated differently depending on their default printer.
Click to expand...
Yep. Friend of mine did development on a tablet app. Because of the variations between every android tablet manufacture and then the OS had minor tweaks for those tablets, it was like writing the app for dozens of different platforms. And then testing required running it on every combination of tablet and OS variation. In the end they decided to go with just an iPad version.
 
avbrief.com

Older iPads Obsolete in Next ForeFlight Update - AvBrief.com

Change may facilitate use of AI in app.
avbrief.com avbrief.com

Thomas Bravo apparently pushing to incorporate "AI" into FF, according to Russ Niles. Could also explain the layoffs if they believe they can replace coders with GPT.

What could go wrong? It's working out so well for Firecrown.
 
Jim K said:
avbrief.com

Older iPads Obsolete in Next ForeFlight Update - AvBrief.com

Change may facilitate use of AI in app.
avbrief.com avbrief.com

Thomas Bravo apparently pushing to incorporate "AI" into FF, according to Russ Niles. Could also explain the layoffs if they believe they can replace coders with GPT.

What could go wrong? It's working out so well for Firecrown.
Click to expand...
Cutting off support for 7+ year old hardware seems like a prudent cost-saving measure.
 
You must log in or register to reply here.
Back
Top