I looked at the zend documentation, and it was basically an auto-generated list of function names. I looked through the specific Form class they were using, and it was useless, just a list of function names with no description of what the parameters meant.

The documentation for other frameworks I read was similar.

Actually, they have another project written in a custom framework, which is also a nightmare, but it's less bloated and I was able to figure out how it works by reading the source.

So frameworks are bad because one framework you used was more bloated than the other? It's not just documentation - Googling "zend form prepopulate data" returns a ton of Stack Overflow answers.

I'm not saying every framework is amazing, I'm saying that using public, known frameworks means there is a lot more support available for you out there. Not least because these frameworks have had many eyes review them - the custom framework you used was less bloated this time, but there's literally zero guarantee of quality there.

Yeah, I was googling carefully. It wasn't just a zend form, they had derived from the zend Form class and added their own custom logic. After a couple days, I couldn't figure it out, either by looking at their code or the zend documentation.

> frameworks suck because there's too much extra code > custom code is the solution > root problem was caused by undocumented custom code

Huh?

The way they were using zend was that they had a bunch of classes derived from the zend classes that implemented the actual application logic.

On that project, the outsourcing company had some custom framework they wrote that lived on top of zend, so it was the worst of both worlds.

To me it sounds like the issue you faced was one of maintaining someone else's nightmarish code, not necessarily one caused by a framework. I still don't see how the absence of a framework would have made it any easier to deal with this contractor's work. In my (very) limited experience I would wager that if they'd been left to implement all functionality themselves they would have left you much worse off.

I've seen frameworks degenerate into a mess both for outsourcing firm projects, and projects developed internally.

You might say "They were using the framework incorrectly!", but if it's too easy to use a framework incorrectly, then I don't see the value it provides.

Without a framework, it's much easier to trace the control flow. If the code is in 2-5 files that are explicitly included, that's a lot easier to understand than when files get magically included from all over the place.