GraphQL is awesome. You probably should not use it.

GraphQL is awesome. You probably should not use it.

This blog post is all about: how developers get lured by shiny wrapping, what kind of problems can be solved by GraphQL, what are the basic ways to solve problems GraphQL in fact can't solve. We had so many "silver bullets" in the software craftsmanship industry recently - some aimed to insta-boost the productivity, others to make the scalability-related problems evaporate like a bad dream - sadly, none of them truly made that difference, but we (as engineers) are still being naive enough to keep falling into very similar traps ...One of the newest kid on this is named GraphQL.…

Read More

FixIt: moving your issue tracker & review comments to code

FixIt: moving your issue tracker & review comments to code

TL;DR Architecture should be kept as close to code as possible, same applies to docs - otherwise they are a subject of near instantaneous entropy. But what about possible items to be fixed - differences between architectural vision & actual implementation, possible deviations from agreed conventions. My proposal is to keep them out of ticketing system & use code-level metadata instead. Treating such an incident as another semantic construct provides certain qualities, makes it harder to omit (keep omitting ...) the issue & possibly shortens the feedback loop. Disclaimer: all examples below are in C# and Powershell. Few days ago…

Read More

The way User Stories (may) strangle the Design

The way User Stories (may) strangle the Design

TL;DR Decomposition of functional requirements into atomic User Stories doesn't mean that activity of elaborate design is redundant - there's always a need of shaping the system's conceptual model: usually at various levels of detail (for different reader categories) & taking into account both static and dynamic perspective. Modern design is not sequential, but continuous and likely more flexible in terms of form, but letting it "just emerge" from context-less User Story implementations is a grave mistake. On several occasions I've criticized the way "lowly conscious" applying of Agile methods (w/o truly embracing Agile…

Read More

Frustrations of a Software Architect

Frustrations of a Software Architect

TL;DR Being a Software Architect is not a Super Senior Developer role, in fact its both leadership & management (these two are not the same) role that should act in parallel (& independently!) to other management dimensions (e.g. product, engineering or project). Based on my personal experience, the proper equilibrium between different dimensions of accountability & leadership (including Architecture) has a tremendous impact on achieving a long term success in Software Engineering-powered business. Sadly, it's Architecture that can be ruled out of the equation most easily & subtly - frequently in a way that renders Architect(s) powerless…

Read More

In caching we (naively) trust

In caching we (naively) trust

TL;DR Solution that are both quick & easy to apply are usually a clear win, but in case of using cache to "fix" performance issues it may get really deceptive. Cache is a good tool (if applied correctly), but the concept of caching scales very poorly with increasing both distribution & domain complexity, UNLESS you follow some very basic rules that may be very restrictive, but help with saving the composition & state coherence within the system. One can divide software systems into two performance-related categories: ones for which performance is not only absolutely crucial, but also…

Read More

Archicrapture: diagrams that illustrate nothing

Archicrapture: diagrams that illustrate nothing

TL;DR Some time ago I've declared my little, private war ... War against misleading, illogical & inconsistent depicting of solution architecture by people who either intentionally or due to their ignorance mix simple (yet very different) concepts i.a.: logical view, physical view, functional view. This is the post about this warfare ... I believe many of you (the ones who work in large enterprise environments) have seem diagrams like this: I've forged this one, of course. The ones you've seen may look a bit different, but I'm sure you recall the general idea of half-random clusterfuck of different size boxes…

Read More

Architecture in the Wild: Business Process Orchestration - part II

Architecture in the Wild: Business Process Orchestration - part II

Part I can be found here. TL;DR - maybe thinking in "processes" is a relic of traditional, policy-driven, hierarchical enterprise? Decentralised model, based on business events & reactions tends to have some advantages & seems to match modern architecture principles better. WHAT IF we ditch BPM completely? Is there a better way? There are at least few scenarios that seem to fit modern principles of software architecture significantly better than classic BPM: API gateway with domain-driven API, orchestrating particular microservices - in such a scenario all the interactions are dispatched & controlled via orchestrator(s), that effectively…

Read More

Wiping the tech debt out with immutable code

Wiping the tech debt out with immutable code

Disclaimer: the idea of immutable code ain't mine - I've read/heard about it somewhere (can't recall precisely ;/) some time ago & it sticked with me. Code maintenance is already a huge problem & it won't get any better by itself. Software is everywhere - even mundane, basic everyday tools get "digital" & ... flawed. Two, three years ago I was encountering bugs (in software I use) occasionally (well, except of Windows itself ;>), now it's a daily bread'n'butter - I don't even have patience to report them. Bad news is that not only many new ones appear, but…

Read More