Business : Research
Supposedly the following quote belongs to Albert Einstein:
"If we knew what it was we were doing, it would not be called research, would it?"
Burt Rutan's definition of Research:
If at least 50% of engineers think that it is impossible to do, then it is research. Otherwise it is development.
(My, Martin Vahi, interpretation of Burt Rutan's definition of research, the way I understand it in 2016, is that if the task is to "get something better" and a series of failures, a series of research projects, leads to that "something better", then the series of research projects, all failures included, is one huge development project. From that point of view the term "Research and Development", the "R&D", is not unfounded.)
The essence of research is walking in the unknown, mapping unknown territories. It might be that the hunters are looking for a specific type of animal that they are aware of and can eat, but on their trip within the unknown territories they might discover totally new types of animals, organisms, phenomena that can be at least as useful or even more useful to the original cause than the finding of the animal that they went to look for. It might turn out that the original goal, find animal X, was stupid to start with. Therefore there are no guaranteed results and "success" in research can not be planned or requested by deadline, with an exception of MBA's, of whom most are unconsciously deeply convinced that math and laws of physics do not apply to them and to anyone of their choosing. As the success can not be guaranteed by deadlines, the "hunters" must have considerable amount of food and other resources with them to last the journey. An effort to save resources while having a wide variety of resources in considerable amounts is part of a successful strategy, just like it is with storage shelves of laboratories. It can always turn out that "a lot" is not enough and it is not known in advance, what type of resource is needed. More skillful and experienced hunters have better chances of surviving the unknown and advancing in the unknown territory, but everyone, including the novice hunters, have a chance to find or notice something new.
Practical conclusion is that research should not be done, when trouble strikes, but it should be an active, hard, effort in the background. It does not make sense to start developing a fire-truck, when fire strikes, but fire-trucks will never be available, if they are not developed.
Calculation result is probabilistically flawed, whenever at least some of the related aspects are left out of the calculations or the input data is flawed. As research is a walk in the unknown, it is not known, what aspects should be included to the calculations. In research the calculations results are in a role of a best guess and one should always use one's best guess for choosing a direction, while intentionally compensating the personal bias with randomness, which is in a role of a slight earth-quake to rock the ball out of local extremums(archival copy).
Software development IS RESEARCH. Otherwise it could be completed by copying files from one folder to another. Just like the hunters studying unknown territories will be in trouble, if they do not get any prey at all, proper software developers are inherently interested in getting the job done as fast as possible, because they understand that the competitiveness of their services depends on the price and delivery time. The longer it takes to develop something, the less competitive the service is, regardless of whether the price is a fixed sum per job or fixed sum per development hour.
Consequently some of the MBA types, who believe that software developers should somehow be demanded to develop their skills to be able to offer better service, get away with quite an insult. The insult is usually delivered in a form of "personal development interview". The assumption of that line of thought is that the person that they hired is some slob, who is inherently not up to his job. A counter-question to the "personal development interviews" approach is that why a hell was the developer, who does not follow the basics of his profession, hired at first place and shouldn't developers, who do not care about the quality of the service that they provide, be dismissed?
Well, one way or the other, the insult is received and after a little while proper developers do dismiss the managers, who mistreat them, but often it is also a loss at the developer side, because it might mean that he has to abandon the project, which in turn means that the project will be incomplete and thrown into the history trash bin, which in turn means that the work of the developer is not usable to end users, which in turn means that the work of the developer is wasted and the developer will not be able to receive references, which in a way is even a good thing in the situation, where the project has a shoddy management.
Work Process, Methodology
Different people have different preferences and beliefs. As of 2017_02 I(Martin Vahi) prefer a work process, where everybody works according to their own best judgement without imposing one's own way of work on collaborators. As of 2017_02 I like the approach that real life problems are the test cases that form the starting point and the theory is optimized to cover as many real life cases as possible while being as simplistic as possible. In my preferred ideal case during the development of the theory a set of specially constructed test cases, experiments, is used for speeding up the development of the theory and for testing specific properties of the theory. One way to look at the work process that I(Martin Vahi) prefer is that the real life cases are in the role of "integration tests" and experiments are in the role of tests of specific properties, capabilities, of the theory.