Crud Is For Beginners

(Allegedly)

I'd say about 40% of all programming is database- and CRUD-related based on analysis of want ads, at least in the US and UK. Even if I was wrong, the authors should still select a wider variety of domains for their samples than what they did, even if that wider selection didn't include DB/CRUD.

If the authors had any intention of their book being a universal and enduring reference, perhaps for decades, and not immediately becoming a laughable showcase of outdated technology, it would have been a sound strategy to avoid any mention of specific domains. The illustration of specific domains would inevitably require examples using technology, APIs, languages and approaches that if they're not already out-of-date soon will be, and this would create the perception -- if not the reality -- that the book was obsolete.

That implies that SystemsSoftware is immune to becoming outdated. Is that your claim? I've seen no evidence their examples were selected to be future-change-proof. It's almost impossible to successfully predict the future anyhow.
SystemsSoftware is a common core of almost all programming -- you'll connect to it, for example, even if you don't develop it -- and it's typically taught at university undergrad level, so its use as general illustration is appropriate. I.e., it's something that every professional programmer, regardless of their working domain, should understand and appreciate. Note that the GoF book didn't mention, as I recall, specific technologies or APIs and used C++ and Smalltalk as characteristically illustrative of OO languages commonly-recognised at the time and considered likely to endure.
You didn't address the question.
Sorry, I thought I answered it implicitly. I'll expand: SystemsSoftware is as prone to becoming outdated as anything else, which is why the GoF book didn't mention, as I recall, specific technologies or APIs and used C++ and Smalltalk as characteristically illustrative of OO languages commonly-recognised at the time and considered likely to endure.
Okay, I'll give them credit for not relying on specific API's. But that's a different scoring point than using a wider variety of domains. Unless you are writing for a specific domain (and state such), it's best to select from a wide variety of domains for coding samples.
Maybe, but there are many domains that will baffle or disengage the reader. I doubt I could plow through financial services or geographical computing examples without falling asleep, and there are aspects of medical informatics that require extensive medical knowledge to make sense, and computer graphics requires precisely the geometry and trigonometry that every reader has forgotten unless they're working on computer graphics. Sticking to SystemsSoftware is probably the best compromise for creating examples that are likely to be appreciated by the majority.
I meant "good" examples from multiple domains, not crappy ones. It's also possible to have crappy SystemsSoftware examples. Or are you arguing there are more easy-to-present examples in systems software than other domains?
Precisely that -- the average SystemsSoftware example is likely to be understood by more readers than the average (say) graphics or database-driven example.
I disagree as a general statement. For example, a "toy" example that helps build up text query expressions may be useful in the future even if SQL itself goes out of style if it focuses on common command string construction techniques and less on a specific query language.
That presumes understanding of "text query expressions" and whatever system is being queried. I'm not sure there's anything particularly illustrative, in terms of OO design patterns, about string concatenation, either.
Text expressions have many uses. And you still have not explained why SystemsSoftware is special and different from all other domains. Just admit you made an erroneous statement and be done with it. Perhaps the authors are just not creative enough to come up with a wider sampling of examples. That's fine, but I'll ding them points for that weak spot.
Above, I did not claim that SystemsSoftware is special. I did claim that "SystemsSoftware is a common core of almost all programming -- you'll connect to it, for example, even if you don't develop it -- and it's typically taught at university undergrad level, so its use as general illustration is appropriate. I.e., it's something that every professional programmer, regardless of their working domain, should understand and appreciate." Certainly specific examples of APIs and the like will become obsolete like everything else, but the GoF made an effort to make their examples generic enough to hold up over time. It's more difficult to make domain-specific examples hold up over time, and they're less likely to be universally appreciated. As for text queries, concatenation of strings to produce them is hardly general enough or challenging enough to warrant a pattern.
I don't believe SystemsSoftware is any less immune to change than a good many domains. I know you will probably disagree and we'll have to leave it at that. In fact, I'd argue that the change patterns in SystemsSoftware is different than that of the domains I'm familiar with such that it risks giving one a distorted view of managing change.
I don't believe SystemsSoftware as implemented is any more immune to change than a good many domains, either. I didn't say it was. As I pointed out above, "I did not claim that SystemsSoftware is special. I did claim that "SystemsSoftware is a common core of almost all programming -- you'll connect to it, for example, even if you don't develop it -- and it's typically taught at university undergrad level, so its use as general illustration is appropriate. I.e., it's something that every professional programmer, regardless of their working domain, should understand and appreciate." The subject of the GoF book was not about managing change; there are books on managing software change (one by Chris Sterling comes to mind), but that's a different subject.
Many programmers are self-taught or came from other semi-related degrees, such as math, statistics, philosophy, law, biology, etc.
The cross-disciplinary programmer seems to be in decline, especially at entry levels.
Could be, but the existence of such a trend doesn't necessarily mute the argument; it's just one factor among many. I see a kind of split between "trade colleges" that focus on specific tools and that use a lot of hands-on training, and "big name" universities that offer more theory and dig deeper into the machine. The first group may only briefly touch on SystemsSoftware.

Whilst roughly 40% of want ads may be database and CRUD-related, that's a poor measure of their actual percentage of overall development activity. Database and CRUD-related positions feature so prominently in job ads because they're mostly entry-level, to be filled from outside via hiring rather than from inside via promotion. They're the modern developer equivalent of working in the mail room.

You are making up things. That's not how it works. Stop guessing from your ass.

Actually, that is how it works. Database and CRUD-related development roles tend to be at the bottom end of the career development ladder. That doesn't mean there aren't senior experts doing database and CRUD-related development, but it's unquestionably where many developers start.

That's utter hogwash. I will agree that CRUD-related development is relatively low paid compared to say embedded programming, but that's because it's easier to pick up the basics of the domain. (It's not that mastering CRUD is easy, but knowing just enough to get started is easier in that than say embedded programming where you have to know more about the guts and hardware constraints.)

What do you think many, if not most, developers work on when they start out in their careers?

It probably depends on the domain. And your "hiring within" explanation only works if people don't change jobs often. Even if you are a domain specialist, you likely work for different companies closely related to that domain throughout your life.

Re "It probably depends on the domain." How about in the domain of custom business applications? Or financial services? Or mobile applications?

What about them? Mobile apps have CRUD screens, I would note.

Yup, I'd bet most new mobile app developers start with a simple CRUD-screen app before moving on to more graphical apps. So what do you think most developers start out doing, when they get a first job in custom business applications? Or financial services? Or mobile applications?

You brought up mobile apps, not me. As far as a given domain, one might start being a tester or customer support for that domain before becoming a domain-specific programmer.

That's not a programming role. I'm referring to first programming roles.

If you spend all that time and money in school to be a programmer in Domain X, you don't want to start out being a programmer in domain Y. A non-programming job in Domain X is often the better career starting path if the domain matters.

Be that as it may, it's irrelevant here. What's relevant here is that many, if not most, new developers -- independent of domain -- start out their programming careers writing CRUD-related applications, when they start writing applications.

If that were true, then CRUD would make for good examples (on par with SS) because of its familiarity to developers, per above. Thanks for making my argument for me.

Now it might, though not when the book was published. On the other hand CRUD is so trivial from a general OO programming point of view that I doubt there are any notable OO patterns in it, but I know there are a wealth of CRUD-patterns that would unquestionably benefit from being documented.

You are making history and facts up. The distribution of CRUD usage hasn't changed significantly since Windows 3.1. Sure, there are far more web surfers now, but their needs reflect needs people have always had: mapping, shopping, collaborating, (e)mail, filing taxes, etc. Besides, I'm reviewing for the here and now, not 1998. And good CRUD is not trivial. GoodEnough CRUD for smaller-scale apps or where users get a lot of training working around oddities is relatively easy compared to other domains, but that doesn't mean "it's easy", especially if you want to do it reasonably well. I'd compare it to the autoharp versus guitar. The autoharp is far easier to get started with than the guitar because the chords are packaged into single buttons. However, becoming a good autoharpest takes skill and practice. Or US soccer compared to US football: kids often start off in soccer rather than football because the equipment and field and safety requirements & issues make starting out cheaper and easier. However, being a top soccer player takes just as much skill and practice as a top football player. Or perhaps chef: you CAN get paid if you are a beginner or lack-luster chef, but it's not the same for brain surgeons. Still, top chefs are as much valued as top brain surgeons (unless you are into weird underground cults). The bottom rung is not an indicator of the top rung or even the middle-rung.

Perhaps another way of saying this is that the barrier to entry for "chef" is lower than "brain surgeon" even though there is a wide range of chef skill and pay levels. There is a wider spectrum of demand for chefs: low-end fry cooks, middle-level for middle-class restaurants, all the way up to celebrity chefs. However, there is no market for low-end brain surgeons (although some of the more stubborn WikiZens appear to be recent customers of such services based on their behavior). You don't want newbies or bozo's on a complex CRUD project anymore than you'd want a newbie brain surgeon. (Typically they pair with experts to gain experience, if I am not mistaking.) The early problems with healthcare.gov show the bad things that can happen when CRUD is done wrong.

In the era of Windows 3.1, CRUD was primarily the domain of ExBase developers, ex-ExBase developers and experienced application developers, not entry-level hires. Times have changed. Now it's the domain of entry-level hires. I didn't say CRUD was trivial in general, I said it was "trivial from a general OO programming point of view." There are no interesting OO patterns in CRUD. There are plenty of interesting CRUD patterns in CRUD.

The peak era of simplicity (low barrier to entry) for CRUD was VbClassic. Since then it has grown more complicated again, especially when it comes to the plethora of choices that often have to be recognized and potentially maintained. (The VbClassic approach faded because it was difficult to support in terms of installation effort and DllHell; while it made life easy for programmers, installers and PC help-desks turned gray over it. In competing with Java, Microsoft also picked up some of the verbosity and learning curve of Java in their VB remake. It made it more enterprise-friendly, but also less approachable for newbies. Microsoft now wants to be a Cadillac dealer, not a Chevy dealer because the upscale market appeared to be much more profitable at IBM and Oracle.)

Re: "There are no interesting OO patterns in CRUD. There are plenty of interesting CRUD patterns in CRUD." -- I don't necessarily disagree with that, but it does beg the question of "why"?

Why what? Why are there no interesting OO patterns in CRUD, or why are there plenty of interesting CRUD patterns in CRUD?

It implies that either the DesignPatternsBook is not complete, or that OO has gaps; both of which are useful information and would count against the book for not addressing them. If looking for a fit to a project, ignoring the gap is like offering a case/switch statement without an "Else/Otherwise" block. "If these conditions, use pattern A; if these conditions use pattern B; if none apply than consider non-OO pattern X". That would be a nicer way to handle gaps instead of ignoring a gap.

None of the above. CRUD isn't an OO programming pattern. It's definitely a UX pattern, and certainly a database interaction pattern, but it's not a programming pattern.
CRUD is a domain, or at least a sub-domain. Patterns are used for implementation of applications in domains. And I would not call it just a UX concern, although it is highly related to UX. It also involves "middle-ware" between UI and the application and/or databases.
Yes, OO patterns may be used for implementing applications in domains, but that doesn't require any new OO patterns, nor does it necessarily require illustration of those patterns within those domains.
So for somebody working in CRUD domains or projects, this book would be almost useless for the shorter term?
Perhaps. If you're building development tools like CRUD frameworks, it would be invaluable. If you're using CRUD frameworks to build CRUD applications without much ancillary processing, I don't think it would be of much value. I've written numerous CRUD-based applications and frameworks, but all the OO patterns were inside the CRUD frameworks. Application development consisted mainly of almost declarative screen specifications with associated event-driven code, though sometimes what was invoked by the event handlers involved OO patterns, but that wasn't CRUD per se. I think what's needed is a CRUD Patterns book. Maybe you should write it?
As an aside, I'd be interested to see what kind of GOF patterns one would find in CRUD frameworks.

{The interesting thing is that the authors did not consider their work complete - see CommentOnCriticismOfTheGangOfFour.}

Kudos to the WikiZen who split the topics. Good call.

Thanks. It was suggested by someone else, though. Left to my own devices, this Wiki would just be one really, really, really long page.

Something like a ParagraphWiki?

No, just one big page.

{Thanks for doing the split.}

"CRUD and OOP Patterns" would be a better title in my opinion, based on the existing content.