A game-changing value of ... missing abstractions - part II

A game-changing value of ... missing abstractions - part II

The first post in the series can be found here. Last week I've presented one aspect of complexity of the transactional part of our platform - availability (when trying to book a new appointment). And what is more important, how one modelling trick has significantly reduced coupling & simplified (and distributed) business logic. Today I'll cover another aspect of the same functionality (appointments) - pricing. And again, my goal is to show you how one Eureka moment has corrected the course of our architectural direction for the whole platform (!). Baby stepsInitially our pricing logic was trivial - each service type…

Read More

A game-changing value of ... missing abstractions - part I

A game-changing value of ... missing abstractions - part I

Few months ago I've published a short article about what is a Model Debt & why it matters. Today I'd like to provide you with two nice, crispy examples that illustrate the idea. Both are coming from the Domain I currently work on with my teams - booking appointments in Beauty & Wellness industry. Booking an appointment initially was very straightforward. Apart from knowing what (particular service) you were booking & whom (which stylist) you were booking, the only challenge was to make sure that no-one has booked the same time-slot (of a given stylist). We've achieved it in the…

Read More

Unappreciated skill of visualizing the work

Unappreciated skill of visualizing the work

This blog post is all about: what can be (effectively) visualized, when visualizing works (brings benefits), what does it mean that visualization is "effective", why visualization makes a difference, why visualization is not just about sketching something that comes to your mind.One of the defining moments in each professional Software Engineer's career is when (s)he realizes her/his limitations - that (s)he can do only about as much but not more. That it's not possible to up-scale her/himself anymore & out-scaling is the only option (if one is really determined to achieve MORE). That is the…

Read More

The anatomy of a Model Debt

The anatomy of a Model Debt

This blog post is all about: the definition of what Model Debt is (& what isn't), how is it created (& why), how to avoid growing Model Debt, whether Model Debt does have anything in common with Technical Debt (& can one use technology to fix it).Disclaimer #1: I was considering writing this post for some time already (as another step in my "Fiber-Driven Development" observations), but the final "trigger" to finally give it a go was attending "Technical debt isn't technical" by Einar W. Høst (at DDD Europe 2019) - I think the author has made a tremendous…

Read More

Up for some Domain Driven Design? We can help.

Up for some Domain Driven Design? We can help.

TL;DR: We're looking for a Senior System Analyst that will fit the boots of Functional Architect role for our platform. The main challenges are all about: scaling complexity, effective (& efficient) knowledge sharing, maintaining Ubiquitous Language, cultivating Domain Model that will correspond to the technical Solution Architecture. It's a chance for everyone who'd like to practice Domain-Driven Design w/o all the typical showstoppers that usually prevent it from happening.Scaling is hard. Like really, really, really hard. And I don't really mean traffic or user-base (which ain't trivial either). It's freaking hard to scale out both: domain complexity…

Read More

DDD Europe '18: my post-conference scribblings

DDD Europe '18: my post-conference scribblings

TL;DR My expectations regarding software craftsmanship conferences are constantly evolving towards more focused & interactive events. Less novelties (one can learn from Internet on the very next day anyway), more warstories & workshops with seasoned practitioners. DDD Europe 2018 was such an event - dedicated to domain modeling & design in general, with majority of sessions in a form of hands-on workshop. I strongly encourage all people deeply involved in building software not only to learn more about Domain Driven Design in general, but also consider the participation in next year edition. Time for a change This year I've…

Read More

Could DevLyst be the next 'black'?

Could DevLyst be the next 'black'?

TL;DR Too many problems in modern software solutions development are related to chasm between 'thinkers' (analysts, people with business knowledge) & 'doers' (IT specialists, mainly programmers), yet we're so used to it we treat it as something carved in stone. Why not try to apply the same bridging concept that was foundational for coining the term 'DevOps' to mix these two worlds - software crafters with sufficient understanding (& working ability of) domain analysis & technical implementation sounds almost like a mythical silver-bullet. Barely anything in life is either black or white, we're usually navigating across various shades of…

Read More

All programming languages suck

All programming languages suck

TL;DR If maintainability & extensibility of your software are among the top priorities, readibility & easy-to-grasp correspondence to functional requirements are far more important than conciseness & technical "aesthetics" (e.g. compliance with patterns) of your code. That's why to build good solutions we need much more expressive power than what any of the programming languages (of the day) offers. At some point we believed NLP will solve this issue & we'll get there with Nth GLs. This is not the case. Instead of building more generic programming languages, we need to get better with building custom…

Read More