|
|
The funniest question in the CodeProject “quick answers” I ever faced was something like
“Everything works correctly until I press the button Start”. 
Sergey A Kryukov
modified 24-May-23 12:14pm.
|
|
|
|
|
If you want to create something totally useless or ridiculous, take it very seriously.
Only then you'll have a chance to succeed.
Sergey A Kryukov
|
|
|
|
|
Why do you need to capture requirements? Because the requirements do not breed well in captivity.
Sergey A Kryukov
|
|
|
|
|
Today, I came across one post which brought this Google search behavior to my attention.
Do the following: load https://www.google.com and enter "recursion". Below the input control, it will output the link "Did you mean: recursion?". Click on it.
How many clicks may it take to understand what is recursion?
Sergey A Kryukov
|
|
|
|
|
I guess it's time to write on yet another popular kind of question from many naive inquirers' of the Quick Questions & Answers forum. The question is reduced to the following schema:
People tell as what they want to achieve, and, instead of a question, we often see the statement:
"I don't know where to start."
When the section "What I have tried" was introduced, people started to write "I don't know where to start" in this section. Unfortunately, seemingly good idea of this section, as an attempt to stimulate the inquirers to write what they try, has failed. This is really sad.
This is my usual comment on such questions:
Unfortunately, this question is not very productive. If you get some answer, your next question probably will be "how to continue?" It is not really important where you start; you can start with one of many different steps. We don't know your current level of knowledge, so it's hard to figure out what kind of help you may need. If you ask such question, it's hard to be sure that you really will be able to use the answer. Not many people like to waste time.
I still think it's a good comment in response to a particular forum question. However, for a blog entry, I have a good deal of things to consider, and that can be applied to many similar questions, and not only the questions of the "I don't know where to start" kind. How to organize and prioritize the work when there is a lot of unknown matter? This is a different story, and some good advice can be useful. How I would deal with such situation? As nearly all developers, I face such situation from time to time, but I have pretty clear vision on how to determine what should be done first and what next. Still, there is usually a lot of possibility, but some general principles can be used. Let's see…
The Principle of the Drunkard's Search
If you lost your keys, search them under the streetlight, because "this is where the light is".
Even though this is considered as an "observational bias", often used for mocking of seemingly stupid behavior, but, after all, is not stupid at all. No wonder that this approach is widely used in scientific research, in particular, in physics.
Why it can be considered a reasonably good strategy in engineering, at certain points?
First of all, this is good because it involves minimal risk of loss in case of failed project. You start the project with something most obvious. You can guarantee the success on this part, so you will have something which works almost for free. If your project fails because you face a brick wall, you still can reuse this trivial part of work for some other project, and you collect some experience. More importantly, when you have some trivial part of work operational, it can give you a platform to get your breath, look around and… see the rest of the problems more clearly. If this trivial part of work requires modification, it will be easy — the work is trivial. Even if you cannot reuse this work at all, it won't be too regretful, because only a minor portion of development time is lost. Not too bad.
Now, I'll describe the possible strategic approach; and this is my own approach, near-opposite to the previously described one.
Do the Hardest Part First
Why? Let's see. It's very possible that you are pretty much sure how to make the whole project, except some less than critical detail, and except some really difficult part, one or couple of them. Usually, the main goal of the project is related exactly to this hard part; and you are not sure if it's feasible at all or not. Apparently, if you leave the hard problem for later time, the whole project can be lost. You really need to make sure you can do the hardest part, so no other works make sense before you make it sure. Prototype the hardest part, and do it as fast as possible. Why? This is because it defines the success or failure of the whole project. Don't be distracted too much by the detail of secondary importance; you can do it later. While in the first, "drunkard's search" approach you should be reasonably accurate, because you may want to reuse this trivial part of work, the "hardest-first" approach can be developed in a pretty dirty way at first. However, it should not be too dirty; it should be thorough enough to eliminate mistakes. The development should be clear enough, because, in this part, mistakes cost too much. You just should not waste time for polishing the code; you can always do it later.
But one can wonder, how can I offer such near-opposite strategies at the same time? I hope the answer is simple:
Combine Different Strategies
You really need to look at the goals of the project are review them on each step. You make some strategic step, plan some works, complete them to certain reasonable extent, and then look again. Here, we come to another key principle:
Get Ready to Modify Decisions at Any Time
It's became a common view during a couple of past decades: development should be iterative and conducted in some repeated cycles. Some could see that it contradicts to the idea of accurate well-planned systematic approach. In reality, the role of this principle is very different: it simply makes the idea of the accurate well-planned systematic approach realistic. But now, the question is: if the strategy should be reviewed pretty often and the decision on next step/cycle can be modified on each iteration, what could be the basis of such decisions? My answer is another principle:
Prototype Everything
There is a really evil misconception: prototyping is a waste of time. Usually, it comes not from engineers, but some managers, such as project managers (it becomes a real disaster if such people don't have engineering qualification). All reasonable and more or less experienced engineers clearly understand: the situation is directly opposite: prototypes save a hell of development time, and reduce development risks greatly. They just should not be polished too well. The other point is less obvious and poorly understood even by engineers: artifacts of prototyping should be stored in the Revision Control System forever, along with the main product.
—SASergey A Kryukov
modified 14-Apr-19 22:39pm.
|
|
|
|
|
Years ago, I've been asked, "what do you think is a good software architecture?"
I answered: 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?
Sergey A Kryukov
|
|
|
|
|
Recursion is always broken.
Sergey A Kryukov
modified 4-Mar-21 2:07am.
|
|
|
|
|
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 us 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?
— Our chef is brainstorming with all the personnel: how to inject pepper in those eggs.
Sergey A Kryukov
modified 12-Mar-17 14:51pm.
|
|
|
|
|
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.
modified 4-Aug-15 10:18am.
|
|
|
|
|
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)
|
|
|
|
|
Thank you, Stefan.
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.
—SASergey A Kryukov
|
|
|
|
|
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.
Kovodstvo, § 149
[Translation into English is mine — SA]
Sergey A Kryukov
|
|
|
|
|
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.
Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime But these days, the realities are changing, and the modern society really needs more modern saying which came to my mind lately.
Give a man an apple and you feed him for few hours; give a man an iPhone, and he will feed Apple for a lifetime
Copyright © 2015 
Sergey A Kryukov
modified 9-Jun-15 15:07pm.
|
|
|
|
|
I'm starting this blog with my notes I plan to write mostly on and around our Quick Questions & Answers forum.
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.
—SASergey A Kryukov
modified 3-Jun-15 21:53pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
