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!

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.

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

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.

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.

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.

Inventing Design Patterns

We've got a BIG problem - we don't know how to solve it. Let's invent a Design Pattern!

It seems that the number of Design Pattern inventors has increased dramatically over the last years. Design Patterns are not a standardization and productivity technique or tool anymore, they have become that ultimate "I can fix everything" thing.

Although there are a lot of Design Patterns published, there is no other way for the God-like programming gurus (every company has at least one of them) than inventing new ones. All the time. "Hey I think, I've invented a new Design Pattern."

So what qualifies you to be a real good Design Pattern inventor? Let's have a closer look on that.

1. You know the GoF - It's the Gang of F... Four? Was it Four? Or Five? Doesn't matter! YOU know them! In person! But the most important thing about this is: You must never remember their names! It's the GoF! They have no names! Ah and by the way: Robert C. Martin, Kent Beck, Martin Fowler and all the other never existed!
   
2. You know that they wrote a book. You know it was called "Design Patterns - ... bla bla bla somewhat". And you also know: It's THE book about Design Patterns. There are also no others.
3. You know it contains the Singleton Pattern. And this was the starting point of your career (as a Design Pattern inventor)
4. You know only the Singleton.
5. The first thing you invented was a Statleton / Staticton / Staticleton, you know, this Singleton that loses it's getInstance() method for performance reasons and maintainability - just to reduce the boiler plate code. (Sure, others would call it a static class, but you call it Staticleton) Read the linked post and you know, what we are talking about - and thanks to Steve Yegge again.

So boy, let me tell you some stupid words:

Design Patterns are common practice. You invented common practice? On your own? And you're the only one who uses it?

R.E.S.P.E.C.T. - That's why I call you the God programmer.

Design Patterns are OO - and that's not that o.O you're doing at the moment, when reading this. Try this one.

Boy, you should have understood at least the 23 Design Patterns named by the GoF. You should also have understood that not all of them are good pratice (anymore). Your task: Find out which ones. You should also have understood that the biggest collection of Design Patterns is called Functional Programming Languages.

And please keep yourself informed. Then you will see that there are so many "new" Design Patterns out there and new ones getting published all the time. Maybe you will publish one of these new appearing Design Patterns in the next years. Maybe you also initiate the usage of a new Design Pattern. But you won't never ever be it's inventor for real.

Game developers have fun! Or are they?

Let's talk about the German games industry, especially the German game developers, today...

Working as a game developer is fun. Game developers have fun. All the time. Nearly everyone who becomes a developer became it because he wanted to make games. Cool games.

Imagine you worked as a developer for several years. Also in the gaming industry. What are you looking at? You can see a lot of developers, a lot of enthusiastic developers who want to change the world. Do they? Kind of!

Have you ever wondered why EVERY game is buggy?

Well look at these guys. They have fun - and I'm really sure they do so - I know it. I also developed games, and I had a lot of fun. By the way: Thanks to the guys! They love their job. And their employer loves them, too. You know why? Guys who are having fun at work don't need too much money. Simple but true.

The best about it: They studied Computer Science because they love games and ever wanted to create games. You know what? That makes them even cheaper.

Now you have some more or less well educated, enthusiastic guys who love their job, do extra hours, every day, because they really love what they do. And they have fun. That's great. They will create high quality games... ummmm... even without... ummmm... experience. BUT we have our Seniors! They've got experience.
How many Senior Developers did you see who stayed in the industry without becoming a manager? Have you ever noticed that nearly every gaming company is always looking for "Senior Principal Lead God Programmers"? And have you ever asked yourself: "What happens to all that (junior) developers who swarm into the industry every year? When do they become a Senior?"

Don't worry - they do. Either while, shortly before or shortly after leaving the games industry. But why does this happen? Because they grow up! Even game developers start to have a life (some of them earlier, some later). You can't feed your children with all that fun you have at work. And I claim that the gaming industry is one of the best teachers for creative, self-contained developers - just because there are so many Juniors you have to be clever and educate yourself. So everyone loves to hire a developer that was trained in the gaming industry. Don't they? They do!

Game programmers might not be the ones that write the cleanest and nicest code, but many of them are clever - some of them are brilliant. And they're willing to learn. And they learn quick. So if you're brilliant, at least clever, and have experience you want to be payed at least good - latest when you realize that all of your friends are payed better.

But there must be some Seniors in the industry. Somewhere. Well. There are! We forgot about two kinds of guys:
The first group are the guys, I honestly respect for what they do and how they do. They are the gods of the industry. But there are very few of them. And most of them usually leave their employer to build up their "own thing" - to make everything better. By the way - by then they become managers, too.
Now let's come to the darkside. The second group are the leftovers. What about the guys who are good, maybe only good enough not to get layed off? Well what would you do, as a manager who has no idea of programming? You have the choice between that guy who managed to survive the last five, maybe ten, years in the industry and the guy who arrived from university - months ago. What do you think, who will become the Senior, the Lead, the boss of the development team?

If you look at the very young browser games creating companies, that popped up out there over the last few years, you can see their very, very young staff. There are Lead Developers with only a few years of experience. They often don't know anything about scalability or performance, or platforms, or professional software development techniques and methodologies, not to speak of leadership and all that unnecessary "soft skill crap". What options do you have, if you have a bunch of Leads who aren't Leads and you hire the real Leads (if you manage to convince one of them)? There is no other chance than lifting up the real Lead to the management level, to not immediately lose him after he arrived. So your structure is getting even worse. Because now you have Lead Developers that are no Lead Developers and you have managers who are no managers. Got it?

Now please ask yourself again why games are so buggy!

At the moment some companies, especially in the online gaming business, try to handle that big issue. And they seem to be successful. Also big players have recognized that you can't grow successfully over the next years or decades if you lose your best staff. Maybe this is THE chance for the German games industry to make a change, to attract the real good developers from outside Germany. But most of all this is a chance to keep their own talents - in the company, in Germany. I know a lot of very good guys that turned their back towards Germany and headed to England, the US or Canada. The Big Players are located there and the talents will follow them.

So let's cheer all the German game development companies and publishers who realized, that there is only one chance to become mature, senior companies by fascinating their Senior Developers and manage to keep them in the company. There is only one way to achieve this goal: Pay fair, treat them fair, value them and their work, teach and educate them.

Never forget: "Human capital" is all you have. It makes your company successful. You will be treated by them, as you treat them!

SOA thoughts

Maybe you've read the legendary "Stevey's Google Platforms Rant" by Steve Yegge - I did so today. If you call yourself a Software Architect or somewhat like this you have to think about his words and sentences.

You. Have. To.

For me the most important statements of him are:

 "But they [Amazon] do services because they've come to understand that it's the Right Thing. There are without question pros and cons to the SOA approach, and some of the cons are pretty long. But overall it's the right thing because SOA-driven design enables Platforms."

"We [Google] don't understand platforms. We don't "get" platforms. Some of you do, but you are the minority."

"A product is useless without a platform, or more precisely and accurately, a platform-less product will always be replaced by an equivalent platform-ized product."

So let's talk about my thoughts and maybe yours.

Did you ever feel like this? Sitting in your chair, reading such sentences and think "We don't understand platforms." Working in the online gaming business means perfomance. Tune up performance. Don't care about code quality. Tune up performance. Don't think about maintainability. Tune up performance. But why? Right! Because "We don't understand platforms."

Nobody cares about SOA, because it's slow - in the eye of many developers in the online gaming industry. But is it really important for a casual social click-based game to be high performant? Is it really important to ignore the opportunities a platform offers? I don't talk about a second Facebook. I talk about internal platforms. About publishing platforms. Regarding the understanding for the importance of a platform: "Some of you do, but you are the minority."

And I think, the ones who will understand the importance of a platform in the online gaming industry will rule the future. You can't beat Facebook. Did you ever think about why? Have you ever thought about what Facebook is? Not? Then go and read "Stevey's Google Platforms Rant". We don't talk about a social network website. We talk about a platform. A networking platform. A gaming platform. An application platform. I fully agree with Steve Yegge - that's why Google+ failed, why it sucked. It never was a platform and it will never be a true platform. Google can build products, Google can't build platforms.

And what about you?