Your Code Base as a Crime Scene

The objective of the board game Cluedo is to deduce how, where, and by whom the victim was murdered based on clues gathered from the other players. Was it Colonel Mustard with the spanner in the Conservatory? Or perhaps Mrs. White with the candlestick in the Lounge? Use your deductive powers to ask the right questions, gather the facts, and determine the answers before anyone else and win the game.

An objective look at your code base should find a multitude of problems: lost architectural vision, questionable code structure, security through obscurity, undeleted dead code, inconsistent coding paradigms, copy-pasted code updated inconsistently, and much more! Instead of looking at the current state, let's look at he journey. Was it the sleep-deprived engineer at home with an misunderstood Stack Overflow answer, the Product Manger making unreasonable commitments on-site, or the non-technical leader making a technical decision? Or all of the above? The reasons are distributed throughout the organization with plenty of blame to distribute.

Join me for a fun discussion about possible triggers that started the decline of your code quality and what actions you, as the engineer, can take to protect the code and yourself!

Data Modeling for Software Engineers

Really, data modeling? Is that even a thing any more?

The days of formal data modeling are definitely years in the rearview mirror, empowered teams define their data as they see fit, implement, and move on. Done. And we'll deal with short-comings down the road when they arise, that's Agile, let's keep moving forward (to data architects' frustration when trying to make sense of it all after the fact).

But "modeling data" extends beyond what is persisted in a database server: API Payloads, messages, configuration files, document metadata, Redis indexes are forms of data we define and work with regularly.

If I've got your attention, join me to discuss data modeling, this time from a software engineering perspective!

Demonolith the Monolith? Think Again!

Mature organizations often have that all-encompassing, business-critical application that represents person-decades of effort. It likely started as a very well-defined, well-implemented solution to original business requirements, but over time became a behemoth as functionality was added without considering the overall impact.

Unsurprisingly, the application has not aged well and eventually leadership admits there are problems:

* consistently increasing production bugs that require immediate attention;
* dramatic increase in time required to deliver new features;
reliance on key individuals to do critical work due to cognitive complexity;
* inability to successfully monitor application to understand its true state.

Legitimately, organizations are loathe to accept that a rewrite is required; it's often interpreted as engineers wanting to do engineering for engineering's sake. Leadership makes a call to action to find a less-costly and more timely solution. After much analysis, discussion, deliberations and hand-wringing, it's decided: Demonolith the Monolith!

presented at DevoxxUK, Devoxx Morocco, and BuildStuff, as well as non-public forums.