Search
EuRuKo 2024
Seven things I know after 25 years of development
Edit
#software-development
#ruby
#domain-driven-design
#technical-debt
#developer-experience
#storytelling-in-tech
Summarized using AI

Seven things I know after 25 years of development

Victor Shepelev • September 11, 2024 • Sarajevo, Bosnia and Herzegovina • Talk

In the talk titled "Seven things I know after 25 years of development" at EuRuKo 2024, Victor Shepelev shares insights he has gained over his extensive career as a developer, particularly focusing on his experience with Ruby and his perspective as a Ukrainian during the war. Victor emphasizes the evolving nature of development practices and methodologies, using personal anecdotes to enrich his discussion. Here are the key points outlined in his talk:

  • Framework Dependence: While frameworks like Rails provide structure and confidence in code, developers must be prepared to make their own architectural decisions as projects grow. Relying solely on frameworks can lead to bloated and poorly organized code.

  • Outdated Methodologies: Just as international security frameworks can become irrelevant, coding methodologies can fail to address current needs. Developers must remain adaptable and recognize that once-trusted patterns may no longer serve the purpose effectively.

  • Continuous Growth: The codebase and associated complexities naturally grow over time, and developers need to be aware of this growth to adapt their methods and technologies. Projects, regardless of their original scale, often expand significantly and require fresh approaches as they evolve.

  • Narrative Focus: He advocates for paying attention to the individual stories within a codebase. Understanding the narrative and unique interactions helps developers design better solutions rather than adhering rigidly to architectural rules.

  • Pursuing Truth in Code: Victor claims that the ultimate goal in software development should not be merely good architecture but discovering the truth about what works effectively. Listening to the stories within the code leads to better understanding and better practices.

  • The Challenge of Truth: Emphasizing that seeking truth may lead to discomfort, especially when established practices or habits are questioned. Developers should embrace change and prioritize honest reflection over dogmatic adherence to old methodologies.

  • The Importance of Communication: He highlights that discussing code through peer reviews is essential for ensuring clarity and understanding among teams, which leads to better collective problem-solving and knowledge sharing.

Ultimately, the talk encourages developers to remain curious, adaptable, and committed to the pursuit of truth, despite challenges. Victor concludes with a heartfelt reminder of his Ukrainian identity and the importance of supporting Ukraine during difficult times, appealing to the audience's sense of solidarity.

Seven things I know after 25 years of development
Victor Shepelev • Sarajevo, Bosnia and Herzegovina • Talk

Date: September 11, 2024
Published: January 13, 2025
Announced: unknown

Through years of career, every developer dedicated to their craft gathers their own set of beliefs, opinions, and habits. Some of them are just reinforcing the common wisdom, some might be quite peculiar; some become irrelevant with time, some only grow stronger; some are about big and important things, and some might be considered nitpicks.

Let me share some of mine—without promising them to be universal or even extremely useful, but with a promise of interesting stories and choices behind them.

EuRuKo 2024

00:00:16.560 hi I am Victor she and I'm happy to be able to talk at Euro unfortunately I can
00:00:25.279 only talk in recording but it's a great honor nevertheless my talk is about
00:00:31.840 seven things I know after 25 years of development a few words about myself I
00:00:38.680 am writing software for about 25 years and uh of them almost 20 or currently
00:00:47.039 maybe more than 20 is dedicated to Ruby using as my primary language uh I've
00:00:53.559 made some contributions to the language itself I write about it a lot uh I
00:01:00.480 maintain the Ruby change log site some some of you might have heard about it uh
00:01:09.240 also I am kind of a principal engineer for us company called Hub stuff but only
00:01:17.320 kind of because uh the most important thing about me is that I am Ukrainian
00:01:23.960 serving in the armed forces currently not in combat position doing other
00:01:29.920 things that I'm better at uh and the rest of my activities are happening
00:01:36.520 besid those duties I joined the army not because I am some kind of militarist to
00:01:44.680 L arms or fighting but because I felt that I have a duty to protect my
00:01:51.520 homeland and it is the same for many ukrainians all kind of people are
00:01:57.039 serving in our armed forces and and uh I have a small personal project of
00:02:04.479 translating poets who are currently serving in our army in English so
00:02:11.000 considering this the actual actual uh title of my talk is seven things I know
00:02:19.200 after 25 years of development and 10 years of War uh it is still about
00:02:25.760 development and druby but I allowed myself to draw some parallels with my
00:02:31.800 experience as Ukrainian and I hope it made the talk richer nothing to graphic
00:02:38.920 or disturbing I promise so let's get to the matter and those seven things I
00:02:46.440 wanted to share as the first one of them is that uh you would grow every framework in any
00:02:54.720 area not only in Tech we frequently rely on various frame Frameworks and
00:03:00.760 Foundations to know what to do what to expect uh what's in our
00:03:06.560 future and how things are related to each other say in international relations uh ukrainians for a long time
00:03:14.120 relied of on notion of being a sovereign country whose security is guaranteed by
00:03:20.560 uh Global Powers but eventually turned it out it is not
00:03:25.599 so but back to TCH uh as a programmers
00:03:31.040 we frequently of course rely on Frameworks as rubis we frequently rely
00:03:37.000 on the framework but I not about to criticize any particular one uh so I
00:03:43.159 have uh turos relationship with rails but I appreciate it as a foundation for
00:03:50.599 many great projects and as a things that made uh Ruby popular and uh still moves
00:03:57.480 forward the thinking in the language uh but my point is Frameworks provide us
00:04:04.079 room and boxes to put our cod in and to feel confident with uh only implementing
00:04:10.400 the business logic inside those uh rooms boxes and limitations but we all know
00:04:16.440 eventually is code grows we have more Concepts and then even more and uh some
00:04:23.880 of them are provided by updated versions of your framework some of them are from
00:04:29.360 s party libraries some of them you implement yourself but however we extend
00:04:36.199 the number of General number of Concepts we rely upon something always sticks out
00:04:43.840 and like a fractal uh every particular concept starts small and then grow into
00:04:51.199 framework of its own like common nowadays colable objects uh call them
00:04:57.479 service objects or operations ctions and interactors they have many names uh this
00:05:04.520 is a simple idea when you introduce it it might seem as a small step you need to achieve
00:05:10.280 completeness of the mental model of how things are related in your Cod base and
00:05:16.560 then there are new requirements and new use cases and eventually you have uh a
00:05:22.840 few dozens of DSL options to define a small uh
00:05:31.560 service object or Cal object and uh then uh some case sticks out anyway not
00:05:40.440 fitting into any of the previous definitions and if you don't handle things that sticking out of the
00:05:47.680 conceptual model you laser have very blotted Concepts like uh huge
00:05:53.120 controllers huge models huge service objects huge decorators or you have have
00:05:59.880 some garbage being in your code base like lib folder or Services folder where
00:06:05.720 everything that sticks out goes and eventually nobody knows what is there so
00:06:12.800 uh basically to handle this you should always be ready to make your own
00:06:18.800 architectural decisions regardless of the framework you rely upon but there is
00:06:25.520 a problem and the second thing I'm sure of that uh whole patterns methodologies and
00:06:34.720 approaches also failure and get outdated like again back to Ukrainian
00:06:41.080 experience their whole International Security architecture became laughing matter at
00:06:47.639 some point and international humanitarian structures Prov themselves useless and human rights Defenders
00:06:55.440 defend anything other than human rights as a developers when we make a decision
00:07:01.280 we might rely on some methodologies trusted approaches books pattern or
00:07:08.039 funny pneumonics and coding simple principles as code grows project matures
00:07:13.639 as industry develops new opinions as challenges change a lot of doubts and
00:07:19.960 questions emerge you might learn that inheritance
00:07:25.280 was an idea that is good only in textbooks you might here that the whole
00:07:31.440 uh object oriented programming have failed us you start to adapt where the active record is a
00:07:38.520 good pattern and viable approach or maybe you need uh passive entities and
00:07:45.159 repositories and uh draw some inspiration from functional programming
00:07:50.599 you might be reminded that solid is an acronym coined for marketing purposes
00:07:56.840 just by one person and it groups useful but vular defined and contradictory
00:08:02.879 principles and in general for any common approach we know for anything that we
00:08:08.440 learn in school or later there is a lot of Articles uh and even
00:08:15.159 books uh arguing about its usel uselessness or even harm harm
00:08:22.240 harmfulness and there are farther counter arguments and counter arguments
00:08:28.199 to that and uh eventually we discover for ourselves more newer more high level
00:08:37.880 uh guiding principles like uh domain driven design which follows very same
00:08:43.479 idea of isomorphism of our domain which we Implement and its coding
00:08:49.839 representation but it still leaves many Blanks on design decisions like when small domain Concepts uh require huge
00:08:58.760 algorithmical implementation and where do you put it if in domain it's it's
00:09:04.000 something small and um what do you do when big domain concepts are very small
00:09:10.800 in code and those discrepan grow and grow and uh also DDD introduces a lot of
00:09:18.399 new terms which uh people love to turn into literal classes So eventually
00:09:24.399 beside your models use controllers decorators representers you have El
00:09:30.040 entities Aggregates bounded contexts and so on and so forth or sometimes uh we
00:09:37.519 might talk about hexagonal architecture as an more high level approach which is
00:09:43.720 notable for the fact that it never explains why is it hexagonal and also
00:09:50.839 for living the design decisions of the whole core AR architecture for yourself
00:09:57.720 which is not to say it doesn't provide some useful principles but uh still a
00:10:03.160 lot of questions remain a lot of uncertainties so those might help but
00:10:10.320 eventually you are still on your own in designing new things why is it
00:10:17.040 so so the third thing I'm certain of that scale only grows this time this is
00:10:25.519 true about many things in the world and it is also quite trivial state statement
00:10:32.600 let's be honest uh but it has frequently over look at
00:10:38.880 consequences uh like imagine any rails up you ever
00:10:46.120 maintain it for some time like maybe year or several years I think you
00:10:52.279 probably agree that all it did was growing uh we live in a capitalistic
00:10:58.800 world where you need to run fast to stay relevant whether it is some new tech
00:11:04.760 like uh switching old application to uh single page application or wi Versa or
00:11:11.880 supporting some mobile client or extending your market share to customers
00:11:17.279 of smaller or bigger scale than before or trying to adjust your Market feed
00:11:22.320 without losing old customers or just uh linear growth which poses new challenges
00:11:28.839 whatever happened there was more code more tables more end points more tests
00:11:35.639 more everything just grows uh as an example we might look at
00:11:41.320 the gitlab open source Cod base which at first looks like your regular rails up
00:11:48.600 uh initially it was what like just an UI for
00:11:54.040 collaboration around code on top of jet like almost trial s
00:11:59.880 but now gitlab is many things if you look into its main folder you'll see a
00:12:06.800 bit more thing than in uh smaller rails applications and then if you go into up
00:12:14.560 folder uh it has a multitude named Concepts uh
00:12:21.000 those standard for ra those more or less while uh
00:12:26.040 widespread and also some uh Uh custom ones characteristical only for this Cod
00:12:32.839 base and then if you investigate into one of those you see more code and more
00:12:38.199 code and know that the last screenshot only goes to letter C so it's like much
00:12:46.160 much more maybe not all of our projects are at scale of gitlab but talking about
00:12:52.720 any commercial and many non-commercial projects eventually you'll need things like repo or notifications better F
00:13:01.920 grain roll management maybe Payment Systems maybe some new opice maybe bul
00:13:08.800 operations some business analytics and so on and so forth the simple yet
00:13:15.839 frequently Overlook at cons consequence of this uh constant growth I was talking
00:13:21.880 about it is uh absolutely Perfectly Natural that your old ways of hand L
00:13:29.519 problems would stop work eventually that you overgrow your framework that you
00:13:34.959 overgrow your methodology that you find new methodology and overgrow outgrow of
00:13:41.240 it too uh so the basically is a way of thinking about
00:13:49.240 several dozens of classes five models three controllers and so on and the way
00:13:54.920 of thinking of several thousands of classes they uh re not quantitively but qualitatively uh
00:14:03.440 different approach so what do we do then to survive through all this uh I have
00:14:11.839 answer uh it's not a definitive one it's just one approach and it might seem like
00:14:20.320 somewhat paradoxical one so my answer is
00:14:26.240 pay attention to singular stories of your codebase when uh working with uh any
00:14:34.160 feature in our software or with uh any
00:14:40.079 particular task uh when when you implement uh something uh
00:14:46.920 when you fix something when you uh try to understand something uh we always
00:14:53.240 have some narrative to follow there are some causes and consequences there are
00:14:58.480 inputs outputs Transformations effects and it all can be told and followed
00:15:05.399 linear linearly but uh in modern Cod many modern Cod bases uh jumping through
00:15:12.880 layers and conventions And discussing the bigger picture we frequently losing
00:15:19.959 those particular particular threads of particular stories what goes where what
00:15:26.959 is connected to what and then we the big picture uh a small illustration uh once
00:15:33.040 upon a time a few years ago I was trying to add a new feature to rubocop it didn't work it out but for unrelated
00:15:40.600 reasons to the story uh and I had this big uh H moment uh when I spent like a
00:15:48.279 day trying to understand an algorithm uh of detecting uh which uh
00:15:55.680 cop disabled directives were redundant and uh it was uh split in several dozen
00:16:05.079 two three line methods very simple very readable each on its own but uh
00:16:12.240 eventually I rewrote it in uh what you see in half a screen sized
00:16:19.920 method which didn't match expected complexity Matrix of rocop uh here is by
00:16:26.319 the way the fragment of original algorithm but I don't have a screen big enough to screenshot the whole thing uh
00:16:33.399 that's not about badly written rubocop because rubocop is awesome piece of software it's very helpful it very well
00:16:41.279 designed and it uh it is one of core of our community but about uh some deeper
00:16:47.880 approach differences like splitting everything into ultimately small methods
00:16:53.639 extracting every non-trivial condition to a predicate is a very widespread
00:16:59.480 approach in rubby community and the default uh complexity threshold
00:17:07.319 of many lters and edas uh just just reinforce that uh but uh it leads to
00:17:17.880 what I'm talking about uh to losing uh a thre of a story that
00:17:24.039 happening uh as a counter opinion in
00:17:29.080 stuff we have this fragment in small coding rules document uh and uh our small coding
00:17:37.440 rules document is quite big and uh I'd say it as important as a whole whole
00:17:43.000 architecture document just for the reasons I'm trying to explain and this fragment underlines
00:17:50.160 the idea of trying to put everything together as a story first and impose
00:17:55.880 architecture particular only after that the single method is not a key here it's
00:18:03.960 just one representation of a story what is a key is point of view from which
00:18:11.799 focusing on exposing what's happening here this Cod is the main goal it uh
00:18:18.480 leads to discovering of good names of uh good structure uh of uh which concepts
00:18:26.480 are related and which are not and it uh happens much more reliably and
00:18:33.760 naturally than just trying to sit and come up with an architecture of
00:18:39.000 implementation of something which uh frequently when implemented in code uh
00:18:46.120 turns out to be just inside out
00:18:51.440 uh most of the time uh trying to Define some new
00:18:57.840 architectural decision starting from the big picture is uh stuck with the problem
00:19:03.679 that there is actually no no big picture in big software projects there is no
00:19:11.840 simple truth or simple set of rules that explain
00:19:17.039 everything uh everybody anybody who tried to make a
00:19:23.280 class flow diagram of a m mature project uh knows that that you you have just an
00:19:30.600 insane V that uh explains nothing uh it is all just a bunch of interlinked
00:19:37.799 stories each of them told on its own and it's like a garden with passes through
00:19:45.200 it not a concrete skyscraper and it's true for uh most of mature projects so
00:19:53.840 why those stories are so important
00:20:00.880 uh the fifth truth that
00:20:06.280 I'm I believe that I learned through my career that the goal is not beauty or
00:20:15.080 good architecture or readability or
00:20:21.600 uh name name name any any other thing but
00:20:27.440 truth um
00:20:34.080 it emerges from listening to the real stories uh one might say that truth is a
00:20:42.799 ve word when talking about software architecture we typically the closest we
00:20:48.880 get is like uh whether our mental model much the expectation of a customer or
00:20:55.240 something like that hiding behind the big words but uh in my persuasion is
00:21:04.760 that on an intuitive level all our principles and methodologies are
00:21:10.520 introduced as a way to search for some truth like objectoriented programming
00:21:19.080 was invented in simpler times in a hope that we can like model the whole whole
00:21:24.760 world in uh in objects that correspond to
00:21:30.320 every concept we we know like Behavior driv driven development was introduced
00:21:37.279 as a way to honestly try to code the requirements to some software before
00:21:44.720 even trying to implement it and so on and so on and so on our problem is we
00:21:50.600 turn any good and imprecise idea and uh each of those are good when when
00:21:58.720 they are imprecise when they are Inspirations when they are ideas but we
00:22:07.960 take them and turn them into disciplines we formalize them we and eventually then
00:22:15.880 uh instead of trying to truthfully mirror the problem to code we replace it
00:22:21.600 with just rigorously following some rules we invented for ourselves
00:22:28.799 uh as a small example uh Rubes Community once leveraged the languages
00:22:34.440 expressiveness to invent an incredibly powerful testing DSL
00:22:40.240 named but then eventually the same Community persuad itself that test shouldn't be expressive that they should
00:22:48.039 follow some rules of the most primitive code possible there are many recommendations like that on the
00:22:54.679 internet as a consequence many rubyists are taught to write tests that are
00:23:00.120 moreable that the coded tests sometimes orders of magnitude more BS and they
00:23:06.200 hate it rightfully and are forbidden from even dreaming uh that of thinking
00:23:13.840 it could be another way but well it actually
00:23:19.400 could whether you like this example or hate it and I know
00:23:30.960 uh but I really hope that you can see at least uh that my one point here that uh
00:23:38.679 this example is telling the story of expected Behavior telling it uh clearly
00:23:45.279 and truthfully and uh attempt to make it work how we want to write it also
00:23:52.600 illustrat the effect of Storytelling approach has on uh the the
00:23:59.120 we use because to make it work you'll need a new uh high level obstructions
00:24:04.919 like new matcher create record which uh is nonstandard uh and uh once Define it
00:24:12.600 they help to make many other tests more expressive and uh more clearly explain
00:24:20.480 explaining the intention but it is a well-known fact
00:24:26.120 that approaches like this frequently meet with a fierce push back and here
00:24:32.240 lies my six thing uh trying to stick to true
00:24:40.159 stories might be very lonely
00:24:45.320 experience uh first of all because uh people have their big
00:24:51.600 pictures and they the first thing that they'll expect from your story is to see
00:24:57.919 how it fits in their big big picture and if it doesn't
00:25:03.279 well that's worse for you so when trying to sell the approach which focuses on
00:25:10.200 what's really going on in the code on telling stories on trying to to express
00:25:15.840 uh a lot in screen of code beat on code reviews on PIR programming or discussing
00:25:23.240 style guides one might meet the reactions ranging from Total indifference to uh active h
00:25:31.399 hostility uh like uh best best case you are trying to explain why some something
00:25:39.640 is better to write in this one line instead of those 10 lines and somebody
00:25:45.960 will tell that that doesn't matter my my code Works let's match it
00:25:53.799 and worth thing that there would be a hug discussion somewhere on redit that
00:26:01.480 this code is not friendly for noes or something like that uh the reason I
00:26:09.080 believe is uh that looking for truth is about
00:26:14.919 adjusting your mental models constantly and questioning your experience and
00:26:21.240 expertise and in general people and especially established professionals and
00:26:27.240 especially especially software developers they aren up to uh challenging their own mental models uh
00:26:35.240 uh I mean we might change tools every day or even Frameworks but if you have
00:26:42.760 some persuasion from maybe even from it school about some some way of writing
00:26:51.120 code when uh or some small habit when it is challenged you you are not not up to to
00:26:59.720 listening uh one might notice that L lately in uh industry there is a lot of strong
00:27:08.679 sentiment against smart code expressiveness in general expressive
00:27:14.360 languages or broader about unimportance of uh any particular ways of the writing
00:27:20.799 code because we are all here like grownup professionals and all Business
00:27:26.360 Solutions and architecture and such stuff uh and there's an offspring of it
00:27:33.640 that I want to touch there is uh lately a strong sentiment against uh code
00:27:39.760 reviewing practice like I get it I do uh in
00:27:45.360 general while solving problems people prefer to uh write not to uh read a lot
00:27:52.559 or EDI in what's uh already written so this this leads to a set state of things
00:28:01.440 when the uh s s and useful practice of code review turns
00:28:08.519 into uh some laborious formal duty for both participants and nobody knows how
00:28:17.640 exactly it should be handled should we discuss the code should not should we
00:28:24.640 not discuss the code should we only um stick to to obvious bugs or should we
00:28:31.960 discuss every comma or what and eventually it is badmouthed as a harmful
00:28:39.000 meaningful meaningless uh way to waste time and establish dominance and let's
00:28:45.159 uh trust each other and uh just manage to master but in my view reading and
00:28:51.720 discussing each other's code is the only way to make sure the story you are
00:28:58.440 telling makes sense to others uh that it doesn't contradict
00:29:03.760 other stories that it doesn't misuse a commus uh to say things that shouldn't
00:29:11.000 be said this way or just just simply un true even if they uh look uh like
00:29:17.960 architectural sound this is uh code reviewing And
00:29:23.960 discussing code and thinking about how to uh Express oneself in code I believe
00:29:30.679 this is a deeply Humane activity and uh nobody will persuade me otherwise which
00:29:38.600 lead me to my last Point kind of uh sentimental
00:29:45.399 one the last point is uh we should never give up seeking Truth uh however
00:29:54.039 uncomfortable it is uh we should search for knowledge we
00:29:59.279 should constantly adjust our worldview uh if uh new knowledge
00:30:06.200 contradicts it we should ask we should rewrite outdated code and uh not grow
00:30:13.200 fond of Concepts that um turn out to be
00:30:19.000 not that useful we should drop faulty hypothesis and of how unreliable
00:30:26.200 Foundation software auor is first of all a writer and that is also a thing I'm
00:30:35.120 deeply assured of and they person that uh uh
00:30:41.799 ideally stands upright and says that's what I know for now and uh that's my
00:30:48.440 best attempt to explain it having this stance prefering it to anything else to
00:30:54.640 hiding behind terms and Concepts and Authority it is an invaluable quality for
00:31:02.600 long-term project success or basically for any
00:31:08.200 long-term uh human activity success this is the most important thing I learned
00:31:14.880 probably not much for a career this long but that's why I stand personally and
00:31:25.120 professionally thank you I hope hope to see you all in person one day and please
00:31:32.639 even if you not remember this talk uh remember to help Ukraine thank you
Victor Shepelev
@zverok
Explore all talks recorded at EuRuKo 2024
+39