Liebe Integrationsverweigerer,
ob ihr in Freital, Heidenau oder in anderen Orten unseres Landes lebt ist vollkommen egal, es spielt keine Rolle. Ihr seid der Grund dafür, dass Integration in Deutschland nicht gelingt. Ihr lebt seit Jahrzehnten in diesem Land, habt Arbeit oder werdet vom Staat versorgt und schafft es nicht, Menschen die vor Krieg, bitterer Armut oder Naturkatastrophen fliehen die gleichen Chancen einzuräumen, wie sie euch dieser Staat tagtäglich bieten würde.
Mal zur Erklärung für euch: Man kann sich nicht integrieren, man kann sich nur wohlverhalten und einigermaßen anpassen, dann kann man integriert werden. Daher bezeichne ich genau euch als Integrationsverweigerer. Ihr verweigert Menschen, die alles aufgeben mussten, was sie hatten, die Chance in unserem Land integriert zu werden. Habt ihr euch jemals mit einem dieser Menschen unterhalten? Habt ihr jemals persönlich aus dem Munde eines Flüchtlings erfahren, wie er nach Deutschland gekommen ist? Natürlich nicht!
Glaubt ihr die dumpfen Phrasen, die ihr tagtäglich drescht, wirklich selbst? Nehmen wir exemplarisch die vielen Menschen, die aus Syrien fliehen müssen. Natürlich sind und waren viele von Ihnen nicht arm. Syrer gelten im Nahen Osten sogar als relativ reiches Völkchen - und ihr selbst sagt ja, dass Armut in euren Augen kein Fluchtgrund ist. Ich persönlich sehe das anders und ich wünsche mir manchmal insgeheim, dass geistige Armut einer wäre.
Kein Mensch auf der Welt würde seinen verhältnismäßig gut bezahlten Job, sein Erspartes, sein Haus und Eigentum, vielleicht sogar seinen eigenen kleinen Betrieb aufgeben und erst recht nicht seine Kinder auf dem Mittelmeer in Gefahr bringen, wenn es nicht um Leib und Leben ginge. Warum versteht ihr das nicht? Weil ihr selbst nichts habt, außer euren Ressentiments?
Die "armen" Syrer würden es kaum bis nach Deutschland schaffen, da der Weg zu uns für sie viel zu teuer wäre. Viele davon schaffen es nicht einmal bis in die Nachbarstaaten und irren im eigenen Land kreuz und quer. Die, die es wenigstens raus schaffen, sitzen zu aber-tausenden in Flüchtlingslagern in der Türkei und im Libanon fest, wo es ihnen deutlich schlechter geht, als in den guten Zeiten zu Hause. Glaubt ihr wirklich, dass diese Menschen das auf sich nehmen, weil sie sich zu Hause nicht einmal im Monat eine Coca-Cola leisten konnten?
Der Konflikt in Syrien ist exemplarisch für die in vielen Ländern. Ein Despot, brutale Partisanen und religiöse Fundamentalisten streiten um die Vorherrschaft und scheuen vor keiner einzigen Gräueltat an der unbeteiligten Zivilbevölkerung zurück, nur um die andere(n) Seite(n) zu "beeindrucken". Welcher normale Mensch soll in so einem Umfeld leben können? Wer will dort seine Kinder aufwachsen sehen? Wie unmenschlich kann man sein, gegen diese Menschen auch noch Hass-Posts und -kommentare im Internet los zu lassen? Aus dem heimischen Sessel bei Bier und TV scheint das ganz gut zu gelingen.
Macht es bei der erschütternden Geschichte von Ailan Kurdi bei euch nicht langsam klick? So spielt sich das tausendfach auf dem Mittelmeer ab und ihr wundert euch wirklich, dass es vorwiegend junge, starke Männer lebendig schaffen dieser Hölle zu entkommen?
Oder die "Jungs" aus Afrika, die hunderte Kilometer zu Fuß zurücklegen, nachdem ihre gesamte Familie alles zusammengekratzt hat, was sie noch hatten, um wenigstens einen von ihnen auf diesen Horrortrip ohne Garantie auf Erfolg losschicken zu können.
Ein reiches Land, wie Deutschland, verträgt noch viele Flüchtlinge. Ein alterndes Land, wie Deutschland, braucht dringend Zuwanderung. Natürlich sind unter den Flüchtlingen viele "ungebildete" - Nicht-Bildung hält aber auch viele Deutsche nicht davon ab, sich vom Staat einfach "aushalten" zu lassen - in jeder Hinsicht. Diese Menschen erfüllen oft nicht einmal die Voraussetzungen, um selbst in unserer Gesellschaft integriert werden zu können. Im Gegensatz zu ihnen WOLLEN viele Flüchtlinge sich integrieren lassen und zeigen ein starkes Bedürfnis Bildung zu erlangen, die sie in ihrem Heimatland vielleicht gar nicht erreichen konnten - aus politischen, religiösen oder finanziellen Gründen. Diese Menschen geben unserem Land nach der anfänglichen Integration und Investition, die wir in sie als Gesellschaft tätigen, unsere Bemühungen in vielfacher Form zurück. Ich persönlich zahle meine Steuern und Sozialabgaben deutlich lieber für einen integrationswilligen Flüchtling, als einen integrationsunwilligen Deutschen.
Unter den Flüchtlingen sind aber in der Tat auch viele gut ausgebildete Fachkräfte, die den besonders besorgten Bürgern in unserem Land ganz sicher keinen Arbeitsplatz streitig machen werden - Thema Bildungsniveau. In Ländern, wie den nordafrikanischen Staaten oder Syrien herrschte keine generelle Armut und Ungebildetheit. Sie sind Schwellenländer, oftmals dicht an den Standards vieler Industrienationen.
Habt ihr euch mit diesen Ländern eigentlich mal genauer beschäftigt, wenn ihr die Angst vor dem Islam heraufbeschwört? Viele dieser Länder waren lange Zeit dicht an der Säkularität. Einige deutlich dichter, als Deutschland heute. Dafür herrscht in diesen Ländern mittlerweile absolutes Chaos, nachdem die westliche Welt die Jagd auf die Diktatoren in diesen Ländern - zu Recht - ordentlich angefeuert und unterstützt hat. Leider wurde - mal wieder - vergessen, dass man diese Länder auch danach noch unterstützen muss.
Wer von euch, die den Untergang des Abendlandes heraufbeschwören, ist eigentlich praktizierender und gläubiger Christ? Religion ist immer etwas komisch, in jeder Religion gibt es Spinner. Es gibt aber auch jede Menge Spinner, die keiner Religion anhängen. Nicht wahr?
Ich wünsche mir ein Deutschland, dass seiner Verantwortung als eines der reichsten Länder der Erde nachkommt, wenn es darum geht Menschen zu helfen, die vor Krieg, Not und Elend fliehen MÜSSEN. Dies bedeutet auch, dass wir uns viel stärker dafür einsetzen müssen, dass Millionen von Menschen gar nicht mehr fliehen müssen. Aber auch da seid ihr dagegen - denn auch das kostet Geld und Mühe. Kann unsere Gesellschaft euch integrieren? Wollt ihr euch überhaupt integrieren lassen? Ich persönlich sehe deutlich größere Chancen dafür, dass uns dies mit den hunderttausenden Flüchtlingen gelingt, die uns dieses Jahr erreicht haben und noch erreichen werden, als mit euch.
Samstag, 5. September 2015
Donnerstag, 6. November 2014
On the run...
Today I've read yet another Facebook post in a PHP group. T'was something similar to "Look at this _fastest_ PHP framework - EVER. Faster than all others"
So. Define fast. The posted graph contained some bars and some figures. Okay. These were numbers. Only numbers. No description of the test case. No description of the features of the compared frameworks. So how can you compare apples and oranges?
I use PHP - among others, I liked PHP. But hey, to be fair, if you NEED performance and speed in your web application you should not even think of PHP. There are reasons, why big, fast, secure web applications are build with Java, Groovy, .NET and other technologies. Of course there are companies - like Facebook - who managed to run large, high performant systems with PHP. But in fact, compared to other technologies, they have to throw money at the problem and invest a lot into hardware. But on the other hand they really use PHP for what it was designed for - to present something to the user's eyes. You have underlying APIs. They are written in a lot of different languages.
Why can't people "use the right tool for the right job"? Especially in the PHP community I constantly face people who are talking and acting like "All I am able to use is a hammer, so every problem is a nail for me". Sorry guys - learn!
As an employer of Software Developers, Engineers, Architects, ... I tend do name them exactly like this: Software Developers, Engineers, Architects. I will not hire a PHP Developer or a Java Developer. Developers must be willing to learn. They must be flexible. They should not switch technologies every now and then, because then you can't build up experience. But they should never say "I will use technology XYZ until the end of my career". But this happens, all the time. And this is the reason for the Speed Race of frameworks.
Sometimes you should get the head out of the hole you're sitting in and look over the edge. What's the problem with other technologies for you? Why would you rather tend to throw the achievements of modern programming (OOP, Clean Code, Unit testing) away only to stick to your old technology and use new frameworks that may be fast, but don't even provide any modern programming methodologies? All these fast, 'modern' PHP frameworks use static methods - happy inheritance, integration and unit testing!
Instead you should put your efforts into creating Service Oriented Architectures and replace your services with fast running microservices in a second step - created with a technology that meets the business needs of every single service.
You have the choice: Either your software is on the run or you are in a constant haste to not lose your performance in a growing software system.
So. Define fast. The posted graph contained some bars and some figures. Okay. These were numbers. Only numbers. No description of the test case. No description of the features of the compared frameworks. So how can you compare apples and oranges?
I use PHP - among others, I liked PHP. But hey, to be fair, if you NEED performance and speed in your web application you should not even think of PHP. There are reasons, why big, fast, secure web applications are build with Java, Groovy, .NET and other technologies. Of course there are companies - like Facebook - who managed to run large, high performant systems with PHP. But in fact, compared to other technologies, they have to throw money at the problem and invest a lot into hardware. But on the other hand they really use PHP for what it was designed for - to present something to the user's eyes. You have underlying APIs. They are written in a lot of different languages.
Why can't people "use the right tool for the right job"? Especially in the PHP community I constantly face people who are talking and acting like "All I am able to use is a hammer, so every problem is a nail for me". Sorry guys - learn!
As an employer of Software Developers, Engineers, Architects, ... I tend do name them exactly like this: Software Developers, Engineers, Architects. I will not hire a PHP Developer or a Java Developer. Developers must be willing to learn. They must be flexible. They should not switch technologies every now and then, because then you can't build up experience. But they should never say "I will use technology XYZ until the end of my career". But this happens, all the time. And this is the reason for the Speed Race of frameworks.
Sometimes you should get the head out of the hole you're sitting in and look over the edge. What's the problem with other technologies for you? Why would you rather tend to throw the achievements of modern programming (OOP, Clean Code, Unit testing) away only to stick to your old technology and use new frameworks that may be fast, but don't even provide any modern programming methodologies? All these fast, 'modern' PHP frameworks use static methods - happy inheritance, integration and unit testing!
Instead you should put your efforts into creating Service Oriented Architectures and replace your services with fast running microservices in a second step - created with a technology that meets the business needs of every single service.
You have the choice: Either your software is on the run or you are in a constant haste to not lose your performance in a growing software system.
Samstag, 29. September 2012
Pragmatism 3/5 - No solution without a problem
Sorry for letting you wait so long for this post. But I think pragmatism also means to get off every now and then. So I'm back from vacation and ready to get back to all that thoughts about pragmatic development.
This time I would like to talk about the dilemma every developer has every now and then: The very disturbing relationship between "problem" and "solution".
Without a problem there is no solution! Really?
The most obvious relationship between this two terms is that there will be no solution if you don't have a problem. You have a problem and you try to find a solution for this problem. This is your job. You do this all day and nothing else - getting into trouble (tasks by your Boss, Customer, Product Owner, Project Manager, Game Designer, ...) and try to get out with a good solution. What do you think about this statement? Is it true?
Well it depends. To explain that we have to make clear what is a "problem". Think of all the inventors. Was it always really a problem they had before they invented things? Is a simple idea "This could be done better" a real problem? If you think like this than refactoring is problem solving for you. You just try to improve things, make them more reliable, performant or nicer and better readable.
Often refactoring produces a lot of good ideas and solutions. I personally think that these improvements are not a problem or task, but kind of play instinct of a developer. Many good solutions were created accidently while trying to improve or rework completely other parts of a software. All depends on complexity. Modern software solutions and systems are so complex that you sometimes don't know how your working day will end up when you start with refactoring some classes in the morning. And this is why there can be real good, creative and innovative solutions without having a problem or task.
Without a solution there is no problem! Really?
This experience is made very often by you? You present and implement a great solution for your problems, tasks, stories. And what happens? Everything works fine - until THAT day. Your nice solution module starts hiccupping. A bug, or maybe two, or more...
So you think: "If they hadn't wanted to have this one feature, the project won't struggle now." Many developers think this way in these situations. But...
Wouldn't it be much more true to think: "If I hadn't worked that sloppy, if I had written Unit Tests, if I had used libraries instead of writing everything by myself, than I wouldn't be in such a trouble now!"
So try to think what comes next when you implement something the next time. Try to explain why you need some minutes and hours for your Unit Tests. The next time you get in these troubles just measure the time it took you to solve the problem. Then try to imagine and estimate how long it would have taken you to write the essential Unit Tests. It should be very surprising if it takes more time writing Unit Tests than solving your nowadays problems. If so this will mainly be because you're not used to write Unit Tests. Time consumption for writing Unit Tests can be improved very quick with a little help (pair programming!) and familiarization.
There is no problem that has no solution! Really?
Well you might think this is the easiest question to answer. Let's come back to the definition of a problem. This is closely coupled to the problem domain you're in and to your tools you can use. I've worked in the Games industry, the Aviation industry and I created Laser Shows on a very proprietary BSD-based system. You have very different problem domains in this three industries. The quality demands differ a lot, too. The available hard- and software also isn't really comparable to each others.
So the most simple answer to the problem is: It depends (again). So let's first face the hardfacts.
If you are dealing with problems that are NP-complete then you are allowed to say: "There are problems that have no solution." But keep in mind: This is only true for you, for us, the developers (and the mathematicians).
But what about all other problems? Well there is a solution. The question is: What is the best solution? THIS is the core problem of pragmatism. Pragmatism means to find the RIGHT solution. And RIGHT is a variable. It depends on objective (!!!) (not your own) quality demands, available hard- and software, available time (yes, deadlines really exist!), available developers, knowledge and hundreds of thousands of parameters.
So how to find a RIGHT solution? First you have to understand your problem. To do this you can either prototype to get an understanding of your problem domains (throw away code!) or rely on a framework and add functionality while developing the feature step by step and maybe rollback, extend, change if you run into the wrong direction (reversible code). Prefer both, when possible!
The most important thing to keep in mind is: You will only come close to the RIGHT solution. But that's okay. This is your job. Do your best, do it professional, methodological, scientifical, reproducable to come close to the RIGHT solution. The first principle of pragmatism is: DO!
This time I would like to talk about the dilemma every developer has every now and then: The very disturbing relationship between "problem" and "solution".
Without a problem there is no solution! Really?
The most obvious relationship between this two terms is that there will be no solution if you don't have a problem. You have a problem and you try to find a solution for this problem. This is your job. You do this all day and nothing else - getting into trouble (tasks by your Boss, Customer, Product Owner, Project Manager, Game Designer, ...) and try to get out with a good solution. What do you think about this statement? Is it true?
Well it depends. To explain that we have to make clear what is a "problem". Think of all the inventors. Was it always really a problem they had before they invented things? Is a simple idea "This could be done better" a real problem? If you think like this than refactoring is problem solving for you. You just try to improve things, make them more reliable, performant or nicer and better readable.
Often refactoring produces a lot of good ideas and solutions. I personally think that these improvements are not a problem or task, but kind of play instinct of a developer. Many good solutions were created accidently while trying to improve or rework completely other parts of a software. All depends on complexity. Modern software solutions and systems are so complex that you sometimes don't know how your working day will end up when you start with refactoring some classes in the morning. And this is why there can be real good, creative and innovative solutions without having a problem or task.
Without a solution there is no problem! Really?
This experience is made very often by you? You present and implement a great solution for your problems, tasks, stories. And what happens? Everything works fine - until THAT day. Your nice solution module starts hiccupping. A bug, or maybe two, or more...
So you think: "If they hadn't wanted to have this one feature, the project won't struggle now." Many developers think this way in these situations. But...
Wouldn't it be much more true to think: "If I hadn't worked that sloppy, if I had written Unit Tests, if I had used libraries instead of writing everything by myself, than I wouldn't be in such a trouble now!"
So try to think what comes next when you implement something the next time. Try to explain why you need some minutes and hours for your Unit Tests. The next time you get in these troubles just measure the time it took you to solve the problem. Then try to imagine and estimate how long it would have taken you to write the essential Unit Tests. It should be very surprising if it takes more time writing Unit Tests than solving your nowadays problems. If so this will mainly be because you're not used to write Unit Tests. Time consumption for writing Unit Tests can be improved very quick with a little help (pair programming!) and familiarization.
There is no problem that has no solution! Really?
Well you might think this is the easiest question to answer. Let's come back to the definition of a problem. This is closely coupled to the problem domain you're in and to your tools you can use. I've worked in the Games industry, the Aviation industry and I created Laser Shows on a very proprietary BSD-based system. You have very different problem domains in this three industries. The quality demands differ a lot, too. The available hard- and software also isn't really comparable to each others.
So the most simple answer to the problem is: It depends (again). So let's first face the hardfacts.
If you are dealing with problems that are NP-complete then you are allowed to say: "There are problems that have no solution." But keep in mind: This is only true for you, for us, the developers (and the mathematicians).
But what about all other problems? Well there is a solution. The question is: What is the best solution? THIS is the core problem of pragmatism. Pragmatism means to find the RIGHT solution. And RIGHT is a variable. It depends on objective (!!!) (not your own) quality demands, available hard- and software, available time (yes, deadlines really exist!), available developers, knowledge and hundreds of thousands of parameters.
So how to find a RIGHT solution? First you have to understand your problem. To do this you can either prototype to get an understanding of your problem domains (throw away code!) or rely on a framework and add functionality while developing the feature step by step and maybe rollback, extend, change if you run into the wrong direction (reversible code). Prefer both, when possible!
The most important thing to keep in mind is: You will only come close to the RIGHT solution. But that's okay. This is your job. Do your best, do it professional, methodological, scientifical, reproducable to come close to the RIGHT solution. The first principle of pragmatism is: DO!
Dienstag, 11. September 2012
13 Top 10 Books
The plan was to list my personal TOP 10 of books a developer should have read at least once in a lifetime. So the plan didn't work. After filtering again and again there are still 13 books left.
And as it is doen't matter in which order you read them, I just ordered them alphabetically by title.
Agile Software Development, Principles, Patterns and Practices
Robert C. Martin
Prentice Hall International, 2011
Clean Code: A Handbook of Agile Software Craftmanship
Robert C. Martin
Prentice Hall International, 2008
Code Complete: A Practical Handbook of Software Construction
Steve McConnell
Microsoft Press, 2004
Design Patterns: Elements of Reusable Object-Oriented Software
The "Gang of Four": Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Addison-Wesley Longman, 1994
Getting Things Done. The Art of Stress-Free Productivity
David Allen
Penguin Books, Reprint, 2002
Mastering Regular Expressions
Jeffrey Friedl
O'Reilly Media, Third Edition, 2006
Rapid Development: Taming Wild Software Schedules
Steve McConnell
Microsoft Press Books, 1996
Refactoring: Improving the Design of Existing Code
Martin Fowler, Kent Beck, John Brant, William Opdyke
Addison-Wesley Longman, 1999
The Art of Computer Programming, Volumes 1-4: 1-4A
Donald E. Knuth
Addison-Wesley Longman, Third Edition, 2011
The C Programming Language
Brian W. Kernighan, Dennis M. Ritchie
Prentice Hall, Second Edition, 1988
The Clean Coder: A Code of Conduct for Professional Programmers
Robert C. Martin
Prentice Hall International, 2011
The Mythical Man-Month. Essays on Software Engineering
Frederick P. Brooks
Addison-Wesley Longman, 1995
The Pragmatic Programmer
Andrew Hunt, David Thomas, Ward Cunningham
Addison-Wesley Longman, 1999
And please keep in mind: Not everything that is written in a book is true. But there are books you should have read and you should know what they tell. It is up to you to believe or to know better.
And as it is doen't matter in which order you read them, I just ordered them alphabetically by title.
Agile Software Development, Principles, Patterns and Practices
Robert C. Martin
Prentice Hall International, 2011
Clean Code: A Handbook of Agile Software Craftmanship
Robert C. Martin
Prentice Hall International, 2008
Code Complete: A Practical Handbook of Software Construction
Steve McConnell
Microsoft Press, 2004
Design Patterns: Elements of Reusable Object-Oriented Software
The "Gang of Four": Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Addison-Wesley Longman, 1994
Getting Things Done. The Art of Stress-Free Productivity
David Allen
Penguin Books, Reprint, 2002
Mastering Regular Expressions
Jeffrey Friedl
O'Reilly Media, Third Edition, 2006
Rapid Development: Taming Wild Software Schedules
Steve McConnell
Microsoft Press Books, 1996
Refactoring: Improving the Design of Existing Code
Martin Fowler, Kent Beck, John Brant, William Opdyke
Addison-Wesley Longman, 1999
The Art of Computer Programming, Volumes 1-4: 1-4A
Donald E. Knuth
Addison-Wesley Longman, Third Edition, 2011
The C Programming Language
Brian W. Kernighan, Dennis M. Ritchie
Prentice Hall, Second Edition, 1988
The Clean Coder: A Code of Conduct for Professional Programmers
Robert C. Martin
Prentice Hall International, 2011
The Mythical Man-Month. Essays on Software Engineering
Frederick P. Brooks
Addison-Wesley Longman, 1995
The Pragmatic Programmer
Andrew Hunt, David Thomas, Ward Cunningham
Addison-Wesley Longman, 1999
And please keep in mind: Not everything that is written in a book is true. But there are books you should have read and you should know what they tell. It is up to you to believe or to know better.
Pragmatism 2/5 - Postmodernity
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
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
Mittwoch, 5. September 2012
Pragmatism 1/5 - Most stressed "pragmatic"
Don’t you think about “pragmatic” as something to be good, clearly understandable, easy, fast? I did. Maybe I still do. But if you keep your eyes and ears open you will recognize that there is also a “pragmatic” on the other hand.
But the most annoying thing is: There’s a “pragmatic” everywhere.
Every job description wants you to be a pragmatic guy. Every task should be done in a pragmatic way. The pragmatic solution is always the best one, they say.
I say: “The pragmatic solution is the only solution.” Pragmatism is the core principle of Agile Development - only do what’s needed now, at this moment; Don’t do less; Don’t do more; Do it safe (tested); Concentrate on it; Don’t waste your time. That’s pragmatic! And everybody out there say’s they do Agile, so they all must work pragmatic.
But why do they have to tell everyone, that they are so pragmatic?
Simple question, simple answer? Let’s have a try.
Caution: Such a situation creates fireworks of Anti-Patterns.
So there is really no simple answer for me to that question. But if you realized that you fit into one of the three approaches you have to get up off your butt and do something.
And as pragmatism comes through knowledge I would likely guide you a way through this swamp of information about this topic. So part two ("Postmodernity") will provide you with some first hints and solutions within the next days.
But the most annoying thing is: There’s a “pragmatic” everywhere.
Every job description wants you to be a pragmatic guy. Every task should be done in a pragmatic way. The pragmatic solution is always the best one, they say.
I say: “The pragmatic solution is the only solution.” Pragmatism is the core principle of Agile Development - only do what’s needed now, at this moment; Don’t do less; Don’t do more; Do it safe (tested); Concentrate on it; Don’t waste your time. That’s pragmatic! And everybody out there say’s they do Agile, so they all must work pragmatic.
But why do they have to tell everyone, that they are so pragmatic?
Simple question, simple answer? Let’s have a try.
The situation
In general everybody who states his pragmatism all the time means that he works dirty, that he does not give a shit on quality and that he doesn’t care about what happens to his work tomorrow. It’s kind of a very queer interpretation of a “let-it-crash-design”, an obviously way too literal interpretation.The “Self-fulfilling prophecy” approach
So if you’re constantly telling yourselves being or doing “pragmatic” by meaning “sloppy” you maybe hope that one fine day you will really be a pragmatic worker. Well this won’t happen, I guess both of us know that. But do you know why? Becoming pragmatic, creating pragmatic solutions, is hard learning and hard work. It will never happen out of the dust. If you don’t put any effort in becoming pragmatic, you can tell yourselves a lot but it will always be a lie.The “Distraction” approach
Maybe you are in the soup. Deep! And maybe you don’t even know it, but you could feel it. Or you exactly know it and continue your work, because everybody wants you to (this would be a perfect Escalation of commitment). Well you have to tell something - yourselves, your co-workers, your boss. So being pragmatic sounds great. Generating a whole bunch of pragmatic solutions - every day - sounds even better than great. So you’re telling exactly that. But in fact you’re trying to keep your Big ball of mud alive.Caution: Such a situation creates fireworks of Anti-Patterns.
The “Junior” approach
From my experience I have to say that especially Juniors (Developers, Project Managers, Product Managers, …) tend to overstress the “pragmatic”. Let’s be kind to them and just say “they do not know better”. This goes into the direction of my former post. If there are no real Seniors to tell and show them what “pragmatic” really means, your entire company runs into big troubles: Nobody in your company will ever know what “pragmatic” is about.So there is really no simple answer for me to that question. But if you realized that you fit into one of the three approaches you have to get up off your butt and do something.
And as pragmatism comes through knowledge I would likely guide you a way through this swamp of information about this topic. So part two ("Postmodernity") will provide you with some first hints and solutions within the next days.
Montag, 27. August 2012
Don't fix it, if it's broken
I talked about the buggy games some days ago. Today let's have a look on what happens when a bug was found.
Nowadays the number of bugs in online games is so high that most of them will survive the whole life cycle of the product. The most important thing about a bug is not how much it will cost to fix it but how much it will cost to not fix it. There are two simple reasons for that: On the one hand a bug that don't hinders a user to pay or makes the player leave the game is not really a problem and sometimes you manage to implement a Bloombug. On the other hand fixing bugs in online games is always expensive just because of the great code quality.
So you will fix only a few of the bugs. That's fine to me, it's your product. But from this attitude there comes the famous word "Don't fix it, if it's not broken". It mostly comes from Producers and Managers who fear costs. They always fear costs. That's why in a way THEY are responsible for the bugs and not their developers.
So if everyone went through this world with that "Don't fix it, if it's not broken" attitude we would be sitting on the trees nowadays with the club in our hands and trying to make fire with a flintstone. This is a sentence that expresses fear. It does not express any kind of security, it's only fear. Fear of change. Fear of costs. Fear of invention.
So if you fear to invest in invention how will you stay or become the market leader of tomorrow. You will always be a copy of someone who really had the courage to face the risk of inventing or discovering new things.
Nowadays the number of bugs in online games is so high that most of them will survive the whole life cycle of the product. The most important thing about a bug is not how much it will cost to fix it but how much it will cost to not fix it. There are two simple reasons for that: On the one hand a bug that don't hinders a user to pay or makes the player leave the game is not really a problem and sometimes you manage to implement a Bloombug. On the other hand fixing bugs in online games is always expensive just because of the great code quality.
So you will fix only a few of the bugs. That's fine to me, it's your product. But from this attitude there comes the famous word "Don't fix it, if it's not broken". It mostly comes from Producers and Managers who fear costs. They always fear costs. That's why in a way THEY are responsible for the bugs and not their developers.
So if everyone went through this world with that "Don't fix it, if it's not broken" attitude we would be sitting on the trees nowadays with the club in our hands and trying to make fire with a flintstone. This is a sentence that expresses fear. It does not express any kind of security, it's only fear. Fear of change. Fear of costs. Fear of invention.
So if you fear to invest in invention how will you stay or become the market leader of tomorrow. You will always be a copy of someone who really had the courage to face the risk of inventing or discovering new things.
Abonnieren
Posts (Atom)