It's also true for CRUD app #34, because the hard part is never the implementation, it's dealing with shifting requirements, either due to the nature of businesses, unsufficient understanding of the problem being solved or sabotage from project stakeholders (conflicting agendas, politics, etc.).
When you plan to build a bridge between A and B, everybody can see that the problem being solved is connecting A to B. You then have to match material knowledge and construction experience from other bridges with the specifics of the new location. Also, you define project completion when you can cross the bridge.
When you start out building a "simple form" to solve some business need, nobody agrees on what that need is or what the form should actually solve. Navigating this is research. Also, nobody can tell when the project is indeed finished (i.e. solves the problem).
That does not begin to explain the sometimes orders of magnitude difference between estimates and final costs, elapsed time and required manpower.
I've sat in on meetings with people discussing a new project, it is absolutely incredible how much of the future derailing of a project you can see happen in real time during those preliminary meetings.
A probable clue you can find in this nice video of a product meeting between 'engineering' and 'customers':
This isn't always true even for bridges. Near where we live, the Akashi-Kaikyo bridge (longer than Golden Gate bridge) construction started in 1988. It took 10 years to build it, and during construction the Kobe earthquake hit and the bridge construction had to be adjusted because Kobe had moved.
This isn't always true even for bridges. Near where we live, the Akashi-Kaikyo bridge (longer than Golden Gate bridge) construction started in 1988. It took 10 years to build it, and during construction the Kobe earthquake hit and the bridge construction had to be adjusted because Kobe had moved. (http://www.jb-honshi.co.jp/english/bridgeworld/bridge.html)
If CRUD apps were as cut-and-dried as you're flippantly implying, then they _would_ take a few hours to complete. There have been many, many attempts at auto-generating CRUD-app frameworks: Visual Basic was one, Salesforce is another. They all (quickly) hit a level of fundamental complexity after which the reality of business requirements hits the expectation that "this is _just_ a CRUD app, it should be _easy_!" and real programming is again required. Only now it's required in a framework (that was supposed to speed things up) that hides important implementation details away from you and wasn't really designed for long-term modification outside of a few text and color changes.
(And that's why "engineering" when related to software is filled with mumbo-jumbo and cargo-cultism.)