|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:
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.
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."
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…
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.
The Principle of the Drunkard's Search
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.
If you lost your keys, search them under the streetlight, because "this is where the light is".
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:
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.
Sergey A Kryukov
modified 14-Apr-19 22:39pm.