Welcome to the second part of the Pragmatism post sequence.
Today we're gonna talk about Postmodernity. You may know it from Arts but do you know what Postmodern Computer Science is about?
First I want to point out the difference between Computer Science and Computer Science! There is the Modern Computer Science and the Postmodern Computer Science. If you attended a University you would have dealt predominantly with Modern Computer Science.
Modern Computer Science focusses on the Program itself. The purpose of Programming is the Program itself. You can plan, design, test, analyze, optimize such a Program. A Program is only an Algorithm and as Mathematics evolves Programs must do, too. The only thing you hardly do while studying these Programs is - Programming. You do Analytics, Maths, Theoretical Computer Science, Analytics, Algorithms, Calculations on Complexity and - did I mention? - Analytics. And if it really comes to Programming you must have done large UML Diagrams, Algortithm Calulations, Planning before starting to program. But then you will write every line of code from scratch as if you were the only programmer on earth who writes the first program ever.
You won't only find this Modern approach in Computer Science but also in Project Management and even in Leadership and Management. The typical representative for the Modern Development process is the Waterfall Model including hierarchical Top-Down-Management. OOP is a brain-child of this Modern Computer Science - it's so beautifully structured and clear, and highly designable.
Postmodern Computer Science focusses on Existing Pieces. It combines these pieces to new bigger pieces of software. But Postmodern Computer Science focusses also on the Creator of the Program - the Programmer, the Team. And it focusses on the Customer, on the User of the Program. A Program has a purpose, it will be used by someone. It should be as good and optimized as possible but it won't be free of bugs and it will also never be complete. A program is called complete when it provides the functionality the user of the program needs right now. Not in the future or past.
Developers are able to do much. All promised crashes (Y2K, ...) because of software problems did not happen. For crashes that happened (multiple financial crises and collapses, ...) software was not responsible, but the "traditional" businesses. So our Programs can't be as bad as everybody tells us they are. So why are we trying to make our lives harder and more complicated than they are?
Agile Development processes are part of the Postmodern approach. But there is more. Domain Engineering, Multi-Paradigm Design, Anti-Pattern Theories, Glueing. Also Design-Patterns are part of the Postmodern approach but they are only a needy tool as the old OOP languages does not provide safe tools and approaches to simple problems, like glueing existing pieces, that thus have to be solved by using Design Patterns. In fact Design Patterns should be damned by Postmodern Development because they produce what they want to eliminate: Duplicate code. The code they duplicate is well formed and standardized, but it's a copy, not a reuse, not glued.
Scripting Languages and most Postmodern Object-Functional Languages are the brain-childs of Postmodern Computer Science. Perl is often named as the first Postmodern programming language, because of its pragmatic approach - It is a glue language. Glue languages combine existing things, no matter which technology these existing things are or use, and create something new from existing parts. That's Postmodernity. No "Inventing the Wheel" all the time.
And why is there not a single pattern, language, approach, technique or technology that results from Postmodern Computer Science? Well, have you heard of "Use the right tool for the job"? That's a typical phrase that can be connected to Postmodernity in Development. There is no Golden Hammer, no Silver Bullet. But the most important thing is: Use a tool and do not create your own one. Without any doubt your self-created hammer will mostly be worse than an existing one, created by a "Hammer-maker".
Therefor Postmodernity doesn't want to replace the Modernity in Computer Science and Development. Postmodernity extends it. You may, you should, use UML Diagrams - where necessary. You should use OOP - where useful. But you must know that there is more. There is Functional and Object-Functional Programming. There is a universe of existing solutions around you. There are Glue Languages. And: There is no unique Big Picture! If you need a Big Picture (which is your entire module, project, system, program - call it as you like) you have to take the (existing) pieces and glue them together. If there is any piece missing, first have a closer look if you really can't find it. If you can't find it, only then start to (re)produce it.
We are living in a world of hundreds, thousands of standards in the IT world. There are so many protocols, APIs, Programming languages, pieces of snippets, libraries, middleware and tool software. There is no uniformity in solutions, but there is nearly completeness for your daily needs. So you have to focus: analyze the needs of your users. Ask them - and explain. If you can't explain, do prototypes! Then glue. Then implement. Immediately. Analyze and plan only as much as needed to finalize one functionality of the software. Then loop back to the user. Show, explain, ask. Go on to the next feature. That is pragmatism in Postmodern Software Development context.
Focus on the functionality, the features of your program, not on your program (code) itself. No over-engineering - if possible no programming at all, just glueing. No exaggerated love for details in your algorithms - if it passes your tests it's done.
But focus also means: Work clean. Concentrate. Don't be sloppy. Test, test, test - automated! No "quick fixes" (because they are neither quick nor fixes in most cases) Instead of writing your own "quick fix" (= dirty hack) try to find a piece of software that does what your buggy piece tries to do and replace your portion of software. Glue!
Now you've read enough - it's time to read:
Notes on Postmodern Programming
Multi-Paradigm Design
Glue Languages
Next time: Part 3 - No solution without a problem
Keine Kommentare:
Kommentar veröffentlichen