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!
Keine Kommentare:
Kommentar veröffentlichen