IMHO about the speech of Gref at the Gaidar Forum and the danger of revolutions

The speech of German Oskarovich Gref did not go unnoticed, not only among the political and economic establishment, but also received a response in the IT community. Still would. “Agile, cloud-based, deep machine learning, artificial intelligence” - and all these bases are not from the mouth of an IT-geek, but the words of a statesman, president and chairman of the board of Sberbank of Russia. I think that German Oskarovich, of course, did not himself write the theses of the IT part of his speech, but, as usual, the emu was helped by the IT advisors.

Further in the post quotes from the speech on the post at Geektimes , the questions they caused to me, my answers and hypotheses about what the IT advisors wanted to say and, finally, the grumbling about the dangers of revolution.

Quote: “Last year we made 27,000 changes to the platform. For comparison, 5 years ago we made 600-800 changes. This year we will make 41,000 changes. If you look at the cans - we are in chocolate, everything is in order. If you look at all these guys here - Amazon, Google and so on, then Amazon makes 10,000 changes to its platform per day. 10,000 a day and 40,000 a year are incomparable things. Time to market is a clock, and time to market is a noncompetitive story. ”
')
Question: What does the number of platform changes per unit of time indicate?

Answer: Nothing but the productivity of programmers.

Hypothesis: The number of employees of the company Amazon, approximately 100,000 people. Since the company's business is the sale of goods and services via the Internet, and not the production of software, the IT people in it are the attendants, and I believe that they constitute no more than 5% of the total number. Total, somewhere, 5,000 people. Of these programmers, about a quarter, that is, 1,250 people. The remaining managers, analysts, testers and other admins. We consider the performance.

The average number of changes transmitted by the programmer to the test during the working day is 10,000 changes per day / 1,250 programmers = 8 changes per day.

And this is a very cool competitive result.

Askhat, in his blog , referring to the speech at the conference, one of the directors of Amazon in 2011, says that this is not about changes, but about production deployments, that is, how many times during a period of time changes go to the server and becomes available for final users.

I do not believe. Not Askhat, of course, but the director. Even if my estimates of the programmers' performance are not too high, then in production every 10 seconds should leave on average no more than one change. What's the point? And if there are more changes, who makes them besides programmers.

Question: How are the number of changes and Time to market?

Answer: Not at all. Because Time to market is determined by the system architecture and production technology. The more business logic is spread out, the more connectedness between modules is, the more time is required for analysis, design, development and testing. And first of all - regression. The more critical and responsible the business, the more difficult the technological processes and the stricter the regulations. Otherwise - “Phobos in the ground” and no agile will save it.

Quote: “And we decide for ourselves that we are leaving for a breakthrough in general, we are completely changing our platform. We are buying a small stake in a Russian-American company that won the tender we held, won the tender from Oracle, IBM, and so on - from everyone. Its platform (C_B: error in the source) The performance of its platform (C_B: quote on video) was an order of magnitude higher, exactly an order of magnitude higher than those of these companies. Sixty programmers do it. ”

Question: Why is the new solution called the platform (as is clear from the Internet, this is In-Memory Data Fabric, from GridGain Systems, which specializes in In-Memory Computing)?

Answer: This is not a platform, but an in-memory database. It does not have a business process engine, an ESB class solution with automatic dispatching and guaranteed delivery, an analytical and reporting platform and much more.

Q: And what exactly did they compare in performance to In-Memory Data Fabric with Oracle RDBMS and IBM DB2, or, nevertheless, with comparable Oracle TimesTen and SolidDB solutions acquired by IBM.

Hypothesis: I really hope that the second, as well as that they have not forgotten one of the leaders among the products of this class, SAP HANA.

Question: Why was the choice made precisely for performance?

Hypothesis: I think that the selection criteria were much broader and included the cost / availability of support, information security requirements, reliability, the presence of a developer community, and much more.

And now grumbling.

Sberbank starts not one, but just three revolutions: rewriting the entire system, the transition to new IT technologies, the widespread introduction of agile processes. The fact that "this is, of course, a colossal challenge" Gref is certainly right. But, on the other hand, “a project without risks is the lot of losers”.

Not sure whether to compare Sberbank with Goolge, since Google - this is 2 billion lines of code . I think if you rewrite the entire AIS of Sberbank, it will be, somewhere, 10 million lines of source code, including autotests. But this is also a serious challenge and probably the main danger, since only 14% of such large-scale developments are completed successfully, and 65% successfully fail ( S. McConnell, “How much does a software project cost?”, “Peter”, 2007 ).

The average performance of good project teams in developing BSS software is 40 tested and documented SLOCs per fighter per day, including managers, analysts, testers, and other admins. Consequently, the total complexity of developing a new system will be

10 000 000 SLOC / (40 SLOC per day per person * 21 days per month) = 12 000 people * months.

And this is an optimistic estimate since the average industry performance, according to statistics from COCOMO II, is only 15 SLOC per day.

You should not expect that 6 thousand Sberbank programmers will develop this system in 2 months, since “nine pregnant women will not give birth to a child in a month”. If we estimate the duration of the project according to Barry Boehm ’s formula , we get

Duration [months] = 2.5 * 12 000 ^ (1/3) = 60 months = 5 years

And this is not one project, but a whole program of projects.

Now about the main risks and how they can be counteracted.

1. Inaccuracy and incompleteness of the requirements for the existing system.
Laying on analytics is approximately two times more labor-intensive than creating a system from scratch, because sometimes, apart from decompiling an executable legacy code, nothing can help.

2. Get even more blurred logic and more related modularity.
Plan a thorough, comprehensive architectural design, prototyping, and testing for compliance with non-functional requirements. Moreover, it is necessary to design not software, but a system of systems, which includes electrical equipment, computing infrastructure and storage, software, telecommunications and organizational support, taking into account all their various interconnections and interdependencies.

3. Instability of new basic software.
I am optimistic about new technologies and believe in the professionalism of programmers with Russian roots, but I know that it takes ten years to develop a serious product applicable in a critical business. I didn’t google it, what is the current stable version of In-Memory Data Fabric software, but I remember well that for the first ten years, according to Larry Ellison himself, customers demanded not money to be returned, but data. And the database version suitable for critical applications was only 5.1. Therefore, it is worthwhile to spend additional time and costs on stabilizing the new basic software.

4. Decreased team performance due to the transition to the new basic software and production processes.
In the old way it is impossible, but in a new way we are not yet able. Therefore, it is necessary to take into account the learning curve in the plans.

5. "Achilles will never catch up with the turtle."
All attempts known to me to immediately replace the old system of this scale with a new one failed. This happened because of the unacceptable costs of parallel changes in functional requirements in the old and new system. I do not even advise you to think about it. “An elephant cannot be eaten whole”, therefore it should be cut into subprojects, which can be implemented by a team of 7-10 fighters and in a period of 6-10 months. And on readiness to replace in industrial operation old functionality with new. By the way, the possibility of such an approach is also one of the important requirements for architectural design. Such an approach will approximately double the laboriousness of developing the system, since it will require additional efforts to integrate the old and new systems to ensure their peaceful coexistence. But it should not affect the timing, since the development and integration can be carried out in parallel.

Shl. Of course, in IT you can do anything that does not contradict the laws of nature. This is only a matter of political will, money and time.

Successes!