I’m digging through a backlog of podcasts and the gem of the day goes to SE-Radio podcast. In episode #247 they talk about DevOps and while I’ve preached and practiced DevOps for years, as mainly as common sense, the podcast did present a more reasonable argument why it works. Developers are praised and appreciated for short time to market; the number of new features they introduce and changes they make to the running system.

Get your company implementing DMARC now… During the past 5-6 years email industry efforts have been pushing the DMARC standard along. It provides the best widely supported and seemingly efficient way to - as a domain-owner - protect the domain from misuse and abuse in terms of spam and phishing attacks. As sending email has often been a wild-west, and knowing who is a valid sender of email may prove a challenge for many companies - and as most IT developers does seem to care too much about the finer details of email (and production just as bad email headers as HTML markup :-) ), implementing DMARC protection on your domain may actually be a challenge.

As a developer it seems, you always seem to strive towards producing ever more complicated code. Utilizing new frameworks, adopting an ever evolving “convention before configuration”, pushing object-oriented programming - maybe Domain Driven Development - are practices introduced, refined and explored in the quest to prove yourself as a steadily better developer with rising skills. Yet to what point? While the intricate complications may impress fellow developers, doing so often digs a hole which may be pretty hard to get out of.

Running a modern IT platform is rarely an easy nor isolated task. Most platforms consist of a fairly large number of components ranging from OS level to 3. party libraries and components added in the user interfacing layers - and adding numerous integrations does make it an interesting challenge to quickly identify and correct bugs and errors. While the system complexity does pose a challenge is surely not an impossible task, as several tools exists for most - if not all - platforms to allow instrumentation of the platform and utilize the instrumentation tools to handle the platform and identify issues quickly.

Most IT departments have the best intentions of providing the best quality, coherent solutions, yet market conditions, projects running in parallel and various constraints on budgets, resources or time, often causes what might be defined as Accidental Architecture. The easiest way to identify cases where you’ve been hit by accidental architecture is when describing your it architecture and look for the works “except” or “but not”. Typical examples include - we have a single-sign system utilized everywhere except…”, “We update all systems to current versions, but not this old system…”.