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

Why Domain Invariants are critical to build good software?

Why Domain Invariants are critical to build good software?

TL;DR All systems (according to systems theory - that means computer software, but also board game, biotope or set of objects that are subjects to the basic law of physics) have some underlying "rules of the game" as a foundation - these invariants are used to derive more specific scenarios / cases. Trying to model the system w/o learning these invariants leads to wrong understanding & shaky foundations. What is more - trying to reverse engineer them is a huge effort w/o guaranteed success. Some time ago, during a long discussion regarding different aspects of design…

Read More

Engineers' Primal Instinct: Pre-mature Generalization

Engineers' Primal Instinct: Pre-mature Generalization

TL;DR Software Engineers see world in patterns, they look for common denominators, not accepting the fact that something may be an one & only instance. That's why we sometimes end up building frameworks for single problem occurrences ("we'll gonna need it in future") or try to squish accidentally similar concepts into one, common form - ignoring the fact that Domain experts don't recognize this similarity (it has no advantage in terms of domain, it doesn't constrain real-world domain development). The proper answer is (of course) to fight off instinct of pre-mature generalization & ... duplicate. It always starts…

Read More