I think books on software management and process are mostly lost on someone who hasn't been involved in the process. (Hell many of those books are lost on project managers)
I think the most important subjects to teach students are javascript, css, & sql (or mongo). Before you teach a beginner wood worker the "Zen of wood" you teach them how to cut a piece of wood without sawing off a finger.
The rest will come later.
I think that's true and fair. However, once some experience has been acquired, I believe it's helpful to evaluate whether it's good experience or bad experience. Comparisons against the literature can be helpful at that point. Case in point: I tried reading 'The Psychology of Computer Programming' in college, but it didn't make much sense to me. Coming to it 15 years later, I realize it'd have been the perfect companion to my first five years in industry, naming and describing problems I'd faced and solutions that only came through experience more painful than reading.
I agree that you should teach the practice. My ideal education would be co-ops combined with a reading course or two on the canon.
Also detailed histories of the devdlopment of large and complex software needs to be written and studied, but I just don't see it happening.
E.g. explaining an interesting or significant software problem and it's surrounding environment from each decade for the last 7 or so decades.
This seems to be a common falsehood propagated by Agile consultants and swallowed whole by an industry that doesn't know any better.
It doesn't look like the waterfall model was ever used on a significant scale; not as far as I remember, anyway.
Well - yes, it was used, and still is: it's the default if you're not careful or if you don't think very hard or realistically, or are very naive. The confusion is that is was only given a name to disparage it: W. Winston Royce observed that the way most people managed software projects was completely unrealistic and didn't take into account changing requirements. He called it "waterfall" as a way to underscore how inflexible the default "write down all the requirements, then write down how long they're going to take, then do them in that amount of time" approach was.
Unfortunately, most people who adopt what they refer to as "agile" processes are still stuck in that same mindset; they think that, by having daily standups, putting in JIRA tickets, and referring to every two weeks as a "sprint", they'll somehow meet the project manager's pipe dream of 100% predictable software development schedules.
- Feedback loops (because problems or deficiencies will arise)
- Involving the customer (because you don't want to spend 12-60 months building the wrong thing)
- Build a prototype (good advice)
- Document, document, document (he thinks 1500 pages is a good target)
The only thing practitioners seem to have taken away is that last bullet. He still made a strong distinction in his model between analysis, design, and implementation. Though, to be fair, at the time "programmer" was more of a technician level and design often involved making detailed designs like flowcharts and such that could be more easily translated into code. These days, design and implementation are really tangled up, and the documentation is awful an non-actionable (I've been on those teams, it's nightmare inducing). People think prose can replace a diagram, so they fill out their 1500 page quota with lots of words but no clarity.
The name came later, and was enshrined in a DOD standard by people who couldn't read past the first few pages. So they entirely missed the lessons learned he was trying to apply to it.
It's available entirely online here http://www.ankn.uaf.edu/curriculum/AxeHandleAcademy/rc/50pat...
It was written in 1986 by the linguist Ron Scollon and his wife Suzie.
I found a paper copy on a free-book shelf outside a thrift store, and consider myself blessed to have stumbled upon it.
I'm going to try an experiment, posting five books I'd put on the list, one per comment. Downvote, upvote, add your own if you like the idea.
I think it's good that it introduces the overall concept of Design patterns, but the book itself isn't really about the general concept of Design patterns.
The book is focused on OOP techniques and tricks. It makes the assumption that OOP is the most general way to modularize things and think about computation and design.
Additionally a lot of the "patterns" aren't actually good, they're actually really bad. Many of the patterns introduced by this book actually increase complexity of a program while giving only an illusory sense of increased modularity and reuse-ability.
Perhaps one needs to have been in industry before and after this book to appreciate how it introduced a common vocabulary, a mechanism for documenting and sharing experience, and a framework for thinking about common problems.
What I think is missing is the idea that design patters are often language smell. They're common patterns to compensate for deficiencies in the language. The GoF is most applicable to C++ code that uses a lot of OOP. Like the previous reply said, reaching for these patterns too quickly complicates things. Like using unnecessarily large words when simpler language would suffice.
By introduced I mean, introduced to the world for the first time. Invented is debatable concept as in was math invented or discovered? I avoid that debate by using the word "introduced."
>Perhaps one needs to have been in industry before and after this book to appreciate how it introduced a common vocabulary, a mechanism for documenting and sharing experience, and a framework for thinking about common problems.
Humans invent vocabulary for everything that they do, giving patterns names is inevitable. I would hardly call it revolutionary. This book just gave the concept of naming patterns a meta name in itself: "Design patterns." I think it's good that this was given a name but its importance is largely exaggerated.
Case in point: Other disciplines of programming don't use the term "Design patterns" or formal pattern names that frequently. In fact, technically, there are tons and tons of "Design patterns" in procedural programming, declarative programming and functional programming, yet experts in these respective fields don't feel the need to give these concepts over-inflated and complicated nomenclature.
Take currying for example. Functional programmers don't call it the "Curry pattern" nor do they refer to it as a design pattern (even though it technically is). A name just arose naturally. No need to give the concept of naming concepts another word.
To take the illustration even further, imagine driving techniques. Should I give the concept of naming driving techniques some name to exaggerate its importance? Perhaps I can, I'll call it: "Vehicular Translation patterns." And instead of talking about cars using regular English like a normal person I'll just communicate like this: "Execute the drift pattern in composition with the slide pattern and inverse throttle pattern to maneuver through that turn." Talking like this helps me sound smarter while obfuscating communication to the point where it can only be understood by a select few. The book design patterns introduced to the programming world what could potentially be done for driving as well. Needless to say, if it's pointless to do this for driving then does that mean it's pointless to do for programming? In my opinion the answer to that question is, "Yes."
In short, use english for most concepts and name things only where it matters and as it comes naturally. No need to invent an entire discipline and inflate it with made up epistemology.
I realize race car driving does have it's own nomenclature but it's not over used to the extent of design patterns nor did they feel the need to give the nomenclature it's own nomenclature (vehicle translation patterns, VTS theory for short)
Or I could just call it english vocabulary within the field of mathematics.
Every single thing you said could be done without the usage of the word "design patterns" and is already done without meta awareness of itself in all fields of engineering, science and anything.
If I were to build a house is there not a language for "architectures, modules, and interfaces" used to make houses more efficient and maintainable? Also it would be (in a way creating vocabulary upon a specific domain)
The difference is for physical architecture it's missing the pompous self importance. It does not need a name for itself. Imagine if it was called "Structural Language Patterns," and every concepts was suffixed with the word "Structual pattern."
You will note "design patterns" is actually derived from physical architecture but physical architecture does not go overboard and give itself a name other than "English Vocabulary" and attempt to communicate with big words where English will make more sense.
Source: started design patterns study group, still active today.
But older me now understands every generation goes thru a phase where they think they newly discovered sex.
When I asked my then teenaged son the difference between "emo" and "goth", he informed me that "goth" is for old people.
English is shared vocabulary. What is the point of "design patterns" when you can already define a word for a pattern in english.
My argument is design patterns is 100% the abuse of words.
Given a concept, I name that concept "Gloop" and make it part of a defined word in the "English Language."
Given a concept, I name that concept "Gloop pattern" and make it part of a defined word in "Design patterns."
Independent of the definitions or assuming both mean the same thing, the two actions are one in the same. There is no benefit of using one technique over the other.
Let's give you another angle: Defining a term under the umbrella of "Design patterns" doesn't make that definition any more precise than if you defined that term under the umbrella of the english language. There is no difference period.
Design patterns is shared vocabulary. English is also shared vocabulary. But the words "Design Patterns" is part of the "English Language." By creating the term "Design patterns" in the "English Language" you are essentially recursively adding complexity to the english language by defining a redundant concept in the same concept.
Just use english. Define the pattern in english, there is no need to define the pattern in "Design patterns."
Additionally, many patterns are better described with existing english words. Why use Facade pattern, when you can just say Object wrapper. The word "Design patterns" inserts a sort of false formalism and elitism into what is essentially just creating new vocabulary in the english language. The claim I'm making in this paragraph is that while yes it's good to have some formal nomenclature, it's excessive to give all of these patterns their own names. Let the naming and the definitions flow naturally.
Other fields of programming have patterns but they don't try to turn these patterns into some kind of theoretical field with it's own nomenclature. Currying is just currying nobody calls it the "Curry pattern". Recursion is just recursion, nobody calls it the "Recursion pattern."
My personal position on the value of the art of namings, eg Facade, Proxy, Wrapper, Adapter, was somehow capturing the author's original intent. As distinct from the implementation. How it's meant to be used.
Lofty sentiment coming from someone condemned to decades of code maintenance.
Professionally, methinks design patterns, and their misuse, has been mostly detrimental. Maybe because the notions were taken too literally, treated prescriptively rather than descriptively.
Calling everything a Decorator. When it's actually a Chain of Command. And when you try to patiently explain the evils of silent failures, buried deep in the levels of indirection, to the "senior architect" author, that same architect insults your intelligence and walks off.
The mere utterance of Factory and Singleton in public somehow empowering legions of noobs littering entire organizations (and libraries) with innumerable implementations.
Trying to debug something called a "Write thru Cache" when its anything but.
Etc.
Fisher's Fundamental Theorem states—in terms appropriate to
the present context—that the better adapted a system is to a
particular environment, the less adaptable it is to new
environments.
[0] https://en.wikipedia.org/wiki/Fisher%27s_fundamental_theorem...