Programming Philosophy 6 - Product and Project
The difference between a product and a project is that there is a plan for developing a product, and there is research when developing a project. If you have some unresolved problem, say you have not yet decided which database to use in your project, then you will need to study this question, that is, investigate. This is called technology research. Research, it is not at all necessary, something completely new on a global scale, if you build a bridge, then you need to explore the ground in this particular place, and until this ground is explored, the bridge, as a product, does not yet exist, while - project. It is not yet known what kind of ground, and therefore it is not known from what to make the bridge, how to strengthen it, it is impossible to calculate the budget and plan the schedule of works.
Of course, any project is similar to a plan, there is a sequence of actions there, they can even set some deadlines, but as long as there are unexplored white spots in it, this is a plan with holes, that is, a project.
If you were able to develop a product and explore many technologies in the process, then you get a competitive advantage in the market, so the desire to get involved not in product development, but in a project, is like a disease. The programmer thinks: now, here we are exploring this little thing, invent it, and tear it up. And any research has an indefinite period, and if you yourself, or the programmer says, “you still have to figure out how to do it,” immediately note to yourself: this is about research, that is, not about the product, but about the project. The project has an indefinite time frame, due to the research.
')
When the project is peculiar thinking in the spirit: for a long time we explore the super-feature, mega-technology, and then quickly we collect everything and get the product. The striking difference of the product is that in it the “collect everything” stage starts very early, almost immediately, and most of the graphics are assigned to fine-tune all parts. In the project, on the contrary, this stage begins much closer to the end of the schedule. The project schedule is like clogging ten thousand nails, you can immediately estimate how long it will take, and methodically hammer in. In general, the project has the feeling that "we have already done this, you just need to do it again for this particular product." Moreover, the process can be repeated on the same schedule by creating another similar product. Many successful projects succeeded precisely because a person who has already seen the entire schedule from beginning to end, leaves the team and clones the entire organizational project, the work schedule and simply does the same thing only better, consciously avoiding research and experimentation.
If, say, your input field sometimes suddenly loses focus or moves it incorrectly, then from the point of view of a project, this is an inessential detail, and from the point of view of a product, this is a flaw that can seriously damage its reputation. Or there are two buttons of the same type on the form, but one tenth of the size, and the other eleventh. A trifle is eliminated in 10 minutes, you need to find the file you need, the right place, fix it, check it. No super technology, but at least 10 minutes off. And in the product of such trifles there are usually hundreds and thousands, they are small, there are many of them and this allows you to use the main weapon of the product developer - to make a schedule. Today we correct thirty jambs, tomorrow, and so for a hundred days, with all the known coefficients, we get two thousand ryushechek and details. And in the project it will not be time.
If I wanted to say that the project is bad and the product is good, I would say that. I just want to clearly separate these two concepts, it seems to me, it can save a lot of effort. The project itself is a wonderful phenomenon, research is also a real work. Moreover, the project can be conducted recognizing the whole probabilistic and gaming essence of research, wisely distributing and designing even these indefinite periods. In the end, this is just an indefinite projection, but you just need to clearly understand what exactly you are doing. I personally, from experience, used to conduct all the research before the start of product planning, all the technologies, principles and rules used should be investigated, there should be no questions left, there should be a fundamental decision at the end of the research that everyone, we take these decisions, aware of them advantages and disadvantages and go to the planning stage, that is, product development.
Research is the search for suitable technologies and tools, the creation of unique algorithms and personnel training, and initial performance studies, and the compilation of a list of necessary features for the customer or the market, and even the search for a convenient operating mode. That is, everything that is not known in advance and cannot be formally determined. That is, by the time the product is developed, that is, a plan and schedule of work, you no longer have white spots, questions, and the plan is made up of solid, tangible, weighty bricks. As soon as you have a feeling that everything is clear, and you just need to work, hammer nails or clone a chip from a chip from a competitor's product, then you can say the product took place. Of course, then it may turn out that it will not be successful, and mistakes were made in planning or in defining the terms of reference, or mistakes in actual practical work, but this will already be taken into account in the next project / product.
The ability to accumulate experience and transfer the algorithm of work from product to product, from project to project, generally distinguishes the person who has embarked on the right path in development. For example, I have long known that changing a font in a button is, on average, at least ten minutes, before it seemed to me that it was a matter of seconds. Typing the building blocks of graphics, the ability to sort all the tasks and subtasks according to the complexity of the execution, the time of execution, the required qualification is the main planning skill. Some types of tasks are not very complicated, but they have a peculiarity to tire memory a lot and then it takes an increased time to move on to the next tasks. If you are a manager of the whole programmers office or a loner, in any case you need to constantly look at yourself from the outside, and not only rejoice that the next small step is completed, and think immediately about the next, but you must constantly think about it and even say out loud and write down what task was solved, how long it was decided, how it is typed, what experience can be drawn for further planning.
In this sense, the development manager, who is not a programmer himself and cannot properly assess the rings in the development chain, is a disaster. Such a person immediately manifests and must be driven, it is usually enough that he was surprised several times, why did it take so long? A programmer’s manager is allowed to be surprised only in case of unexpectedly fast passage of a certain segment of a distance. And that is not desirable. It’s clear that if a programmer has everything in his head and he doesn’t need a deep switch to the moment of a new line in the plan, then he can do something almost instantly. That is, you fixed the button in three different places, it took ten minutes, but it happened so quickly only because it was the same type of work, and it so happened that all three buttons were fixed in a row. But if you had to fix the button in one place of the code, because fix the bug in the protocol, then another button, then find the division by zero, and again fix another button, then each button fix could take ten minutes. Moreover, it is possible to take into account not only the development process at one step and the switching time, but also bouts of enthusiasm and loss of strength. The most important talent of a manager, be it a self-manager, or a team manager, is the ability to track when work is inhibited because of a sudden study. Usually a wrinkled forehead or a desire to distract from work is a good sign. It means that the developer doesn’t have something in his head, he doesn’t keep in memory, the uniform motion on the points of the plan is shut up. Here you need to show experience and deep understanding, and “settle” the question - either realize that research is inevitable and add a bold row of indeterminate size to the plan plate, and throw all your efforts on the solution, or circumvent the issue by applying a proven alternative solution. If you are making a product, your task is not to “work better”, but to adjust the process to full predictability.
An interesting everyday comparison, although it should be understood that any comparison is only a comparison and can only illustrate a certain principle, it is cooking dinner. When you need to feed yourself, you can cook food very quickly, and you can afford experiments and research in the process. A little more salt, a smaller, new seasoning to try, but if you need to make a festive dinner and feed dear guests, then the situation is radically different. It seems that the costs should be linearly scalable, 5 guests, so the estimated costs for a gala dinner are five times more than your own lunchtime snack, but in actual fact, the costs will differ by an order of magnitude, and the choice of ingredients, and the thoroughness of performance and serving spent time. This is a project and a product. No one will experiment with festive soup, and if it does, it will regret it. Guests will come exactly at five, that is, there is a deadline. The cost of serving and detailing, cutting the cheese into thin slices, spreading the jam in an even layer, these are things that are made ten times easier in a regular household meal than in a festive mode. This is the product, it is a festive dinner. The complexity of the performance of a festive lunch or dinner is compensated by the fact that everything is determined in it, each operation is debugged for years, at best the hostess decides on one unusual dish, and it takes a lot of time and energy and is accompanied by oops according to the principle: “I have never done before , I decided to try, do not judge strictly, "looking for a competitive advantage, so to speak. In addition, everything is perfectly scaled, because most of the operations are typical and they can be done by everyone in the kitchen.
It is now a year since I presented my project Deodar to the community. This was originally a typical "Project", the number of studies that needed to be carried out in order to take on the actual performance of the product, was immediately determined by me as huge. Let's start with the fact that the lack of high-quality jerks in the development tools that are interesting to me has depressed me for years, even decades. How many times, installing a new version of your favorite development tool, editor, IDE, debugger, did you wonder how many developers did, and how again nothing changed in essence? In projects with open source, in general, the main tendency to avoid fundamental changes, total refactoring, and instead of attaching to the machine, more and more pens, ozonizers and repainting the doors every time. While a healthy process of iteration of versions should provide for fundamental changes in all areas from time to time. One of these fundamental changes is the solution to the problem, which in everyday language can be called “there’s not enough little things”. That is, there is a great tool, everything is becoming obsolete, but one little thing that is familiar to you, just a little thing is missing, and because of this, a product developed with a resource does not suit hundreds of thousands of man-hours, because of its functionality, the development of which takes one person-day.
It is very important for the developer, as a person who solves non-trivial tasks, to rely on a tool, and dependence on this tool determines strategic decision making in planning.
How many times have you heard the phrase "we decided to abandon ..."? My youth came to the heyday of Borland products in Russia, I learned to program professionally and used Turbo Pascal and later Delphi. In this connection, I have developed some skills of work, a habit to rely on such tools of the environment as F4 (Run to cursor), Control + Enter (Open file at cursor), instant compilation. It became critical for me that I could compile with one button, put a stop under the cursor and start the program, then also terminate it with one button and continue editing the code. When I tried to work in my usual mode on Visual Studio, except for orders of much slower compilation, the need to start the debugger with one button, run the program with another, pre-delete the previous break point and install a new one, was a whole process that I could not distracted. For several days, I wrote a macro that somehow solved the problem. Of course, these are my personal preferences, but the problem is that each programmer has his own personal passions, without them there is no programmer, even the painter has his own personal passions for methods and tools. One of my friends, a machine tool technician, could not work if he did not have a gasoline bath at hand, in which he could instantly wash his hands instantly at any time to the pre-lunch cleanliness. He suffered terribly when he had to work in another workshop where there was no such bath. A trifle, but from such trifles and a working process.
I have always postulated such a thing as the perfection of development tools. You know how the production of the means of production among the Marxists, which distinguishes a developed economy from simply mechanized. My belief that a truly advanced development tool can speed up development not by percentages, but by orders of magnitude, and not only accelerate, but also enable the developer to take on tasks of a different degree of complexity. About five years ago I made an ambitious attempt to create a C ++ IDE that meets my requirements. She was called DaoIDE. For this, I had to solve a few fundamental problems. First, make your own text editor or learn how to effectively use Scintilla or another open source. Text editors I do as much as I can remember. In general, creating a text editor is an example of a complex programming task. Everything can be seen on the screen, and the most complex structure, it is an ideal task for advanced students. My love for text editors flourished when I had to work with the Aldus Page Maker application, I openly admired what this program can do, and it was written in the late 80s and early 90s. I happened to write dozens of text editors from scratch, that is, from scratch. And that's not counting the hundreds of fast prototypes. From the simplest laptops for dos, to systems with complex markup and special requirements. So there was no problem with the editor. Then I had to deal with the debugger, I made many prototypes of the environment interaction with the debugger, based on dbghelp.dll, in pure assembler, through GDB, GDB-MI, WinDbg and various ready-made skirts over them. I was terrified in the process - how difficult it is, how bad everything is documented, it is obvious that no debugger was originally made for embedding into third-party applications. Then I had to deal with the C ++ compiler, my main requirement for it was compilation speed. I had to thoroughly understand the history of the development of existing compilers and make sure that the fastest compiler (precisely in terms of compilation speed, and not in terms of the speed of the compiled program) is Digital Mars C ++ (DMC), formerly Symantec C ++. My reasoning is simple, in the process of developing an application, it needs to be run many thousand times, and an optimized executable output is needed only at the moment of release once. DMC often worked several dozen times faster than rivals, giving a performance close to the familiar Delphi jet compiler. But he did not give the opportunity to debug these executables, due to the object file format licensed a decade ago. MSVC, especially earlier versions, was much faster than GNU C ++. But there were no chances for cross-platform and terrible vague documentation, each, such as determining the type of variable, had to be investigated for days. This project took me at least a year, almost all the time was spent on research.
The C ++ Dao environment project died out precisely because I was convinced of the inapplicability of all existing IDE-building blocks available in the world, primarily compilers, debuggers. Solving this problem, I spent a lot of time studying not only the source code but also the community and the history of the development of these tools. For example, I realized that GCC will never compile quickly, moreover, with each version it will compile more and more slowly, such is the demand of the market and such is the focus of development. Not to mention the fact that the steering committee itself works in a very specific way, and it will never be possible to fundamentally revise the compiler device. The logic is simple, everything is done according to science: lexer, AST, backend, codegen, etc., there is nothing to invent here. When I saw the first video with the stories of the authors of LLVM / Clang I was jumping for joy, it was obvious how much Apple and Google think more creatively and decisively. The GDB device is also a nightmare both historically and technically. Here I must clarify that if I state the horror of these projects, but this does not mean that I do not like them, or I consider them idiots, those who made them.Not at all, these are world projects, including MSVC, C ++ compilers are so complicated that there are only a few of them in the world, and all those who work on them are super-people! You can literally list on your fingers the projects of this level. It just became clear that people are working in a different direction than the one that is close to me personally. And we come back to the idea of ​​perfect development tools and personal developer skills.
It's just my style, it is important for me that the process is flowing, it is important to feel instant returns, and to start the application after each tiny change, to feel. This is neither bad nor good, it's just my personal style. By the way, he is not so empirical in fact, there are also studies by psychologists. For example, it has been proven that in order for the mind to succeed, to fix the memory, a person needs to get the result instantly, this is the theory of learning and fruitful work. We again touch on the topic of psychology, I am sure that without a deep study of the processes of memory, decision making, mood, and other detailed research of the programmer at work, our improvement of development tools will be extremely ineffective.
This is partly due to the marketing awareness of Western manufacturers, if there is a market, people use a development tool, then why change it fundamentally? This is the basics of marketing. If a person is accustomed to smoking a shag, then do not try to sell him a cigar, do not deprive yourself of the market, it is better to grind cigars into a shag and sell an improved shag. Why improve the compiler in unexpected directions, if there is a huge user base already trained to rely on what is? You just need to file, and tint. Now there is even a marketing strategy aimed at weekly, for example, updates, and the fact that there again only “repainted the fence” or moved the button, these are trifles, the main thing is that “the project is a giff”. So it turns out that usually some new bold solutions on the market appear with a new product,and not with the new version of the existing one. Such radical changes that brought Ruby and Python could not have been expected from a new version of any existing system.
When I wrote YaUI, where I had to use four programming languages ​​and three different platforms at once, and accordingly, no single debugger could cover all this, I was completely used to and loved debugging without a debugger, through codification. Moreover, I translated all development into the usual notepad ++, with compilation on the command line, through scripts, as a result I managed to achieve the same approach to development on all three platforms and four languages. (Java, ObjC, C ++, JavaScript, Android, Windows, iOS). When I realized that you can code without any monstrous IDEs at all, to remove the dependence on these huge brake worlds, you can not compile and use Node.js at all, and not wait for another drawback to be corrected again in the debugger, I realized that I want to make a minimalist tool for this programming style. So,actually, the idea of ​​Deodar was born. I also wanted to give up on Windows and reduce the dependence on another corporation, that is, a source of unpredictable changes. Here I actually come back to the main topic of the article - the project and the product, because it immediately became clear to me that it is only possible to write something by conducting very long research. That is, I want to show by example how I tried to deliberately conduct long-term studies before, in fact, working on a product.That is, I want to show by example how I tried to deliberately conduct long-term studies before, in fact, working on a product.That is, I want to show by example how I tried to deliberately conduct long-term studies before, in fact, working on a product.
The first task I faced and which I solved for about six months, realizing that I can not cope, was working with windows, a screen and a keyboard. I already had development experience under the XWindow System, and when I decided to figure it out, I was once again convinced that all the documentation for Unixes was built on the principle of mans, that is, if you know what to type, you type and it is written to you do it, but if you don’t know what the function is called that does what you need, you will go a very long way. In the end, I learned to work with the screen and windows through the socket on the XWindow Protocol simply by reading the old specification. But I failed the main thing, to draw Anti Aliased Text. The fact that in Windows or on a Mac is done by calling one function, there is a whole story in the world of X.I had to create an OpenGL context and with handles to render letters there using FreeType or HarfBuzz. The problem was that they could not reach normal speed, FPS. I researched dozens of alternatives, all sorts of toolkits and wrappers, ranging from the generally accepted GDK, Qt, FLTK, SDL and to very complex hybrid solutions, including GLUT, Pango in various combinations. And each such attempt took days and even weeks. Dozens of folders with prototypes are still. In the end, I figured it all out and decided to use Xlib + FreeType + OpenGL textures.including GLUT, Pango in various combinations. And each such attempt took days and even weeks. Dozens of folders with prototypes are still. In the end, I figured it all out and decided to use Xlib + FreeType + OpenGL textures.including GLUT, Pango in various combinations. And each such attempt took days and even weeks. Dozens of folders with prototypes are still. In the end, I figured it all out and decided to use Xlib + FreeType + OpenGL textures.
Next came the clipboard problem. It turned out that on pure Xlib this is a whole story and it took me weeks again to solve this problem. It seems to me that people understand how the clipboard in Linux works at the X level in the world of one. Again incredibly elusive documentation. In the end, I created a demo hello world on this topic and laid it out on the githab; now anyone can see how it is done on C. in twenty lines. It’s amazing that people couldn’t say anything distinctly about the Stackerflo. Then there was the problem of unicode text entry and again, days and weeks of research, dozens of other people's examples, which all did not work as usual and finally managed to deal with it. By the way, the variant of work of Deodar from under the console was also considered. But understand, the terminal is an ancient technology,it is still compatible with sixties teletypes. This is a rudiment, and the main problem of the terminal is the inability to detect keystrokes, that is, elementary onKeyDown, onKeyUp is basically impossible on the terminal, which is essentially a streaming character device not directly connected with hardware. Recently, the author BASH was asked how he sees the future of his brainchild. Do you know what he said? I want to say that BASH disappears as soon as possible and everybody should forget about it and finally create something more modern, corresponding to contemporary tasks.how he sees the future of his creation. Do you know what he said? I want to say that BASH disappears as soon as possible and everybody should forget about it and finally create something more modern, corresponding to contemporary tasks.how he sees the future of his creation. Do you know what he said? I want to say that BASH disappears as soon as possible and everybody should forget about it and finally create something more modern, corresponding to contemporary tasks.
, V8 Node.js? ? . , npm . . Turbo Vision, . , JavaScript , , . : A->B->C A.draw() .draw(), .draw() .draw() , B.draw(). Turbo Vision . A.draw.apply(this), this.inherited.draw(). B.draw() , . , JavaScript, , , , . , JavaScript , dnaof .
Actually, Deodar as a product consisted of a hybrid of a classic two-pane file manager with its reactive blind navigation and a very convenient text editor, not inferior to Notepad ++, SublimeText, and other parameters that interest me. Another important point was the introduction of the terminal inside Deodar. That is, by pressing Escape, the user sees the running BASH and all three components, the editor, the file panels and the console are very tightly connected to the congruent system. And the main killer feature, of course, is JavaScript itself, that is, this environment doesn’t need any APIs for developing plug-ins, you have all the source code at hand, and it’s minimalist, it’s not millions of lines, but a few thousand. By the time of last year’s release, from the date of which exactly a year had passed, there were still two unsolved fundamental problems.It was not possible to achieve the desired rendering speed, that is, it was acceptable, but I wanted even more FPS and could not figure out how to get into the Ubuntu repository, though. Therefore, Deodar is still a project. I recently had a chance to re-write the drawing and get to the desired performance. Now this whole saga continues, because I immediately realized that this is a PROJECT and it will last for years and it should be understood that every step involves research with an open date.that this is a PROJECT and it will last for years and it should be understood that each step involves research with an open date.that this is a PROJECT and it will last for years and it should be understood that each step involves research with an open date.
Actually, the product level is still ahead, for me this is a question of the interface, because as Linus says ours, Torvalds - if your program has a feature, but it is not in the interface, then there is NO FICHI. And in Deodar, there are still no menus, a calculator, a palette editor, work with archives and so on. By the way, working with archives is a necessary thing, it’s just the work of the programmer, it’s secondary, my goal was to make not so much the file manager as such, but the work environment of the programmer with the file manager inside. But for the product and it is necessary.
Well, I hope you were interested in this small excursion into the philosophy of programming and a small PR of my project. I have been repeatedly approached in the comments with the claim that there is already an article in the series Programming Philosophy, but there is nothing about programming yet. My goal is to write about programming, interpreting this phenomenon comprehensively, and not only technically. After all, most of the texts on programming are extremely one-sided, from the series “I’ve put a new version of X, let me tell you what rake I had to step on.” Again, I do not rate what is good and what is bad, such texts are good in themselves, they solve their problems. But we need to undermine the more complex issues, develop the language, introduce new concepts, expand existing ones.Today I tried to take the seemingly notions of Project and Product and speculate, publicly, how they differ. After all, what is happening in the programmer’s head needs to be able to express, and we still only tap the screen and moan, “well, what do you not understand” or “look in the code”, “well, what can people do if to program. " Maybe they can, you just do not know how to explain what you think about this section of the code? This is a matter of language development. Take for example closures, because there is no such keyword in the programming languages, but there is a closure! That is, the concept is introduced exclusively humanitarian, in the head of programmers, they say, look, here’s how you can write and make a “closure”, you can do this and that with it. Then the concept develops, child concepts are added, the set of associations is expanded. In general, we will workmove in the chosen direction. I really hope that if you move purposefully, then sooner or later you will be able to find the right tone of the reasoning about the subject and greatly enrich our understanding of the profession. And many thanks to everyone who takes part in the comments, even those who are minus me, criticize, and especially those who read and wait for sequels!
Programming philosophy
6: Product and Project
5: Reactos and Hummingbird
4: Chapito technology
3: Chichikov and programmer
2: Myth and language
1: Tri-directional programming
Of course, any project is similar to a plan, there is a sequence of actions there, they can even set some deadlines, but as long as there are unexplored white spots in it, this is a plan with holes, that is, a project.
If you were able to develop a product and explore many technologies in the process, then you get a competitive advantage in the market, so the desire to get involved not in product development, but in a project, is like a disease. The programmer thinks: now, here we are exploring this little thing, invent it, and tear it up. And any research has an indefinite period, and if you yourself, or the programmer says, “you still have to figure out how to do it,” immediately note to yourself: this is about research, that is, not about the product, but about the project. The project has an indefinite time frame, due to the research.
')
When the project is peculiar thinking in the spirit: for a long time we explore the super-feature, mega-technology, and then quickly we collect everything and get the product. The striking difference of the product is that in it the “collect everything” stage starts very early, almost immediately, and most of the graphics are assigned to fine-tune all parts. In the project, on the contrary, this stage begins much closer to the end of the schedule. The project schedule is like clogging ten thousand nails, you can immediately estimate how long it will take, and methodically hammer in. In general, the project has the feeling that "we have already done this, you just need to do it again for this particular product." Moreover, the process can be repeated on the same schedule by creating another similar product. Many successful projects succeeded precisely because a person who has already seen the entire schedule from beginning to end, leaves the team and clones the entire organizational project, the work schedule and simply does the same thing only better, consciously avoiding research and experimentation.
If, say, your input field sometimes suddenly loses focus or moves it incorrectly, then from the point of view of a project, this is an inessential detail, and from the point of view of a product, this is a flaw that can seriously damage its reputation. Or there are two buttons of the same type on the form, but one tenth of the size, and the other eleventh. A trifle is eliminated in 10 minutes, you need to find the file you need, the right place, fix it, check it. No super technology, but at least 10 minutes off. And in the product of such trifles there are usually hundreds and thousands, they are small, there are many of them and this allows you to use the main weapon of the product developer - to make a schedule. Today we correct thirty jambs, tomorrow, and so for a hundred days, with all the known coefficients, we get two thousand ryushechek and details. And in the project it will not be time.
If I wanted to say that the project is bad and the product is good, I would say that. I just want to clearly separate these two concepts, it seems to me, it can save a lot of effort. The project itself is a wonderful phenomenon, research is also a real work. Moreover, the project can be conducted recognizing the whole probabilistic and gaming essence of research, wisely distributing and designing even these indefinite periods. In the end, this is just an indefinite projection, but you just need to clearly understand what exactly you are doing. I personally, from experience, used to conduct all the research before the start of product planning, all the technologies, principles and rules used should be investigated, there should be no questions left, there should be a fundamental decision at the end of the research that everyone, we take these decisions, aware of them advantages and disadvantages and go to the planning stage, that is, product development.
Research is the search for suitable technologies and tools, the creation of unique algorithms and personnel training, and initial performance studies, and the compilation of a list of necessary features for the customer or the market, and even the search for a convenient operating mode. That is, everything that is not known in advance and cannot be formally determined. That is, by the time the product is developed, that is, a plan and schedule of work, you no longer have white spots, questions, and the plan is made up of solid, tangible, weighty bricks. As soon as you have a feeling that everything is clear, and you just need to work, hammer nails or clone a chip from a chip from a competitor's product, then you can say the product took place. Of course, then it may turn out that it will not be successful, and mistakes were made in planning or in defining the terms of reference, or mistakes in actual practical work, but this will already be taken into account in the next project / product.
The ability to accumulate experience and transfer the algorithm of work from product to product, from project to project, generally distinguishes the person who has embarked on the right path in development. For example, I have long known that changing a font in a button is, on average, at least ten minutes, before it seemed to me that it was a matter of seconds. Typing the building blocks of graphics, the ability to sort all the tasks and subtasks according to the complexity of the execution, the time of execution, the required qualification is the main planning skill. Some types of tasks are not very complicated, but they have a peculiarity to tire memory a lot and then it takes an increased time to move on to the next tasks. If you are a manager of the whole programmers office or a loner, in any case you need to constantly look at yourself from the outside, and not only rejoice that the next small step is completed, and think immediately about the next, but you must constantly think about it and even say out loud and write down what task was solved, how long it was decided, how it is typed, what experience can be drawn for further planning.
In this sense, the development manager, who is not a programmer himself and cannot properly assess the rings in the development chain, is a disaster. Such a person immediately manifests and must be driven, it is usually enough that he was surprised several times, why did it take so long? A programmer’s manager is allowed to be surprised only in case of unexpectedly fast passage of a certain segment of a distance. And that is not desirable. It’s clear that if a programmer has everything in his head and he doesn’t need a deep switch to the moment of a new line in the plan, then he can do something almost instantly. That is, you fixed the button in three different places, it took ten minutes, but it happened so quickly only because it was the same type of work, and it so happened that all three buttons were fixed in a row. But if you had to fix the button in one place of the code, because fix the bug in the protocol, then another button, then find the division by zero, and again fix another button, then each button fix could take ten minutes. Moreover, it is possible to take into account not only the development process at one step and the switching time, but also bouts of enthusiasm and loss of strength. The most important talent of a manager, be it a self-manager, or a team manager, is the ability to track when work is inhibited because of a sudden study. Usually a wrinkled forehead or a desire to distract from work is a good sign. It means that the developer doesn’t have something in his head, he doesn’t keep in memory, the uniform motion on the points of the plan is shut up. Here you need to show experience and deep understanding, and “settle” the question - either realize that research is inevitable and add a bold row of indeterminate size to the plan plate, and throw all your efforts on the solution, or circumvent the issue by applying a proven alternative solution. If you are making a product, your task is not to “work better”, but to adjust the process to full predictability.
An interesting everyday comparison, although it should be understood that any comparison is only a comparison and can only illustrate a certain principle, it is cooking dinner. When you need to feed yourself, you can cook food very quickly, and you can afford experiments and research in the process. A little more salt, a smaller, new seasoning to try, but if you need to make a festive dinner and feed dear guests, then the situation is radically different. It seems that the costs should be linearly scalable, 5 guests, so the estimated costs for a gala dinner are five times more than your own lunchtime snack, but in actual fact, the costs will differ by an order of magnitude, and the choice of ingredients, and the thoroughness of performance and serving spent time. This is a project and a product. No one will experiment with festive soup, and if it does, it will regret it. Guests will come exactly at five, that is, there is a deadline. The cost of serving and detailing, cutting the cheese into thin slices, spreading the jam in an even layer, these are things that are made ten times easier in a regular household meal than in a festive mode. This is the product, it is a festive dinner. The complexity of the performance of a festive lunch or dinner is compensated by the fact that everything is determined in it, each operation is debugged for years, at best the hostess decides on one unusual dish, and it takes a lot of time and energy and is accompanied by oops according to the principle: “I have never done before , I decided to try, do not judge strictly, "looking for a competitive advantage, so to speak. In addition, everything is perfectly scaled, because most of the operations are typical and they can be done by everyone in the kitchen.
It is now a year since I presented my project Deodar to the community. This was originally a typical "Project", the number of studies that needed to be carried out in order to take on the actual performance of the product, was immediately determined by me as huge. Let's start with the fact that the lack of high-quality jerks in the development tools that are interesting to me has depressed me for years, even decades. How many times, installing a new version of your favorite development tool, editor, IDE, debugger, did you wonder how many developers did, and how again nothing changed in essence? In projects with open source, in general, the main tendency to avoid fundamental changes, total refactoring, and instead of attaching to the machine, more and more pens, ozonizers and repainting the doors every time. While a healthy process of iteration of versions should provide for fundamental changes in all areas from time to time. One of these fundamental changes is the solution to the problem, which in everyday language can be called “there’s not enough little things”. That is, there is a great tool, everything is becoming obsolete, but one little thing that is familiar to you, just a little thing is missing, and because of this, a product developed with a resource does not suit hundreds of thousands of man-hours, because of its functionality, the development of which takes one person-day.
It is very important for the developer, as a person who solves non-trivial tasks, to rely on a tool, and dependence on this tool determines strategic decision making in planning.
How many times have you heard the phrase "we decided to abandon ..."? My youth came to the heyday of Borland products in Russia, I learned to program professionally and used Turbo Pascal and later Delphi. In this connection, I have developed some skills of work, a habit to rely on such tools of the environment as F4 (Run to cursor), Control + Enter (Open file at cursor), instant compilation. It became critical for me that I could compile with one button, put a stop under the cursor and start the program, then also terminate it with one button and continue editing the code. When I tried to work in my usual mode on Visual Studio, except for orders of much slower compilation, the need to start the debugger with one button, run the program with another, pre-delete the previous break point and install a new one, was a whole process that I could not distracted. For several days, I wrote a macro that somehow solved the problem. Of course, these are my personal preferences, but the problem is that each programmer has his own personal passions, without them there is no programmer, even the painter has his own personal passions for methods and tools. One of my friends, a machine tool technician, could not work if he did not have a gasoline bath at hand, in which he could instantly wash his hands instantly at any time to the pre-lunch cleanliness. He suffered terribly when he had to work in another workshop where there was no such bath. A trifle, but from such trifles and a working process.
I have always postulated such a thing as the perfection of development tools. You know how the production of the means of production among the Marxists, which distinguishes a developed economy from simply mechanized. My belief that a truly advanced development tool can speed up development not by percentages, but by orders of magnitude, and not only accelerate, but also enable the developer to take on tasks of a different degree of complexity. About five years ago I made an ambitious attempt to create a C ++ IDE that meets my requirements. She was called DaoIDE. For this, I had to solve a few fundamental problems. First, make your own text editor or learn how to effectively use Scintilla or another open source. Text editors I do as much as I can remember. In general, creating a text editor is an example of a complex programming task. Everything can be seen on the screen, and the most complex structure, it is an ideal task for advanced students. My love for text editors flourished when I had to work with the Aldus Page Maker application, I openly admired what this program can do, and it was written in the late 80s and early 90s. I happened to write dozens of text editors from scratch, that is, from scratch. And that's not counting the hundreds of fast prototypes. From the simplest laptops for dos, to systems with complex markup and special requirements. So there was no problem with the editor. Then I had to deal with the debugger, I made many prototypes of the environment interaction with the debugger, based on dbghelp.dll, in pure assembler, through GDB, GDB-MI, WinDbg and various ready-made skirts over them. I was terrified in the process - how difficult it is, how bad everything is documented, it is obvious that no debugger was originally made for embedding into third-party applications. Then I had to deal with the C ++ compiler, my main requirement for it was compilation speed. I had to thoroughly understand the history of the development of existing compilers and make sure that the fastest compiler (precisely in terms of compilation speed, and not in terms of the speed of the compiled program) is Digital Mars C ++ (DMC), formerly Symantec C ++. My reasoning is simple, in the process of developing an application, it needs to be run many thousand times, and an optimized executable output is needed only at the moment of release once. DMC often worked several dozen times faster than rivals, giving a performance close to the familiar Delphi jet compiler. But he did not give the opportunity to debug these executables, due to the object file format licensed a decade ago. MSVC, especially earlier versions, was much faster than GNU C ++. But there were no chances for cross-platform and terrible vague documentation, each, such as determining the type of variable, had to be investigated for days. This project took me at least a year, almost all the time was spent on research.
The C ++ Dao environment project died out precisely because I was convinced of the inapplicability of all existing IDE-building blocks available in the world, primarily compilers, debuggers. Solving this problem, I spent a lot of time studying not only the source code but also the community and the history of the development of these tools. For example, I realized that GCC will never compile quickly, moreover, with each version it will compile more and more slowly, such is the demand of the market and such is the focus of development. Not to mention the fact that the steering committee itself works in a very specific way, and it will never be possible to fundamentally revise the compiler device. The logic is simple, everything is done according to science: lexer, AST, backend, codegen, etc., there is nothing to invent here. When I saw the first video with the stories of the authors of LLVM / Clang I was jumping for joy, it was obvious how much Apple and Google think more creatively and decisively. The GDB device is also a nightmare both historically and technically. Here I must clarify that if I state the horror of these projects, but this does not mean that I do not like them, or I consider them idiots, those who made them.Not at all, these are world projects, including MSVC, C ++ compilers are so complicated that there are only a few of them in the world, and all those who work on them are super-people! You can literally list on your fingers the projects of this level. It just became clear that people are working in a different direction than the one that is close to me personally. And we come back to the idea of ​​perfect development tools and personal developer skills.
It's just my style, it is important for me that the process is flowing, it is important to feel instant returns, and to start the application after each tiny change, to feel. This is neither bad nor good, it's just my personal style. By the way, he is not so empirical in fact, there are also studies by psychologists. For example, it has been proven that in order for the mind to succeed, to fix the memory, a person needs to get the result instantly, this is the theory of learning and fruitful work. We again touch on the topic of psychology, I am sure that without a deep study of the processes of memory, decision making, mood, and other detailed research of the programmer at work, our improvement of development tools will be extremely ineffective.
This is partly due to the marketing awareness of Western manufacturers, if there is a market, people use a development tool, then why change it fundamentally? This is the basics of marketing. If a person is accustomed to smoking a shag, then do not try to sell him a cigar, do not deprive yourself of the market, it is better to grind cigars into a shag and sell an improved shag. Why improve the compiler in unexpected directions, if there is a huge user base already trained to rely on what is? You just need to file, and tint. Now there is even a marketing strategy aimed at weekly, for example, updates, and the fact that there again only “repainted the fence” or moved the button, these are trifles, the main thing is that “the project is a giff”. So it turns out that usually some new bold solutions on the market appear with a new product,and not with the new version of the existing one. Such radical changes that brought Ruby and Python could not have been expected from a new version of any existing system.
When I wrote YaUI, where I had to use four programming languages ​​and three different platforms at once, and accordingly, no single debugger could cover all this, I was completely used to and loved debugging without a debugger, through codification. Moreover, I translated all development into the usual notepad ++, with compilation on the command line, through scripts, as a result I managed to achieve the same approach to development on all three platforms and four languages. (Java, ObjC, C ++, JavaScript, Android, Windows, iOS). When I realized that you can code without any monstrous IDEs at all, to remove the dependence on these huge brake worlds, you can not compile and use Node.js at all, and not wait for another drawback to be corrected again in the debugger, I realized that I want to make a minimalist tool for this programming style. So,actually, the idea of ​​Deodar was born. I also wanted to give up on Windows and reduce the dependence on another corporation, that is, a source of unpredictable changes. Here I actually come back to the main topic of the article - the project and the product, because it immediately became clear to me that it is only possible to write something by conducting very long research. That is, I want to show by example how I tried to deliberately conduct long-term studies before, in fact, working on a product.That is, I want to show by example how I tried to deliberately conduct long-term studies before, in fact, working on a product.That is, I want to show by example how I tried to deliberately conduct long-term studies before, in fact, working on a product.
The first task I faced and which I solved for about six months, realizing that I can not cope, was working with windows, a screen and a keyboard. I already had development experience under the XWindow System, and when I decided to figure it out, I was once again convinced that all the documentation for Unixes was built on the principle of mans, that is, if you know what to type, you type and it is written to you do it, but if you don’t know what the function is called that does what you need, you will go a very long way. In the end, I learned to work with the screen and windows through the socket on the XWindow Protocol simply by reading the old specification. But I failed the main thing, to draw Anti Aliased Text. The fact that in Windows or on a Mac is done by calling one function, there is a whole story in the world of X.I had to create an OpenGL context and with handles to render letters there using FreeType or HarfBuzz. The problem was that they could not reach normal speed, FPS. I researched dozens of alternatives, all sorts of toolkits and wrappers, ranging from the generally accepted GDK, Qt, FLTK, SDL and to very complex hybrid solutions, including GLUT, Pango in various combinations. And each such attempt took days and even weeks. Dozens of folders with prototypes are still. In the end, I figured it all out and decided to use Xlib + FreeType + OpenGL textures.including GLUT, Pango in various combinations. And each such attempt took days and even weeks. Dozens of folders with prototypes are still. In the end, I figured it all out and decided to use Xlib + FreeType + OpenGL textures.including GLUT, Pango in various combinations. And each such attempt took days and even weeks. Dozens of folders with prototypes are still. In the end, I figured it all out and decided to use Xlib + FreeType + OpenGL textures.
Next came the clipboard problem. It turned out that on pure Xlib this is a whole story and it took me weeks again to solve this problem. It seems to me that people understand how the clipboard in Linux works at the X level in the world of one. Again incredibly elusive documentation. In the end, I created a demo hello world on this topic and laid it out on the githab; now anyone can see how it is done on C. in twenty lines. It’s amazing that people couldn’t say anything distinctly about the Stackerflo. Then there was the problem of unicode text entry and again, days and weeks of research, dozens of other people's examples, which all did not work as usual and finally managed to deal with it. By the way, the variant of work of Deodar from under the console was also considered. But understand, the terminal is an ancient technology,it is still compatible with sixties teletypes. This is a rudiment, and the main problem of the terminal is the inability to detect keystrokes, that is, elementary onKeyDown, onKeyUp is basically impossible on the terminal, which is essentially a streaming character device not directly connected with hardware. Recently, the author BASH was asked how he sees the future of his brainchild. Do you know what he said? I want to say that BASH disappears as soon as possible and everybody should forget about it and finally create something more modern, corresponding to contemporary tasks.how he sees the future of his creation. Do you know what he said? I want to say that BASH disappears as soon as possible and everybody should forget about it and finally create something more modern, corresponding to contemporary tasks.how he sees the future of his creation. Do you know what he said? I want to say that BASH disappears as soon as possible and everybody should forget about it and finally create something more modern, corresponding to contemporary tasks.
, V8 Node.js? ? . , npm . . Turbo Vision, . , JavaScript , , . : A->B->C A.draw() .draw(), .draw() .draw() , B.draw(). Turbo Vision . A.draw.apply(this), this.inherited.draw(). B.draw() , . , JavaScript, , , , . , JavaScript , dnaof .
Actually, Deodar as a product consisted of a hybrid of a classic two-pane file manager with its reactive blind navigation and a very convenient text editor, not inferior to Notepad ++, SublimeText, and other parameters that interest me. Another important point was the introduction of the terminal inside Deodar. That is, by pressing Escape, the user sees the running BASH and all three components, the editor, the file panels and the console are very tightly connected to the congruent system. And the main killer feature, of course, is JavaScript itself, that is, this environment doesn’t need any APIs for developing plug-ins, you have all the source code at hand, and it’s minimalist, it’s not millions of lines, but a few thousand. By the time of last year’s release, from the date of which exactly a year had passed, there were still two unsolved fundamental problems.It was not possible to achieve the desired rendering speed, that is, it was acceptable, but I wanted even more FPS and could not figure out how to get into the Ubuntu repository, though. Therefore, Deodar is still a project. I recently had a chance to re-write the drawing and get to the desired performance. Now this whole saga continues, because I immediately realized that this is a PROJECT and it will last for years and it should be understood that every step involves research with an open date.that this is a PROJECT and it will last for years and it should be understood that each step involves research with an open date.that this is a PROJECT and it will last for years and it should be understood that each step involves research with an open date.
Actually, the product level is still ahead, for me this is a question of the interface, because as Linus says ours, Torvalds - if your program has a feature, but it is not in the interface, then there is NO FICHI. And in Deodar, there are still no menus, a calculator, a palette editor, work with archives and so on. By the way, working with archives is a necessary thing, it’s just the work of the programmer, it’s secondary, my goal was to make not so much the file manager as such, but the work environment of the programmer with the file manager inside. But for the product and it is necessary.
Well, I hope you were interested in this small excursion into the philosophy of programming and a small PR of my project. I have been repeatedly approached in the comments with the claim that there is already an article in the series Programming Philosophy, but there is nothing about programming yet. My goal is to write about programming, interpreting this phenomenon comprehensively, and not only technically. After all, most of the texts on programming are extremely one-sided, from the series “I’ve put a new version of X, let me tell you what rake I had to step on.” Again, I do not rate what is good and what is bad, such texts are good in themselves, they solve their problems. But we need to undermine the more complex issues, develop the language, introduce new concepts, expand existing ones.Today I tried to take the seemingly notions of Project and Product and speculate, publicly, how they differ. After all, what is happening in the programmer’s head needs to be able to express, and we still only tap the screen and moan, “well, what do you not understand” or “look in the code”, “well, what can people do if to program. " Maybe they can, you just do not know how to explain what you think about this section of the code? This is a matter of language development. Take for example closures, because there is no such keyword in the programming languages, but there is a closure! That is, the concept is introduced exclusively humanitarian, in the head of programmers, they say, look, here’s how you can write and make a “closure”, you can do this and that with it. Then the concept develops, child concepts are added, the set of associations is expanded. In general, we will workmove in the chosen direction. I really hope that if you move purposefully, then sooner or later you will be able to find the right tone of the reasoning about the subject and greatly enrich our understanding of the profession. And many thanks to everyone who takes part in the comments, even those who are minus me, criticize, and especially those who read and wait for sequels!
Programming philosophy
6: Product and Project
5: Reactos and Hummingbird
4: Chapito technology
3: Chichikov and programmer
2: Myth and language
1: Tri-directional programming
Source: https://habr.com/ru/post/254531/
All Articles