May 27, 2014 at 14:34Impressions of attending the CRAFT conference in Budapest (April 23-25) and video reports
Just a month ago (April 23-25) in the glorious city of Budapest, a conference for CRAFT developers was held . I was lucky enough to get on it and now I got around to write a review about what I saw and heard.
The conference attracted to itself not by the fact that you can get to Europe at the corporate expense, but by a selection of invited authors, among whom were Dan North, Michael Feathers, Bruce Eckel, Eric Evans, Greg Young. It is strange that there was no mention of her on Habr. Despite the fact that the conference was declared as a conference for developers, it was not about technology at all. There were several reports about the use of specific technologies, but most of the reports were about development in general.
The motto of the conference is the call “Adapt!”. This thought was heard in so many reports. Maybe the organizers therefore did not give out notebooks in the package of participants - they wanted us to adapt? =) At the same time, they gave out pens and had to look for a notebook in the surrounding stores.
Under the cutscene, the description and video reports that seemed to me the most interesting.
Insert the video directly into the article did not work, so the video is represented by links. If anyone helps with the insertion of the videos themselves, I will be grateful.
For myself, I highlighted some of the most useful and interesting reports, and arranged the rest in chronological order.
Video report
A very informative first report that set the tone for the entire conference. The main idea: flexible approaches are applicable only where the changing external world. If the outside world is static with respect to the system, then scrum degenerates into waterSrumfall , which entails overhead costs without additional profit. If the outside world is not well known or is changing rapidly, then you need to be able to adapt. As an example, the author gives the experience of the Ducati team during their debut on the superbike track. In a critical situation, everything is flexible, because you need to adapt quickly, otherwise you will not survive.
As a way to adapt to the situation, the author offers User Stories.
The main idea: from user stories you need to compose and use the roadmap for its intended purpose: as a " road map ". The author says that most of the roadmap he saw was actually a tunnel , not a road map . A tunnel involves moving in only one direction, and not many path options. As an example, the author cites a car navigator. It is ideal for planning and orientation on the ground, because it shows two main information blocks that describe the current situation:
Further, the author went on to Palchinsky’s principles from Tim Harford’s book Adapt: Why Success Always Starts with Failure : link to a quote about principles.
The author shows that user stories should be used to analyze what the customer actually wants, and then to adapt to the current situation of the project. No need to try to realize all the stories, because it may either not be necessary, or very expensive. Instead, you should consider user stories as a set of alternatives (road map) that you can choose when the situation around the project changes.
He said that he was preparing the book “50 quick ideas to improve your User Stories”.
Report video A report
from the category "how it turns out that smart people do stupid things." It is worth looking to try to compare your behavior with examples. Examples are all vital with real projects. In the end, the author was even asked the question "did you even work on successful projects." The report looks very easy due to the abundance of examples and interesting points that you can laugh at.
The author makes fun of architectural fails - decisions that were made in different projects at different times, including by himself. He talks about how this decision was born, why the idea seemed cool and why the embodiment of the idea turned out terrible. Most of the systems he talks about are used in reality. The author makes concise conclusions about what cannot be done, or vice versa, to be done in order to avoid such problems. A few basic points (I did not write out everything - without a context they will not be clear):
Report video - unfortunately the video starts from about the 10th minute. In the first part, Dan discusses how professionals in different fields practice skill.
A report on how to travel to Mastery and what Mastery in general is. The story is based on folding the origami “Jackstone”, which the author could not add up to 15 years.
Basic definition: Mastery is opportunity in context. It's hard to tell something about this report without retelling it in full. I recommend for viewing to all who are interested in the topic of improving their skills.
Video report
This report was the most expected for me - I wanted to hear about these three letters DDD first-hand. But, surprisingly, this report turned out to be one of the most tedious reports at the conference. It may also be because I already know a lot about this and have heard little from the report. Evans spoke without emotion, in an academic tone. It was hard to listen, but the essence conveyed quite clearly.
The first part of the report is devoted to the description of how important it is to correctly distinguish aggregates and their roots and how this can affect the performance and survivability of the system in the future. The story was based on the example of the delivery of freight containers across the oceans and coordination of the delivery schedule. He showed how, depending on the choice of aggregates and their roots, the behavior of the system changes and what kind of rake is obtained in each case. Key points: correctly formulate questions for the system and balance between normalization and denormalization.
Inconsistency between the states of aggregates is a normal phenomenon and exists in any complex system. Therefore, it must be governed by agreements (SLAs) that govern how long such inconsistency can exist in the system.
At the end of the report, I touched a little on bounded contexts. Between contexts, use the Enevtual Consistencey.
Video report
A good introduction to the principles of reactive programming and event-oriented development. The author says that the main problem of reactive programming is a large entry threshold, but after overcoming this threshold, the approach becomes obvious and simple. Key points:
Report video
Nothing happens for free. You have to pay for any architectural solution, so there is no perfect abstract architecture. The flexibility of an architecture (like a system) is always relative and time-dependent. Therefore, you always need to explore and adapt.
Due to the different interests of different stakeholders, it is impossible to create one universal diagram. A set of diagrams should be considered as a set of maps of various scales, in which a set of abstractions is much more important than a set of notations. It is proposed to use the C4 model:
You need to think in Components, and implement in Classes. It is important to distinguish between these two points of view. Well, in conclusion, a key message from the author of the report: return the architecture back to the developers !
Video report
A report on what the quality of the development process is all about. Not only writing code, but generally the whole process. The report can be viewed if revenge is 50 minutes of free time. Despite the obviousness of the main points, they are not applied everywhere, which leads to poor results. KO broadcasts:
Report video A report
from a former saxophonist who became a developer. The introductory report of the second day of the conference, because it is about the development world as a whole. About inspiration and courage in the development, about the quality of software, contradictions in the views and goals of developers and customers who give rise to low-quality solutions.
The author mentions the development process in the pledge of the story about Six Sigma , that the Function is important for the customer, and the form is important for the developer. There is always a confrontation of internal and external quality. Here you need to be able to balance, because internal quality determines, but not always, external. And this "not always" must be able to identify.
Software report video sucks. The rest of the report is an explanation of this thesis and a search for reasons why this is so. main reasons:
Video report
Report on the benefits of the Event Sourcing approach over traditional normalized databases. Any DBMS sucks (Every database sucks!). But each sucks in its own unique and unique way. Therefore, it is necessary to use a tool suitable for this task for each specific task. Storing the flow of events instead of states allows this. I did not succeed in highlighting specific theses, because this was the last report on the second day of the conference, but it’s worth looking at the report.
Video report
For me, this report was from the category of Captain’s revelations. Evidence: Make autotests the most autonomous. The test should test one particle of functionality at the right level of abstraction. If the wrong level of abstraction is chosen, then Automation of testing the UI is impossible, because you need to look at the UI to evaluate its quality.
Video report
Strange report. Statistics Slide Set from Developer Productivity Report
Report video I
expected some sacred knowledge from the report on how to make really flexible databases, but everything turned out to be trite:
The conference attracted to itself not by the fact that you can get to Europe at the corporate expense, but by a selection of invited authors, among whom were Dan North, Michael Feathers, Bruce Eckel, Eric Evans, Greg Young. It is strange that there was no mention of her on Habr. Despite the fact that the conference was declared as a conference for developers, it was not about technology at all. There were several reports about the use of specific technologies, but most of the reports were about development in general.
The motto of the conference is the call “Adapt!”. This thought was heard in so many reports. Maybe the organizers therefore did not give out notebooks in the package of participants - they wanted us to adapt? =) At the same time, they gave out pens and had to look for a notebook in the surrounding stores.
Under the cutscene, the description and video reports that seemed to me the most interesting.
Insert the video directly into the article did not work, so the video is represented by links. If anyone helps with the insertion of the videos themselves, I will be grateful.
For myself, I highlighted some of the most useful and interesting reports, and arranged the rest in chronological order.
The most useful and / or interesting reports (highly recommend for viewing)
How I Learned to Stop Worrying and Love Flexible Scope (Gojko Adzic)
Video report
A very informative first report that set the tone for the entire conference. The main idea: flexible approaches are applicable only where the changing external world. If the outside world is static with respect to the system, then scrum degenerates into waterSrumfall , which entails overhead costs without additional profit. If the outside world is not well known or is changing rapidly, then you need to be able to adapt. As an example, the author gives the experience of the Ducati team during their debut on the superbike track. In a critical situation, everything is flexible, because you need to adapt quickly, otherwise you will not survive.
As a way to adapt to the situation, the author offers User Stories.
The main idea: from user stories you need to compose and use the roadmap for its intended purpose: as a " road map ". The author says that most of the roadmap he saw was actually a tunnel , not a road map . A tunnel involves moving in only one direction, and not many path options. As an example, the author cites a car navigator. It is ideal for planning and orientation on the ground, because it shows two main information blocks that describe the current situation:
- distance to the next turn;
- direction of the next turn.
Further, the author went on to Palchinsky’s principles from Tim Harford’s book Adapt: Why Success Always Starts with Failure : link to a quote about principles.
The author shows that user stories should be used to analyze what the customer actually wants, and then to adapt to the current situation of the project. No need to try to realize all the stories, because it may either not be necessary, or very expensive. Instead, you should consider user stories as a set of alternatives (road map) that you can choose when the situation around the project changes.
He said that he was preparing the book “50 quick ideas to improve your User Stories”.
Architecture War Stories (Stefan Tilkov)
Report video A report
from the category "how it turns out that smart people do stupid things." It is worth looking to try to compare your behavior with examples. Examples are all vital with real projects. In the end, the author was even asked the question "did you even work on successful projects." The report looks very easy due to the abundance of examples and interesting points that you can laugh at.
The author makes fun of architectural fails - decisions that were made in different projects at different times, including by himself. He talks about how this decision was born, why the idea seemed cool and why the embodiment of the idea turned out terrible. Most of the systems he talks about are used in reality. The author makes concise conclusions about what cannot be done, or vice versa, to be done in order to avoid such problems. A few basic points (I did not write out everything - without a context they will not be clear):
- Don't cache the cache.
- Data should be free of code dependencies.
- Fight the madness.
Jackstones: the journey to mastery (Dan North)
Report video - unfortunately the video starts from about the 10th minute. In the first part, Dan discusses how professionals in different fields practice skill.
A report on how to travel to Mastery and what Mastery in general is. The story is based on folding the origami “Jackstone”, which the author could not add up to 15 years.
Basic definition: Mastery is opportunity in context. It's hard to tell something about this report without retelling it in full. I recommend for viewing to all who are interested in the topic of improving their skills.
Acknowledging CAP at the Root - in the Domain Model (Eric Evans)
Video report
This report was the most expected for me - I wanted to hear about these three letters DDD first-hand. But, surprisingly, this report turned out to be one of the most tedious reports at the conference. It may also be because I already know a lot about this and have heard little from the report. Evans spoke without emotion, in an academic tone. It was hard to listen, but the essence conveyed quite clearly.
The first part of the report is devoted to the description of how important it is to correctly distinguish aggregates and their roots and how this can affect the performance and survivability of the system in the future. The story was based on the example of the delivery of freight containers across the oceans and coordination of the delivery schedule. He showed how, depending on the choice of aggregates and their roots, the behavior of the system changes and what kind of rake is obtained in each case. Key points: correctly formulate questions for the system and balance between normalization and denormalization.
Inconsistency between the states of aggregates is a normal phenomenon and exists in any complex system. Therefore, it must be governed by agreements (SLAs) that govern how long such inconsistency can exist in the system.
At the end of the report, I touched a little on bounded contexts. Between contexts, use the Enevtual Consistencey.
Just good and interesting reports in chronological order
Going Reactive: Event-Driven, Scalable, Resilient & Responsive Systems (Jonas Bonér)
Video report
A good introduction to the principles of reactive programming and event-oriented development. The author says that the main problem of reactive programming is a large entry threshold, but after overcoming this threshold, the approach becomes obvious and simple. Key points:
- always use weak binding;
- it is necessary to design so that there are no locks ever;
- it is necessary to design asynchronous interaction initially;
- actors communicate only through messaging;
- using Shared nothing architecture;
- location transparency;
Agility and the essence of software architecture (Simon Brown)
Report video
Nothing happens for free. You have to pay for any architectural solution, so there is no perfect abstract architecture. The flexibility of an architecture (like a system) is always relative and time-dependent. Therefore, you always need to explore and adapt.
Due to the different interests of different stakeholders, it is impossible to create one universal diagram. A set of diagrams should be considered as a set of maps of various scales, in which a set of abstractions is much more important than a set of notations. It is proposed to use the C4 model:
- System context
- Container
- Components
- Classes
You need to think in Components, and implement in Classes. It is important to distinguish between these two points of view. Well, in conclusion, a key message from the author of the report: return the architecture back to the developers !
What Makes a Good Development Process? (Bruce Eckel)
Video report
A report on what the quality of the development process is all about. Not only writing code, but generally the whole process. The report can be viewed if revenge is 50 minutes of free time. Despite the obviousness of the main points, they are not applied everywhere, which leads to poor results. KO broadcasts:
- Using repositories for versioning, testing of everything that can be tested and automation of everything that is done more than 1 time, including tests.
- Communication, honesty and transparency throughout the project life cycle. First of all, before the customer.
- Release in a minimum valuable product (Minimum Valuable Product). But you need to produce a product that is valuable to the customer, and not to the developer. Based on this, it is necessary to build priorities in solving specific problems.
- Automatic continuous delivery (Continuous Delivery), as a mechanism for constant version updates. This allows you to release the first version of MVP as early as possible and further refine on the most important functions.
- Mistakes are inevitable. They need to learn and adapt (again, "Adapt!").
- BrainStorming replace with BrainWriting. During BrainWriting, participants write their opinions in writing, and then everyone gets together and discusses. This is better than BrainStorming, because everyone can speak, not just the most loud.
- The most understandable and supported solution is the best choice in most cases.
- It is necessary to do CodeReview.
McDonalds, Six Sigma, and Offshore Outsourcing: Unexpected Sources of Insight (Chad Fowler)
Report video A report
from a former saxophonist who became a developer. The introductory report of the second day of the conference, because it is about the development world as a whole. About inspiration and courage in the development, about the quality of software, contradictions in the views and goals of developers and customers who give rise to low-quality solutions.
The author mentions the development process in the pledge of the story about Six Sigma , that the Function is important for the customer, and the form is important for the developer. There is always a confrontation of internal and external quality. Here you need to be able to balance, because internal quality determines, but not always, external. And this "not always" must be able to identify.
Responsibly maximizing craftsmanship in software engineering (Theo Schlossnagle)
Software report video sucks. The rest of the report is an explanation of this thesis and a search for reasons why this is so. main reasons:
- The development of high-quality software is a very difficult task (practically impossible).
- Engineers are subject to "traditions." It is customary here and it works, so don’t touch it.
- The developers do not read academic literature and do not know the basics.
- Teams within a company or even a project do not share best practices.
- Engineers work perfectly autonomously (but in small projects), so problems arise in large projects.
- It is often easier to write from scratch than to refactor, but most people prefer to refactor.
Polyglot Data (Greg Young)
Video report
Report on the benefits of the Event Sourcing approach over traditional normalized databases. Any DBMS sucks (Every database sucks!). But each sucks in its own unique and unique way. Therefore, it is necessary to use a tool suitable for this task for each specific task. Storing the flow of events instead of states allows this. I did not succeed in highlighting specific theses, because this was the last report on the second day of the conference, but it’s worth looking at the report.
Well, reports that are not worth the time
Find the Right Abstraction Level for Your Tests (Gerard Meszaros)
Video report
For me, this report was from the category of Captain’s revelations. Evidence: Make autotests the most autonomous. The test should test one particle of functionality at the right level of abstraction. If the wrong level of abstraction is chosen, then Automation of testing the UI is impossible, because you need to look at the UI to evaluate its quality.
Data-Driven Software Engineering (Jevgeni Kabanov)
Video report
Strange report. Statistics Slide Set from Developer Productivity Report
Databases & Schemas in an Agile World (Andrew Godwin)
Report video I
expected some sacred knowledge from the report on how to make really flexible databases, but everything turned out to be trite:
- use PostgreSQL because it gives minimal downtime and locks when changing the schema;
- the scheme must be modified only within the framework of the transaction;
- Well, he suggests using hybrid (part of the data in typed columns, and the rest in blob fields as xml or something else) schemes to optimize between flexibility and speed.