Years ago, I've been asked, "what do you think is a good software architecture?"
Good architecture is not the one which contains no mistakes. This is the one where fixing mistakes costs less.
Until now, I don't know a better answer. There are many different criteria of good and bad architecture, but I think its rigidity is the most frequent problem. There are many "opposite" cases when people try to make it overly customizable, but is it really opposite? I'm not sure. Perhaps this is the same problem in a different skin. But we don't see such cases too often. Isn't that because such architectures rarely end up as complete software projects?
I repeat again and again: it's bad to be too much goal-oriented. Ramming some problem more and more can defeat the purpose. Often, "The Truth Behind" lies somewhere outside of the problem itself. Often, the real virtue is not solving the problem, but asking: it that the right problem to be solved? In connection to that, I cannot help being amazed with the way of thinking of some our inquirers. The typical thread looks like this:
Answer: Your problem is: you can never do ABC, it is impossible. To get further advice, please tell as what you really want to achieve. Follow-up question: Then please tell me: how to do ABC?
That means that the person cannot realize one's ultimate goal, because of being fixed on some fictional, imaginary intermediate goal, which is just a misconception, which cannot be reached or would imply total abuse of technology. And it does not matter that the real ultimate goal is never reached.
We had an anecdote circulating, about one of the countries with notoriously spicy, peppery cuisine:
One traveler had trouble with this peppery cuisine, barely able to tolerate so much pepper. One day, he was sitting in a restaurant, thinking "What can I order to avoid getting so much pepper?". He got an idea and called a waiter:
— Please, I want boiled eggs. Yes, just boiled, unshelled; serve the whole eggs, in the shells.
The kitchen did not produce anything for an hour or two; people started to worry.
— What takes so long?
— Out chef is brainstorming with all the personnel: how to inject pepper in those eggs.
The story about pepper in a restaurant reminds me a story with garlic. My wife is allergic to garlic. So, we quite often meet the situation you provided in joke.
As to the unhappy programming inquirers... The truth is that some people not even know how to ask proper question and they are not interested to improve their questions. They expect from us to provide answer for every possible situation. So, the answer should be build as a "map of process": if this then that, if that then other, if other then… else… finally: something/whatever. Conclusion: we have to inform the iinquirer that his question is to vague to answer. Then we should ask him to improve question.
BTW: Have you tried to follow up "The Truth Behind" link? Seems, it's broken.
I understand what you're saying, but I wonder how many that could benefit from it really do.
Perhaps a better way of describing the problems is this:
Do not describe the problem you have in terms of a solution, describe it in terms of the requirements that your solution must fulfil to be correct.
What you call 'ABC' already is the solution that that the inquirer tried. He finds that this solution doesn't work, and asks how to make it work. This is the wrong question to ask. The right question to ask is "what other solutions are there that would fulfil the requirements I have?"
Of course, this requires actually writing down these requirements as well. On a sidenote, I've found that just doing this (writing down the exact requirements) can sometimes open your mind to a real solution - the problem is often that the inquirer didn't actually think about what the requirements really are.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
What you say is a typical aspect of the same problem. Your advice really can help. But often the problem is not that some inquirer does not know in what terms to describe the problem, because this is only a consequence of more fundamental problems, like not knowing what one really wants.
A number of times, I answered some questions of the inquirers who wanted some good project for their school engineering practice, such as the term or course project at school, or even the diploma project. When I worked with my own students, I tried to give them a piece of my own job, and, unfortunately, I still could not say that they helped me a lot. But what to advise when the strangers, students from some school I don't know ask such question? Note that those are people who did not understand that they are asking stranger, someone from CodeProject, people who are not aware of their level of knowledge and experience, school course and their quality, working habits and interests. Can such people get some help? This is not easy. To me, it would be more natural to address to their professors and school fellows, support the culture of sharing the ideas, and so on.
So, I don't think such people can be really helped by giving them what they expect — concrete project assignments. The help should be radically different, something which could encourage them to use their own head. I really offered some advice, but that would need a separate place for discussion.
A while ago, I found a wonderful passage from a book I use to learn some industrial design. It is written by a very famous designer, the owner of the successful leading design studio represented in several countries, often getting very expensive orders. Even though it mostly appeals to young designers, it is very well applicable to students in any creative field of activity, and very much to programming:
Most problems are solved in a wonderfully simple way: you need to take it and make it. For example, young designers often write to the author, asking him to give them a test task, so they could show themselves. The author always gives them all the same task: create your own task and do it. If a designer really worth something (it means, can solve problems), this person will simply bring the samples of excellent works. And, where to get such samples? You need to make them. And, how to make them? Start with something simple, for example, organize the food in your own refrigerator. And what if there is no any food in the refrigerator? Take a pencil and draw it. And what if you have no pencil? From this point — you are on your own.
I think we have one good tradition: some questions are not answered, and not because we don't want to help an inquirer. Just the opposite, we want to give that person much better help: to give one the good change to learn how to help oneself, in cases where it seems feasible and reasonable, when our advice can really help to learn something. And, also traditionally, many use this old saying, which is known to be referred to in English in XIX century, but the saying itself is probably much older.
I collected many answers which I keep answering over and over, but I could simply reference the single source where I answer on the topic. Many are on the questions which can easily be automatically removed by a number of abuse reports, but I gave some interesting answers which I don't want to lose. Moreover, some answers are so controversial. I don't want to argue so much with people who consider any strong opinion as abuse and always preach in favor or modesty, moderation and neutrality and balance. It makes a lot of sense, but often this is so boring! If the whole humankind made these undisputable qualities the top priority, we would never get most of our inventions and other brilliant artifacts of culture. I hope my modest (really modest, no insincerity here) ideas will see more quiet life on the page of my own blog.
More importantly, there are a lot of out-of-format materials which hardly can be in place in any other place. They cannot be answers, articles, comments or other posts, but they can be referenced. Sometimes they won't serve any particular purpose, but still can be interesting, just for fun. But I ask everyone to reference my post with full and correct attribution. The attempt to preserve the original authorship information, mine or other people I want to refer to is one of my goals.
Sergey A Kryukov
modified 3-Jun-15 21:53pm.
Last Visit: 31-Dec-99 19:00 Last Update: 6-Feb-16 19:50