How to become a hero (Jacob Sirotkin on ADD-2010)
Jacob Sirotkin , a well-known blogger and experienced developer likes to open the eyes of young programmers on the sometimes impartial side of employers, while explaining the nature of these facts.
Problems that do not like to speak at the interview, but which have to face.
For owners of thick channels who do not like to read - you can offer a video recording of the report:
')
Love to listen to audio in the car - download and listen.
Look through and download the presentation of the report here .
Prepared materials speeches Stas Fomin
Now I will make a short report, but first a few words about myself. Not that I was distinguished by a special intelligence and ingenuity, but for more than ten years I have been developing software, and all the time I was very worried about what comes out of it.
I have been doing jug.ru for ten years, I have a LiveJournal , and I love speaking at conferences.
Now, we will talk about how I see our industry as a whole. There are many programs that have very, very, very many different functions. And then, when the introduction begins, the customer is carried out, as if by a minefield - and what if something is introduced? A similar minefield scheme is valid for many of our outsourcers. Those. at first, as many clients as possible are taken, as many staff are recruited for these clients, a small money drips for this large staff, and when the money runs out, all programmers quit, “undermined”.
You know, even if you are developing for the IPhone, theoretically you can become millionaires. But statistically you are deep in the red. There was a small review article, which was devoted to sales statistics on the AppStore, and it happened so, that there are very successful programs with high incomes, but the majority receives quite ridiculous amounts.
And I do not pretend to tell you in my report how to make successful software. Why I do not claim it? I am deeply convinced that you can not make a successful software if you do not have your own brains. And I will not give you my own brain. It is technically impossible. But what do I hope for? I hope that I will touch on some issues that you will be useful to think about. Maybe you will like it.
I would like to hear the expectations of the audience. What heroes do you have that you would like to consider as potential role models? Are there any versions?
The noise in the hall ... "Linus Torvalds", "Sergey Brin", ...
Well, in fact, I must disappoint you (see slide). And you can learn from me, according to what I myself ran into. My role model is Don Quixote, which stubbornly tries to bring the light of truth to the authorities. Well, for everyone else.
Trying to tell the right things, do the right things, well, somehow move in general, forward. It happens very, very painful and insulting. I do not advise.
Captain Evidence is somewhat easier. Some people think that this is not interesting, but practice shows that there are always willing to argue.
And now we come to the main question - why becomes a hero? Look here - salaries in Russia, they are very small. Programmers usually get twice as many as the national average. If the programmer has some additional qualities, then he gets two more more than the average programmer. And the qualities may be different - Java knowledge, ability to behave well in interviews, good English ... literally for anything.
And look how it can work out - here you come to work, you want to develop a reasonable good eternal. And your boss wants to watch football. Who will win?
The noise and excitement in the hall ...
Sick question ...
Another issue is related to our territorial distribution, remoteness from many of our customers. Just imagine that your company has a branch in Bobruisk. Will you give this affiliate a task for which they will give you a medal?
Think for yourself why you need to give the task to Bobruisk, if you do it yourself and they give you a medal for it. You will not give it away. Except for one case - this task cannot be done.
The noise in the hall → In Bobruisk it will be made for less money!
Bobruisk will receive less money. He will not get a medal. A medal is more than a little money.
Noise in the hall → Medal we get! And he - less money. And those who commissioned Bobruisk will receive big money.
In general, Bobruisk will not receive a medal.
So, excuse me, when you look from San Francisco, it’s all the same there - Bobruisk or St. Petersburg.
In addition to the global such ancient Russian longing, there are still questions that help to find out what is happening at all, and in general, how much destruction you have in a project.
I want to immediately warn you, these questions need to be asked very carefully, because if you ask them very often, you will pass for uncommunicative people, asocial types.
Who will be the first user?
Use-case is simple: you make a prototype for the minister. I will tell you in secret - the minister, as if he are here, here he is sitting, but here (pointing at a table 5 meters away) a computer. And the minister looks like this from three meters. He doesn’t care if there is a working code, or a powerpoint presentation.
Therefore, if your goal is to develop a prototype for the minister, then you need to specifically program and do not need anything at all.
Another question - who is to blame? Imagine that you are doing a system. And released nothing. That year worked, and the release - no. Nothing happened. Solid bugs. Who will be punished?
Very often, analysis shows that they will not punish anyone. Because the person who is supposedly the main person for this project, he is also part-time the owner of the company, and he has ten other more interesting and useful projects. Those. he will not be punished, and you will be fired. That's all. Well, respectively, the blame on you is easy to shift, it's easy.
So the artist will be punished ...
How can you punish? - can be fired - well, it means they will be fired. They can still scold - they can scold, treat it calmly.
You understand that it is very difficult to make a project if only you are interested in its success, but not the person who allocates resources to it.
This question is a good one, because if it turns out that someone is really guilty, then you can get support from that person. If a manager is working with you, who will be removed if the project fails, you can explain to him that “there is a threat” and he will help you.
Those. the question is rather “who is to blame but me”?
This is a somewhat future question - “who will be to blame for the collapse?”
The question is less critical. If you are Blizzard, you probably do not care, and so you are ahead of the market for many years.
But if you make commercial software, and suddenly it turns out that it doesn’t matter when you make it, it means that someone just forgot to calculate how profitable your business is.
When you have a deadline as far as you want, the project can eat as much money as you like. This means that it may turn out to be economically meaningless.
So if there is no deadline, then there is also reason to think.
Now let's talk about how to make a successful project. Let me quote the title from the iPhone developer guide. "Formulate what you do, for whom you do and what exactly."
This makes life much easier. Guide, by the way, I recommend reading in the original, his intelligent people wrote, and they did quite well.
When you have a definition of what you have done, it helps you not to waste time on empty discussions. For example, we did a project for the Ministry of Economic Development of the Russian Federation. And we needed to build a model of economic development of the regions according to 17 parameters. The parameters are completely from the baldies, we did not understand anything in them. It was not clear what to do. I proposed a simple model - “we will summarize these parameters with arbitrary coefficients”. This is an absolutely comprehensible model, which we called “Super Summator”.
They gave users the opportunity to change the coefficients, and at the same time look at which region, at which coefficients it goes to the top. We have not argued for a minute about what we are doing. We immediately understood it. We have released a product with perfect quality.
In terms of functionality, there were small notes, but they did not care about anyone.
What else is useful to have a goal? You can overcome resistance!
Another case from my practice - I got a manager who, in principle, did not want to work. He had some other interests in life. He didn’t want to launch any tasks in the development, and that’s all, he practically didn’t run them. But, he once went on vacation, and at the top there was a small castling, I got the top, very high-level manager, who gave me a fairly well-defined task. I did this task, starting from agreeing on specifications, and ending with user support, despite the fact that the manager was still opposed to doing so.
Was against the drive to coordinate the requirements, was against launching the development, was against the implementation. But since there was a clear goal, it still worked out.
Let's talk about the processes. There was such a person, or rather there was such a person, Joel Spolsky , who did for us on stackoverflow.com .
And ten years ago, he wrote an article “The Joel Test: 12 Steps to Better Code,” in which he outlined the criteria for a normal development process point by point.
Let's ask ourselves how the industry responded to Joel Spolsky's article?
The industry put a big bolt on Joel's article.
You come to a new project, there is no bugtracker.
“You don't have a bugtracker, so how is it? “But no, no, we don’t care, we are like that.”
Everything, full autonomy. I will now allow myself to retell Joel's ideas a little creatively, but from the point of view of reality.
Maybe not very well seen, but this is a classic comic about a swing. About how different parties understand the project, how they see it. It is clear that the vision is different for everyone. This vision needs to be synchronized, and in order to cope with it, you will have to expend efforts, time, argue, write letters competently, maybe even gather meetings and knock out business trips, i.e. for this we must somehow fight.
There is a good method how to solve this problem. Need to use a wiki.
A wiki is used by personal example, texts are written into it, ask colleagues to write, ... there are successful examples when the wiki starts successfully and develops successfully.
And as a result, specifications are obtained, practically in that form, in the format about which Joel wrote, he has several articles on how to write specifications.
"Wiki must win" - who should he win? Usually, he must defeat Sharepoint. This is such a large repository of documents; managers sometimes put a Word document in it. Put a vord document, then try to read it. They say "something is incomprehensible at all, some kind of nonsense." The manager says - "OK, guys, I understood, really nothing is clear, there are a lot of questions, I will rewrite."
After a week, commits a new version - well, something was fixed in two places, on trifles. It does not become easier. Sharepoint for collaboration - I did not see him ever working. Vicky basically works. It is hard, but it works.
Stas Fomin : You might be interested in successful cases using wiki systems:
From the audience - and we have the opposite example. Vicky died, and sharapoint won.
It's amazing.
Vicky was inconvenient because it is extremely inconvenient to edit.
You did it, you did a great job, but here’s a real programmer ... And what if linuksoid? He doesn’t even really connect, he can still download the document, but he can no longer edit it.
Wikis are much easier to edit documents!
This slide is due to deep personal experiences. What happens if you fix bugs?
First, you will get the respect of your colleagues [1]! “Yasha fixes bugs ... you think ...” - Yeah, not a very useful activity.
Secondly, you can easily be fired! Here you are, write some component, and wrote it without bugs. Everything, it works, you can be fired. It happens, I know.
The third point - you come to the interview, they ask you, “what have you done? - I corrected the bugs ... - and did what? That's all. Go nafig, we need people who write without bugs.
You may not have fixed your bugs, but the interview is sad.
Why fix it anyway? The fact is that when you fix bugs, you still make your application better. And sometimes the effect is unexpected. You get more than you expect.
For example, you had an assembly process that took half an hour and at the same time required some actions by the hands of the general director. And you took, and wrote an automatic script. And it turned out that you can develop software faster and it became better to live better.
Another point is that sometimes real bugs need to be corrected. The real example is the boss comes to me, and says, “in two weeks the release, and we have some bugs ... release, after all, we should fix it ...”. Well, nothing, rewrote quietly in two weeks.
The third point - look, there is an iPhone. In principle, Nokia, HTC, Microsoft can make a device that will be competitive in any parameters. The price can be underestimated, the display can be set, not worse, at least a large processor can be installed, the accelerometer is absolutely not a problem. What can't they do? They can not make a platform that will not fail. Those. make no bugs, it's very hard. It really becomes a competitive advantage.
When two search engines fight, on the simplest questions they are exactly the same, but it turns out that on some queries one system works better than the other. And gradually, all users move to the search engine, which has fewer bugs. Those. in a competitive market it is very important to fix bugs.
And to write an application with bugs, any student can, this is not the focus.
This next slide is about the fact that you have a software development process. Those. you need to understand how to release releases.
Suppose this situation - you release releases once a year. What does this mean? This means that the people who released the last release left the company.
And you start releasing a release. You do not understand how to do it. You do this for the first time. Naturally, you are doing poorly. Therefore, you release a release not once a year, but once in two.
Stas Fomin : If you do not believe in such long release cycles, see the video story about the three-year product release cycle.
One year you develop something, and then you finish another year to somehow release it.
Sometimes it ends at the top, and you don't release a release at all.
We talked about some kind of common infrastructure, but if you want to work efficiently, you need some theoretical knowledge. I would like to advise you to read a couple of books, the first of which is the refactoring of Martin Fowler, which changed my life - I greatly added to the coding after reading it.
But now I want to stop at its name, or rather the subtitle - “improvement of the existing code”. What, after all, is the revolutionary idea of ​​refactoring? In the fact that now we are not throwing out the code, we are improving it.
Now we are not saying that we will now come and write the second version of the code again, and it will be more correct, we take the existing version and begin to modify it. And gradually modifying, we get a better result.
And now, software is being made that way. No one immediately makes the perfect product, which then no one touches. Everyone now first makes the first version, then looks at the reaction of users and modifies.
Those. Now the software is not so much developed as the existing one improves. And the initial development, it can last a year. A revision can take five, ten years, depending on how successful your product is. The more successful the product, the longer the refinement lasts.
Another book is Effective Java, it is recommended to read the second edition, it is just for Java 5, more relevant, in my opinion it is only in English.
Joshua Bloch often speaks, you can watch his presentations, videos, slides ... you don’t have to buy his book on Amazon.
More relevant - "Patterns", there is a famous book of the "gang of four" about design patterns, but it is poorly translated, and its use in practice often turns out, let's say, not very desirable results, but here it is all more clear, and quite a lot of brains This book is invested.
Another point is that modern software is based on ready-made software components, on something that other people have already developed. This greatly reduces time, improves quality, and, in principle, the trend is clear and correct.
There is one minus. If a person is an idiot, then no library will help him. Here a person wants to use SOAP, and he doesn’t give a damn that because of this he gets a reaction time for a minute more, and eats three times more memory. He just does not care, so he wants and he uses, he does not care. And if this project was not started by you, then you often have to go along with this business ... here I had a case, a system for conducting surveys via the Internet. She had a Tamino XML Database inside. Everything was very good, I worked with XML for a long time, but he had one problem - he could not make more than ten insert-s per second. As you understand, ten inserts per second is very small. We can’t cope with it in any way, we have to use something else, even though ORACLE is possible, it can do it, even a hundred per second. Not a problem at all, here we go on orakl and we will not have any problems. But the bosses said, "Tamino is our child, we yourself here vkoryachili, and we just will not give him up so much." And ten inserts per second are mnee, no way ... Well, I was fired, then everything was replaced there, but - partially ...
Xslt
A positive example is XSLT. Allows you to separate data from the view. For example, if you are doing a SaaS service, i.e. You have one large server and many clients running their applications on your server. You want to customize them for each specific client. XSLT gives you this opportunity.
We had an example, we wrote SaaS-service, then it was called not SaaS-and Application Service Provider. And the client part was made through XSLT, and the admin part was not. And the client periodically asked us - “Can the admin part of the XSLT be made as a client part?”. We said - "Well, we must rewrite the XSLT." “To rewrite is something expensive.” And then, after a while, I asked again ...
Yes, customization through XSLT is very convenient and helps a lot, it works exactly when you need to customize for different clients.
Json Suppose you have two servers. JSON is a very good format to share information between. JSON is better than XML. It is more compact, it is more standardized, it does not have an attribute dilemma or a tag. And at the same time, it is still human-readable, and is very easily processed by the program. And you can add arbitrary new data to it. I highly recommend to at least pay attention to him and know what it is.
Asynchronous task processing
Another such large enterprise pattern is asynchronous processing of tasks. When is it applicable?
Suppose you have a server. And on it a large number of tasks. The naive approach is synchronous, when you strive to process every task immediately. In real life, you can have two troubles:
Asynchronous task processing is when you first write a task, and process it later. And then you can try to process it once, then a second time, if there are any errors, you can process them gradually, if there are too many of them, you get almost complete control.
I have applied this solution since Yandex.Money, under the guidance of Phil Delgyado, and in almost all other projects this makes life very easy, there is a very detailed article, I refer you to it:
www.telamon.ru/articles/async.html
Joel has another article about software being developed for ten years. Good Joel on the example of Excel, I have my own examples.
I would like to talk about Sphinxe, here Andrei Aksenov is here in the room, I am here at the opening, he will speak after me, a rare opportunity to look at him. I also have a lot of personal in this word. I just did a search engine for Russian museums ten years ago. I invented the bicycle. I did everything based on SQL made my inverted index. A full-text full-text search did not, it is "not within the budget and is not required at all."
At this time, Lucene began, at this time Sphinx began. Those. I did not notice that there is a niche for custom search engines. I did not notice that there was Lucene, and continued, as if to suffer nonsense at work. And then you could join Lucene, and maybe, if I joined him then, he would have better competed with Sphinx. But not destiny.
Another example was yesterday, OS Phantom. Dmitry Zavalishin just started to do it, but he was thinking about how to do it for exactly more than ten years. And therefore, I want to tell you that if you have any idea, understand that ... JUnit, who wrote overnight, these are trifles ... if you want to make serious software that people will use, be prepared for that you will develop it for a long time. Maybe not ten years, but you can easily leave the year for the first version, be prepared for this.
You can not develop a good software without difficulty.
Now these are more general questions, recommendations. You see, there is such a conflict when you work as a programmer.
Suppose you want to develop good software so that it is popular, that it works very much and without any problems. You need to do this for half a year or a year, well, let some kind of significant time period.
But at the same time, you have a boss, not a customer, he can, and he sets short-term goals for you. And very often, these short-term goals come into conflict, with a final, long-term result.
The customer really wants to see on the clock exactly what we did.Or does he have any momentary Wishlist, that now, be sure to do it this way and quickly. Or he just wants to talk to you and therefore convenes a meaningless rally at which you don’t understand at all what he is talking about.
My advice to you is to try less to engage in nonsense. It demoralizes, and the result is a bad result.
Fresh example from my practice. The customer, more or less suddenly, said that he no longer wants autocommites, with each request, and he wants everything, well, everything is just a transaction. I thought a little bit and said that if he insists on auto commit, then let's break the contract now, for something I don’t like the idea. The customer thought and said: “Yes, Yasha, you sold me auto commit”.
Those.understand: not doing nonsense is a risky position.
As soon as you begin to contradict leadership, the risk of dismissal hangs over you immediately. But sometimes it turns out, if you can explain something, then the management part agrees. They gave an order, and then they saw that you were unhappy - "well, well, we do not insist."
Those.in principle, speaking sometimes helps. Sometimes not.
Here is another such sad moment. If you develop a lot, write, often make releases, then sooner or later you will be mistaken.
If you make a release once a year, you will be mistaken once a year. But specifically. And if you make a release once a week - five releases are normal, ten releases are normal, and on the twentieth - opa, and they were mistaken. Of course, everyone will think about you. “How could you! Such a responsible project! ... ”
In fact, there are no mistakes. And accept the fact that you will be scolded for mistakes, well, of course, within certain limits, accept it.
If you don’t know how to write code without bugs, and every first release falls, then you need to improve the quality, or do some other things, but sometimes everyone has mistakes. Simple people should come to terms with this.
There is a parallel process that your software is trying to sell to someone. And often the situation is like this - "We have already sold it, do not touch anything else." And sold ... yes there the user can lose data, if nothing touches. And sales are very often under pressure.
A very bad case, when salespeople promised something to some large client, for some big money, and you were faced with the fact - that “we have already sold it.” Please do it urgently!
And because of this, literally the whole system is stuck with crutches. I literally saw a situation where a half-system serves some customers, and the other half only serves one customer. Almost complete copy-paste! Those.realistically, caving in under a single client, you simply turn your code into ruins. Reduce the speed of its development by an order of magnitude.
And understand - if you want a hundred new customers, then you should not concentrate on one customer. We just need to look to the future, strive to develop faster, and not try to adapt to one particular client. Take into account his opinion - yes, of course. But do not sacrifice the whole development.
Problems that do not like to speak at the interview, but which have to face.
- How to successfully develop software in spite of difficulties?
- Will the superiors like this?
- What will it be for?
- How to live on?
For owners of thick channels who do not like to read - you can offer a video recording of the report:
')
Love to listen to audio in the car - download and listen.
Look through and download the presentation of the report here .
Prepared materials speeches Stas Fomin
Introduction
Now I will make a short report, but first a few words about myself. Not that I was distinguished by a special intelligence and ingenuity, but for more than ten years I have been developing software, and all the time I was very worried about what comes out of it.
I have been doing jug.ru for ten years, I have a LiveJournal , and I love speaking at conferences.
There are no heroes in the minefield
Now, we will talk about how I see our industry as a whole. There are many programs that have very, very, very many different functions. And then, when the introduction begins, the customer is carried out, as if by a minefield - and what if something is introduced? A similar minefield scheme is valid for many of our outsourcers. Those. at first, as many clients as possible are taken, as many staff are recruited for these clients, a small money drips for this large staff, and when the money runs out, all programmers quit, “undermined”.
There is no point without their brains
You know, even if you are developing for the IPhone, theoretically you can become millionaires. But statistically you are deep in the red. There was a small review article, which was devoted to sales statistics on the AppStore, and it happened so, that there are very successful programs with high incomes, but the majority receives quite ridiculous amounts.
And I do not pretend to tell you in my report how to make successful software. Why I do not claim it? I am deeply convinced that you can not make a successful software if you do not have your own brains. And I will not give you my own brain. It is technically impossible. But what do I hope for? I hope that I will touch on some issues that you will be useful to think about. Maybe you will like it.
How to become a hero
I would like to hear the expectations of the audience. What heroes do you have that you would like to consider as potential role models? Are there any versions?
The noise in the hall ... "Linus Torvalds", "Sergey Brin", ...
Well, in fact, I must disappoint you (see slide). And you can learn from me, according to what I myself ran into. My role model is Don Quixote, which stubbornly tries to bring the light of truth to the authorities. Well, for everyone else.
Trying to tell the right things, do the right things, well, somehow move in general, forward. It happens very, very painful and insulting. I do not advise.
Captain Evidence is somewhat easier. Some people think that this is not interesting, but practice shows that there are always willing to argue.
Dangerous questions
What for?
And now we come to the main question - why becomes a hero? Look here - salaries in Russia, they are very small. Programmers usually get twice as many as the national average. If the programmer has some additional qualities, then he gets two more more than the average programmer. And the qualities may be different - Java knowledge, ability to behave well in interviews, good English ... literally for anything.
And look how it can work out - here you come to work, you want to develop a reasonable good eternal. And your boss wants to watch football. Who will win?
The noise and excitement in the hall ...
Sick question ...
What tasks will you assign to the Bobruisk branch?
Another issue is related to our territorial distribution, remoteness from many of our customers. Just imagine that your company has a branch in Bobruisk. Will you give this affiliate a task for which they will give you a medal?
Think for yourself why you need to give the task to Bobruisk, if you do it yourself and they give you a medal for it. You will not give it away. Except for one case - this task cannot be done.
The noise in the hall → In Bobruisk it will be made for less money!
Bobruisk will receive less money. He will not get a medal. A medal is more than a little money.
Noise in the hall → Medal we get! And he - less money. And those who commissioned Bobruisk will receive big money.
In general, Bobruisk will not receive a medal.
So, excuse me, when you look from San Francisco, it’s all the same there - Bobruisk or St. Petersburg.
Who will be the first user?
In addition to the global such ancient Russian longing, there are still questions that help to find out what is happening at all, and in general, how much destruction you have in a project.
I want to immediately warn you, these questions need to be asked very carefully, because if you ask them very often, you will pass for uncommunicative people, asocial types.
Who will be the first user?
Use-case is simple: you make a prototype for the minister. I will tell you in secret - the minister, as if he are here, here he is sitting, but here (pointing at a table 5 meters away) a computer. And the minister looks like this from three meters. He doesn’t care if there is a working code, or a powerpoint presentation.
Therefore, if your goal is to develop a prototype for the minister, then you need to specifically program and do not need anything at all.
Who is guilty
Another question - who is to blame? Imagine that you are doing a system. And released nothing. That year worked, and the release - no. Nothing happened. Solid bugs. Who will be punished?
Very often, analysis shows that they will not punish anyone. Because the person who is supposedly the main person for this project, he is also part-time the owner of the company, and he has ten other more interesting and useful projects. Those. he will not be punished, and you will be fired. That's all. Well, respectively, the blame on you is easy to shift, it's easy.
So the artist will be punished ...
How can you punish? - can be fired - well, it means they will be fired. They can still scold - they can scold, treat it calmly.
You understand that it is very difficult to make a project if only you are interested in its success, but not the person who allocates resources to it.
This question is a good one, because if it turns out that someone is really guilty, then you can get support from that person. If a manager is working with you, who will be removed if the project fails, you can explain to him that “there is a threat” and he will help you.
Those. the question is rather “who is to blame but me”?
This is a somewhat future question - “who will be to blame for the collapse?”
When is the deadline?
The question is less critical. If you are Blizzard, you probably do not care, and so you are ahead of the market for many years.
But if you make commercial software, and suddenly it turns out that it doesn’t matter when you make it, it means that someone just forgot to calculate how profitable your business is.
When you have a deadline as far as you want, the project can eat as much money as you like. This means that it may turn out to be economically meaningless.
So if there is no deadline, then there is also reason to think.
Create a Product Definition Statement
Now let's talk about how to make a successful project. Let me quote the title from the iPhone developer guide. "Formulate what you do, for whom you do and what exactly."
This makes life much easier. Guide, by the way, I recommend reading in the original, his intelligent people wrote, and they did quite well.
What to do?
When you have a definition of what you have done, it helps you not to waste time on empty discussions. For example, we did a project for the Ministry of Economic Development of the Russian Federation. And we needed to build a model of economic development of the regions according to 17 parameters. The parameters are completely from the baldies, we did not understand anything in them. It was not clear what to do. I proposed a simple model - “we will summarize these parameters with arbitrary coefficients”. This is an absolutely comprehensible model, which we called “Super Summator”.
They gave users the opportunity to change the coefficients, and at the same time look at which region, at which coefficients it goes to the top. We have not argued for a minute about what we are doing. We immediately understood it. We have released a product with perfect quality.
In terms of functionality, there were small notes, but they did not care about anyone.
Resistance is futile
What else is useful to have a goal? You can overcome resistance!
Another case from my practice - I got a manager who, in principle, did not want to work. He had some other interests in life. He didn’t want to launch any tasks in the development, and that’s all, he practically didn’t run them. But, he once went on vacation, and at the top there was a small castling, I got the top, very high-level manager, who gave me a fairly well-defined task. I did this task, starting from agreeing on specifications, and ending with user support, despite the fact that the manager was still opposed to doing so.
Was against the drive to coordinate the requirements, was against launching the development, was against the implementation. But since there was a clear goal, it still worked out.
The Joel Test: 12 Steps to Better Code
Let's talk about the processes. There was such a person, or rather there was such a person, Joel Spolsky , who did for us on stackoverflow.com .
And ten years ago, he wrote an article “The Joel Test: 12 Steps to Better Code,” in which he outlined the criteria for a normal development process point by point.
Let's ask ourselves how the industry responded to Joel Spolsky's article?
The industry put a big bolt on Joel's article.
You come to a new project, there is no bugtracker.
“You don't have a bugtracker, so how is it? “But no, no, we don’t care, we are like that.”
Everything, full autonomy. I will now allow myself to retell Joel's ideas a little creatively, but from the point of view of reality.
Process
Maybe not very well seen, but this is a classic comic about a swing. About how different parties understand the project, how they see it. It is clear that the vision is different for everyone. This vision needs to be synchronized, and in order to cope with it, you will have to expend efforts, time, argue, write letters competently, maybe even gather meetings and knock out business trips, i.e. for this we must somehow fight.
Wiki must win
There is a good method how to solve this problem. Need to use a wiki.
A wiki is used by personal example, texts are written into it, ask colleagues to write, ... there are successful examples when the wiki starts successfully and develops successfully.
And as a result, specifications are obtained, practically in that form, in the format about which Joel wrote, he has several articles on how to write specifications.
"Wiki must win" - who should he win? Usually, he must defeat Sharepoint. This is such a large repository of documents; managers sometimes put a Word document in it. Put a vord document, then try to read it. They say "something is incomprehensible at all, some kind of nonsense." The manager says - "OK, guys, I understood, really nothing is clear, there are a lot of questions, I will rewrite."
After a week, commits a new version - well, something was fixed in two places, on trifles. It does not become easier. Sharepoint for collaboration - I did not see him ever working. Vicky basically works. It is hard, but it works.
Stas Fomin : You might be interested in successful cases using wiki systems:
From the audience - and we have the opposite example. Vicky died, and sharapoint won.
It's amazing.
Vicky was inconvenient because it is extremely inconvenient to edit.
You did it, you did a great job, but here’s a real programmer ... And what if linuksoid? He doesn’t even really connect, he can still download the document, but he can no longer edit it.
Wikis are much easier to edit documents!
Fix bugs
This slide is due to deep personal experiences. What happens if you fix bugs?
First, you will get the respect of your colleagues [1]! “Yasha fixes bugs ... you think ...” - Yeah, not a very useful activity.
Secondly, you can easily be fired! Here you are, write some component, and wrote it without bugs. Everything, it works, you can be fired. It happens, I know.
The third point - you come to the interview, they ask you, “what have you done? - I corrected the bugs ... - and did what? That's all. Go nafig, we need people who write without bugs.
You may not have fixed your bugs, but the interview is sad.
Why fix it anyway? The fact is that when you fix bugs, you still make your application better. And sometimes the effect is unexpected. You get more than you expect.
For example, you had an assembly process that took half an hour and at the same time required some actions by the hands of the general director. And you took, and wrote an automatic script. And it turned out that you can develop software faster and it became better to live better.
Another point is that sometimes real bugs need to be corrected. The real example is the boss comes to me, and says, “in two weeks the release, and we have some bugs ... release, after all, we should fix it ...”. Well, nothing, rewrote quietly in two weeks.
The third point - look, there is an iPhone. In principle, Nokia, HTC, Microsoft can make a device that will be competitive in any parameters. The price can be underestimated, the display can be set, not worse, at least a large processor can be installed, the accelerometer is absolutely not a problem. What can't they do? They can not make a platform that will not fail. Those. make no bugs, it's very hard. It really becomes a competitive advantage.
When two search engines fight, on the simplest questions they are exactly the same, but it turns out that on some queries one system works better than the other. And gradually, all users move to the search engine, which has fewer bugs. Those. in a competitive market it is very important to fix bugs.
And to write an application with bugs, any student can, this is not the focus.
How fast can you fix a typo?
This next slide is about the fact that you have a software development process. Those. you need to understand how to release releases.
Suppose this situation - you release releases once a year. What does this mean? This means that the people who released the last release left the company.
And you start releasing a release. You do not understand how to do it. You do this for the first time. Naturally, you are doing poorly. Therefore, you release a release not once a year, but once in two.
Stas Fomin : If you do not believe in such long release cycles, see the video story about the three-year product release cycle.
One year you develop something, and then you finish another year to somehow release it.
Sometimes it ends at the top, and you don't release a release at all.
Theory
We talked about some kind of common infrastructure, but if you want to work efficiently, you need some theoretical knowledge. I would like to advise you to read a couple of books, the first of which is the refactoring of Martin Fowler, which changed my life - I greatly added to the coding after reading it.
But now I want to stop at its name, or rather the subtitle - “improvement of the existing code”. What, after all, is the revolutionary idea of ​​refactoring? In the fact that now we are not throwing out the code, we are improving it.
Now we are not saying that we will now come and write the second version of the code again, and it will be more correct, we take the existing version and begin to modify it. And gradually modifying, we get a better result.
And now, software is being made that way. No one immediately makes the perfect product, which then no one touches. Everyone now first makes the first version, then looks at the reaction of users and modifies.
Those. Now the software is not so much developed as the existing one improves. And the initial development, it can last a year. A revision can take five, ten years, depending on how successful your product is. The more successful the product, the longer the refinement lasts.
Another book is Effective Java, it is recommended to read the second edition, it is just for Java 5, more relevant, in my opinion it is only in English.
Joshua Bloch often speaks, you can watch his presentations, videos, slides ... you don’t have to buy his book on Amazon.
More relevant - "Patterns", there is a famous book of the "gang of four" about design patterns, but it is poorly translated, and its use in practice often turns out, let's say, not very desirable results, but here it is all more clear, and quite a lot of brains This book is invested.
Bricks
Profanes do not care which libraries to use.
Another point is that modern software is based on ready-made software components, on something that other people have already developed. This greatly reduces time, improves quality, and, in principle, the trend is clear and correct.
There is one minus. If a person is an idiot, then no library will help him. Here a person wants to use SOAP, and he doesn’t give a damn that because of this he gets a reaction time for a minute more, and eats three times more memory. He just does not care, so he wants and he uses, he does not care. And if this project was not started by you, then you often have to go along with this business ... here I had a case, a system for conducting surveys via the Internet. She had a Tamino XML Database inside. Everything was very good, I worked with XML for a long time, but he had one problem - he could not make more than ten insert-s per second. As you understand, ten inserts per second is very small. We can’t cope with it in any way, we have to use something else, even though ORACLE is possible, it can do it, even a hundred per second. Not a problem at all, here we go on orakl and we will not have any problems. But the bosses said, "Tamino is our child, we yourself here vkoryachili, and we just will not give him up so much." And ten inserts per second are mnee, no way ... Well, I was fired, then everything was replaced there, but - partially ...
Xslt
A positive example is XSLT. Allows you to separate data from the view. For example, if you are doing a SaaS service, i.e. You have one large server and many clients running their applications on your server. You want to customize them for each specific client. XSLT gives you this opportunity.
We had an example, we wrote SaaS-service, then it was called not SaaS-and Application Service Provider. And the client part was made through XSLT, and the admin part was not. And the client periodically asked us - “Can the admin part of the XSLT be made as a client part?”. We said - "Well, we must rewrite the XSLT." “To rewrite is something expensive.” And then, after a while, I asked again ...
Yes, customization through XSLT is very convenient and helps a lot, it works exactly when you need to customize for different clients.
Json
Json Suppose you have two servers. JSON is a very good format to share information between. JSON is better than XML. It is more compact, it is more standardized, it does not have an attribute dilemma or a tag. And at the same time, it is still human-readable, and is very easily processed by the program. And you can add arbitrary new data to it. I highly recommend to at least pay attention to him and know what it is.
Asynchronous task processing
Another such large enterprise pattern is asynchronous processing of tasks. When is it applicable?
Suppose you have a server. And on it a large number of tasks. The naive approach is synchronous, when you strive to process every task immediately. In real life, you can have two troubles:
- You will have very, very, very many tasks that you cannot handle simultaneously.
- You started getting tasks with errors. And you do, the roof goes.
Asynchronous task processing is when you first write a task, and process it later. And then you can try to process it once, then a second time, if there are any errors, you can process them gradually, if there are too many of them, you get almost complete control.
I have applied this solution since Yandex.Money, under the guidance of Phil Delgyado, and in almost all other projects this makes life very easy, there is a very detailed article, I refer you to it:
www.telamon.ru/articles/async.html
Do not be nonsense
Joel has another article about software being developed for ten years. Good Joel on the example of Excel, I have my own examples.
I would like to talk about Sphinxe, here Andrei Aksenov is here in the room, I am here at the opening, he will speak after me, a rare opportunity to look at him. I also have a lot of personal in this word. I just did a search engine for Russian museums ten years ago. I invented the bicycle. I did everything based on SQL made my inverted index. A full-text full-text search did not, it is "not within the budget and is not required at all."
At this time, Lucene began, at this time Sphinx began. Those. I did not notice that there is a niche for custom search engines. I did not notice that there was Lucene, and continued, as if to suffer nonsense at work. And then you could join Lucene, and maybe, if I joined him then, he would have better competed with Sphinx. But not destiny.
Another example was yesterday, OS Phantom. Dmitry Zavalishin just started to do it, but he was thinking about how to do it for exactly more than ten years. And therefore, I want to tell you that if you have any idea, understand that ... JUnit, who wrote overnight, these are trifles ... if you want to make serious software that people will use, be prepared for that you will develop it for a long time. Maybe not ten years, but you can easily leave the year for the first version, be prepared for this.
You can not develop a good software without difficulty.
Do not be nonsense
Now these are more general questions, recommendations. You see, there is such a conflict when you work as a programmer.
Suppose you want to develop good software so that it is popular, that it works very much and without any problems. You need to do this for half a year or a year, well, let some kind of significant time period.
But at the same time, you have a boss, not a customer, he can, and he sets short-term goals for you. And very often, these short-term goals come into conflict, with a final, long-term result.
The customer really wants to see on the clock exactly what we did.Or does he have any momentary Wishlist, that now, be sure to do it this way and quickly. Or he just wants to talk to you and therefore convenes a meaningless rally at which you don’t understand at all what he is talking about.
My advice to you is to try less to engage in nonsense. It demoralizes, and the result is a bad result.
Fresh example from my practice. The customer, more or less suddenly, said that he no longer wants autocommites, with each request, and he wants everything, well, everything is just a transaction. I thought a little bit and said that if he insists on auto commit, then let's break the contract now, for something I don’t like the idea. The customer thought and said: “Yes, Yasha, you sold me auto commit”.
Those.understand: not doing nonsense is a risky position.
As soon as you begin to contradict leadership, the risk of dismissal hangs over you immediately. But sometimes it turns out, if you can explain something, then the management part agrees. They gave an order, and then they saw that you were unhappy - "well, well, we do not insist."
Those.in principle, speaking sometimes helps. Sometimes not.
Errors are more important than sales
Here is another such sad moment. If you develop a lot, write, often make releases, then sooner or later you will be mistaken.
If you make a release once a year, you will be mistaken once a year. But specifically. And if you make a release once a week - five releases are normal, ten releases are normal, and on the twentieth - opa, and they were mistaken. Of course, everyone will think about you. “How could you! Such a responsible project! ... ”
In fact, there are no mistakes. And accept the fact that you will be scolded for mistakes, well, of course, within certain limits, accept it.
If you don’t know how to write code without bugs, and every first release falls, then you need to improve the quality, or do some other things, but sometimes everyone has mistakes. Simple people should come to terms with this.
There is a parallel process that your software is trying to sell to someone. And often the situation is like this - "We have already sold it, do not touch anything else." And sold ... yes there the user can lose data, if nothing touches. And sales are very often under pressure.
A very bad case, when salespeople promised something to some large client, for some big money, and you were faced with the fact - that “we have already sold it.” Please do it urgently!
And because of this, literally the whole system is stuck with crutches. I literally saw a situation where a half-system serves some customers, and the other half only serves one customer. Almost complete copy-paste! Those.realistically, caving in under a single client, you simply turn your code into ruins. Reduce the speed of its development by an order of magnitude.
And understand - if you want a hundred new customers, then you should not concentrate on one customer. We just need to look to the future, strive to develop faster, and not try to adapt to one particular client. Take into account his opinion - yes, of course. But do not sacrifice the whole development.
Source: https://habr.com/ru/post/118054/
All Articles