I _do_ work for a multi-national, multi-billion dollar company. It's my day job. On one of my current projects a wrong bit of coding could impact 40 million customers in real time.
I am critical of Adobe's poor performance in figuring out where LR is going. The import process, as changed, is a good example of being tone deaf when it comes to listening to users' desires and expectations. It appears that their architectural planning is haphazard.
But I will take strong issue with the suggestion that "throw a few more engineers at the problem" will solve anything.
First, the skill sets required are rare. There ain't that many folks out there that can do it.
Second, LR is complex. In fact, it's a wonderful testament to the engineers that have worked on it all these years that much of that complexity is hidden from the users.
Third, a new engineer, even an incredibly skilled one, has to spend a lot of time learning how the program actually works...how the pieces and parts all go together. It takes time, at least many months, for an engineer to understand how even a small part of it works. As an analogy, any reasonably competent photographer understands exposure, but asking a competent Canon shooter to explain the ins-and-outs of Nikon's autofocus system the first time you hand him a D810 would be ridiculous.
Fourth, LR is now at version 6. Even with the best code management processes in place, there's going to be kruft, places where a small change in one place will impact a completely different part of the program. I'm sure there's lots of shared code for rendering an image that is used by every module. Making a change in that code to speed up rendering when moving the highlights slider in Develop may break the Print module's use of that same code. Frankly, I'm amazed that Adobe's folks got GPU processing working in LR as well as they did. All of this means that regression testing, which really boils down to "I fixed it here, now let me find out if my change broke any of the myriad other uses of that routine," is an exacting process that only gets more involved in time. It also means that bringing an engineer up to speed takes a lot more time.
I would hope that Mr. Hogarty will indeed learn to listen better to the current user base...and, perhaps, allow more opportunity to allow that base to respond to proposed changes. I miss the public beta program; it would have prevented a lot of heartache in this particular case.
I would also hope that ways to communicate what users want could be qualified more clearly. Too often, users are proposing solutions instead explaining the problem. For example, the problem was slow rendering, but many posts asked for "GPU processing." Maybe that is the right answer, but I'd rather let the engineers address the real problem instead of telling them how to fix it.