The painful truth of leaky abstractions 20171125 1

The painful truth of leaky abstractions 2017/11/25 1

Private and Confidential 2

About myself Yurii Hohan - Software Engineer at Aculocity • • Extremely passionate of databases, software architecture, deep reflection and technical details. Like public speaking – being both at receiving and especially at the giving end. Always open to giving public talks (“Microsoft SQL Internals” workshop ) – yuriihohan@gmail. com 3

Abstractization Please, close your eyes and imagine a dog. Now, let’s share the breed of the dog and its short description. Ideas Thoughts Dog Real World Terms Words 4

Abstraction (from the Latin abs - meaning away from) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics. In software engineering, abstraction is a technique for arranging complexity of computer systems. It works by establishing a level of complexity on which a person interacts with the system, suppressing the more complex details below the current level.

Abstraction & inferring 6

Law of Leaky Abstraction – Joel Spolsky All non-trivial abstractions, to some degree, are leaky. This means the details of the lower level concept that are being abstracted away are leaking up through the higher level concept. Private and Confidential 7

Start the TV set example In theory, starting the TV is as easy as clicking the button on the remote control. What could possibly go wrong: • • • Remote control batteries might stop functioning or it might get lost. TV signal from the operator might get lost because of bad weather. You might have to switch TV source. You might have to start TV tuner. TV might be broken. You might have forgotten to pay you subscription fee. The list may go on and still it is not all that vast. It will work in most of the cases. 8

Driving a car example In 2010, number of cars in the world surpassed 1 billion. Crazy. Driving a car is simple? What can go wrong? 1. Technical fault (check engine, brakes, etc. ) Manufacturers started to introduce electronics to diagnose – dealing with the leak. 2. You might need to accelerate quickly and that will require choosing lower gear speed. 3. The driving surface might require special driving – aqua planning, breaking on the ice, road with gravel or bad Moldavian road Now just imagine that instead of driving a car you fly the plain. 9

Driving a car example When abstracting, think of concequences. In 2010, number of cars in the world surpassed 1 billion. Crazy. Can the Earth handle that? 1. Ecological disaster. 2. Complex crossroads. 3. Fuel consumption. Non-recoverable resource. 4. Transport of future – multi-height buses. 10

Consequences (1) Poor performance – slow systems 11

Consequences (2) Doing things inefficiently and without understanding aka “cargo cult” 12

Consequences (2) Doing things inefficiently and without understanding aka “cargo cult” 13

Consequences (3) Not modeling all the cases right aka “corner case” 14

Consequences (3) Not modeling all the cases right aka “corner case because of third party” • • • Because of third party. Example – a scheduler library that does not take Daylight Saving into Account Locale differences. Forgetting about the Black Friday in USA Business logic dictated. Example – still prefer permanent supplier if the cost expenses are less than 10%. 15

Leaking more than necessary 16

17

LINQ – Demo 1 It is one my favourite. NET features, LINQ is easy to addict to. But it is non-trivial and unfortunately – it leaks. Give some examples of the leakage: Performance. 18

Why SELECT * is a bad idea? – Demo 2 You work on Football Online Store Site. You have been assigned to improve the performance of a page which reads from a big. Transaction. History table containing history of all the orders in the system. You need to show the details of latest 100. What will you do? Let’s see 19

Online Interview App – Demo 3 Suppose we create a Watch. Sport. Together TV app. We are a group of friends who love football. We live in different places. We would like to use an app to get together and watch football. Today it is the 24 th of March 2018 and we are in Moldova. We know that the next game is on the 26 th of March 2018 17: 00 and we invite guys from Birmingham, Alabama, USA. Both parties must be present on time to enjoy the game. What could go wrong? 20

Minimizing leakage (1) Offer consistent abstraction Make sure you offer the same level of abstraction across the board. E. g. – if you create a REST API, make sure that all the resources of it are RESTful. If you use /teams to GET all the teams and /teams/3 to GET the team with id 3, use the same for all the resources – players, coaches, etc. (instead of players/? id=3) Most obvious rule – very often not followed because of lack of knowledge, not enough knowledge sharing, attention sloppiness, not caring about the leakage. 21

Minimizing leakage (2) Introduce additional abstractions for special cases Continuing the previous example, you decided to go with PUT to modify API resources. It is not good for /games and you want to use delta loads. Start using PATCH but do not do delta loads through the PUT method. E. g. – if we talk about class design to a class with Simple. Operations and one with Complex. Operations. 22

Minimizing leakage (3) Accept that leakage is inevitable and let the abstraction ask the developer to make the choice. e. g. – table variables vs temp tables Lazy loading vs eager loading in ORMs Class vs struct in. NET 23

Minimizing leakage (4) May be not try to abstract at all? If you feel like what you create leaks too much, it might be a clear indication it is not worth the effort of creating it and more important if the effort of others to understand it. 24

Conclusions 1. In order to use engineering tools right, you have to learn the abstractions. Not down to the lowest level off course because that destroys the point of it. Before starting – make sure you understand the abstraction. Next step – digging deeper when the problem comes 25

Conclusions 2. Being a specialist in a domain means knowing what is hidden behind the abstraction. For yourself, count the number of things you consider to know thoroughly. Do the same things for the team you work with. (Ideally your team should cover the whole stack of your development) 26

Conclusions 3. Think of the tools you use. Does the leakage happen often in your work? May be, frequent leakages are indicators to consider other tool. 4. When you engineer something(especially external), minimize the leakage with all means. We may be talking about an external library, user page, anything. 27

Further reading 1. https: //www. joelonsoftware. com/2002/11/11/the-law-of-leaky-abstractions/ Joel Spolsky - The Law of Leaky Abstractions 2. Jeff Atwood - https: //blog. codinghorror. com/all-abstractions-are-failedabstractions/ 3. https: //www. youtube. com/watch? v=l 3 n. PJ-y. K-LU Jon Skeet - "Back to basics: the mess we've made of our fundamental data types" 4. http: //jonskeet. uk/csharp/teasers. html Jon Skeet - C# Brainteasers 5. https: //sqlperformance. com/2014/06/t-sql-queries/table-variable-perf-fix 6. https: //www. amazon. com/T-SQL-Querying-Developer-Reference-Ben. Gan/dp/0735685045/ref=pd_lpo_sbs_14_t_1? _encoding=UTF 8&psc=1&ref. RID=Z H 6 FX 6 TWHGGTWR 7 B 6 WA 9 - T-SQL Querying (Developer Reference), Itzik Ben. Gan 28

Feedback Private and Confidential 29