In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways.Well, at the time it was alta-vista not google we turned to. :)
The code was pretty straight-forward Java (about the most clever thing was use of forName and assorted reflection), so finding stuff was not a problem. We had many examples; examples as part of the rather good documentation was important for us.
We tried to avoid doing anything complicated. That was part of the point. Negative lines of code was a win.
It was easier to work with and figure out and extend than the alternatives at the time, and arguably still cleaner and more light-weight then what came after.
When the time came to move to some standard Java thing is was no easier (and often harder) to find decent examples or docs.
And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again.
No, not at all.
I really don't get this broad dismissal of all in-house frameworks. Is it so far-fetched to think that a small group of smart developers with business domain knowledge can build fast, lean, code? Maybe I was just lucky to have experienced this, but I don't think it's so rare.
The code was good, clean, Java. We ran into some issues because of garbage collection (we were really pushing things for speed and memory) for some related code but roadblocks due to our basic tools were rare.
Somehow we avoided over-engineering stuff. It actually worked, and worked well.
And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language.
Again, no, not at all. They had little trouble picking up EJBs or whatever was the Java-du-jour, if they needed, but unlike devs who only knew how to piece together beans and JSPs (basically plug-and-play coders) they knew how to handle things when stuff didn't work as expected or as the docs insisted. They could actually program because they actually knew the language.
Contrast this to people who learn, say, only Rails, and Rails conventions, and write very little custom Ruby code. They're at the mercy of the framework because they're married to a particular tool rather then being immersed in the underlying language. Ideally if one picks a framework one should also really learn the underlying language, but given a choice in hiring I'll go with the one who knows the language over one who knows a framework.
Perhaps not every case of using your own custom tools, well-designed for the task at hand, is the same, or does not work out well for every type of programmer.
I have worked places where they used poorly-conceived in-house tools, and it was not good. But that's not the case everyplace, and a business can get a competitive advantage using tools streamlined for their domain.