The Dead

The dead? The dead… well they don’t die anymore, just slowly waste away. If they’re lucky maybe they can have a volshebnik use their dark arts or some taytakura prey to some unseen fiend to stop their body from rotting and existing in a state of agony until they break down to dust. Of course in some parts the dead that don’t die are hauled into fires and burnt, unlive, screaming and kicking until they’re nothing more then ash. What happens then? I’d sooner not know, would like to imagine that’s the end of it, but knowing this world I’d not bet on it.

Naomi Wilding,

  • Senior Student at St Authors Academy
  • Missing for 3 months.
  • Unstable family home
  • Reported delinquency
  • Body found buried in the garden.
  • Brain missing.
  • Empty cavity used as kind of plant pot for a flower.
  • Flower not previously catalogued.

Charlie Bird,

  • Junior Student at St Authors Academy
  • Missing 11 weeks
  • Part of Miss Wilding’s friendship group
  • Single parent household
  • Truent
  • Body found buried in the garden.
  • Similar state to Miss Wilding.

Hanna Smith,

  • Senior Student at St Authors Academy
  • Missing 10 weeks
  • Part of Miss Wilding’s friendship group
  • Boyfriend – also missing
  • Abusive father
  • Minor criminal record
  • Body found buried in Garden.
  • Similar state to Miss Wilding.

Jamie Collins,

  • Junior Student at St Authors Academy
  • Missing 9 weeks


“Sometimes it’s simply easier to kill”

“That’s a reasonably troubling statement”

“However that is the state of things, the world is on the brink and there’s little point in trying to justify yourself to those with a knife to your back.”

“While I can see your point you may learn a thing or two by listening to them.”

“They were letting their blade do the talking before I concluded the conversation.”

This short exchange was had between two men in a dark field while a half dozen noblemen lay dead around them.

Seeding the Stars

Fourth Generation Seed Fleets

By this point in time a Seed fleet consisted of over a hundred large ships sent in a number of waves, the first consisted of automated factories that would arrive first. The factory fleet would set about building orbital infrastructure, deconstructing asteroids and smaller orbital bodies, large scale laser network construction and the development of O’Neil cylinders.

The second wave was made up of seasoned colonists, people who had helped in the organic settlement of the solar systems worlds and environs. For all practical pueposes their ships were O’Neil cylinders that had engines to propel them through the depths of space. Generally there were four such ships with a total population of about two million people.

The final wave was more of a column of settlers looking for a home away from the Sun that had been the species home for so long, among them were AI and other virtual life.

3 Dandies

The exaggerated sniffing of the air as he strolled past them in the quadrant was a daily pitter-patter that drifted towards a young man that walked by who seemed to mind his own business.
“It’s a disgrace they let dogs in.” A blond true blooded noble snorted as he lent back against the wall waving a lavender hanky in front of his nose.
“Dog? To fine an animal, what we have here is common swine.” A dashing brown haired noble exclaimed excitedly.
“Swine swill more like.” A third red-headed boy laughed obnoxiously.
“Good day sires” the passerby bowed slightly as he moved swiftly on.
“By God, it spoke to us!” The blond chirped.
“How disgusting I must wash. Immediately!” The brunette clamoured.
“The indignity of it all!” The redhead Hollard.
The young man stopped and turned. Looked as though for a moment he was about to say something and then turned back to his walk.

Crack the Can

A pair of vast graphene cylinder spin like thousands of others, ten kilometers long, a radius of one and a half kilometers, each home to over ten million souls. Held together by a lattice framework of steel and graphene and connected to the center of each cylinder like a cotton wheel on a spool the megastructure futher surrounded by a network of solarpanels, sattelites and domes. Small vessels dart between the artificial island in space, while effortlessly orbiting the Sun.

A black cylinder which had been hidden in the shadow of a piece of tumbling ice traveling a short few dozen kilometers from the habitat sprung visibly to life. A blaring thermal signature, monstrous acceleration, cargo doors silently slide open and vast metalic gods ready to hurl themselves into space.

“Hey, Charlie?” Tariq the sensor operator asked sounding a bit bewildered.
“What’s up” Charlie was stood on the ceiling reading an inventory log.
“I’ve got a massive heat spike coming from that rock we indexed for a fly by.” Tariq prodded some buttons.
“That doesn’t sound kosher, got visuals?”
“Just getting some along with a full scan.”
Charlie spun to face one of the larger monitors as the image came in, black on black, but the light from the sun barely reflected off the surface. “What the fuck” he mouthed.
“This ain’t no cargo hauler in a rush.”
“Analysis of object would indicate a space craft, given its behaviour I would suspect it’s hostile.” The ships AI chimed in. “Activating collison defenceses.”
“Tariq, Raise the island, get them to the emergency shelters!”
“Ahead of you already.”
“Unauthorised systems access at outer docking doors.” The AI added.
“Got a visual feed?” Charlie looked out across docking can which the nest protruded into. Metrics and messages streamed across the inteligent glass as claxons howled.
Four large stealth black combat mechs were attached to the outside of the cans hull. “Combat sleeves.”
“Why aren’t they reacting to the drones?”
“I guess they don’t care.”
Tariq looked across at Charlie “I guess that ain’t good”
“You’d guess right”
The docking bay began to open, and as it did a small cylindrical object began to float into the docking can. They stared for a moment.
“Holy shit, get down and cover your fucking eyes!” Tariq screamed as he dove to the ground. Charlie a moment behind. The light so bright that even with face buried on the floor it was as bright as day. An elecromagnetic pulse rippled from docking can and through the habitats destroying all electrics.

“This is Diver one, package delivered, moving to collect the prize.” A womans voice oveer the intercom moved her armoured combat sleeve through the docking can outer door and into the sea of blackness the other sleeves following in, maintaining firing archs and vision.

“This is Diver three, Scan shows the package did the work, controls on their reactors are scrubbed and the whole thing has shutdown.” A male from the recon sleeve.

“Pop the can Diver two, we need into cylinder two.” Diver one directed. She looked across at the nest, two thermals, she lifted her snub cannon and pulled the trigger, no thermals.

“This is Diver Two, Confirmed”

“Diver three, make sure we’re ghosts.”

“This is Diver Three, On it Diver one”


Again I find myself contemplating the problem with setting IT organisations on the “right path” with regards to transformation. It almost seems that out of politeness and I suppose an obligation to some pretence created before my arrival. There is a common pattern to the “Digital transformation” get in some tools, an issue tracking system, a continuous integration platform, maybe some kind of orchestration, a version control system, etc… normally these will all be the “likely suspects.”   

At some point, someone will say something like “I feel we’re creating solutions for the unknown” at which point I will look at them somewhat at a loss for words. Not because I disagree but because I deeply understand that they are likely right, it isn’t very smart to go “yes I know, but this is what the organisation has asked for and as such that’s more or less what we’re going to do.” What would I do for most of these organisations if given carte blanch? Firstly I wouldn’t set about putting in place tools until we had to, remember “Do just enough so that you can get started.” I suppose I take the most issue with the process and management side of the whole thing. Version control is likely the only thing that’s a no-brainer you go with some flavour of hosted git, which one? I don’t really care.

The last thing I’d ever commit to is a computerised issue management system whether it’s VSTS, Atlassian or Kanbanize, why? Because that way leads to creating a “solution” that doesn’t make any sense. There will be loads of features you never use and as many that don’t fit the business and given the business doesn’t even know what it wants yet you’re in a sticky place.

By the way, I really dislike the word solution, as I tend to find that today’s solution is tomorrow’s embuggerance. I’m very much a believer in the Toyota view of “countermeasures” this is what we’re doing until we find a better way of doing it and we will constantly challenge ourselves with finding a better way of doing this.

So I would say the best thing is to stick to using sticky notes, large bits of paper, whiteboards, bits of string, felt tip pens, and A3 reports. I’d suggest talking every day and changing things every week or so. Engender PDCA and robust problem-solving methodology. Then maybe after six months or a year, you’ll be ready to commit the current state to a computer system of your design. Don’t buy COTS as it’ll have lots of things you don’t want and it will lack lots of things you do want. You can use the time saved by your new processes to do this development work if you do go for a standard packaged piece of software look for the one that sets the least level of constraints. You can’t trust that a third party piece of software won’t do something your company can’t accept.

I honestly think that this would drive far better practice and adoption in almost all organisations. Though we wouldn’t get to deliver nicely packaged “solutions.”

DevOps, Technical Principle or Institutional Discipline?

Work In Progress

DevOps as a term is seen to have emerged after a 2009 Velocity conference where John Allspaw and Paul Hammond gave their “10 Deploys per day: Dev and Ops Cooperation at Flickr” presentation. During which they described how they created shared goals between Dev and Ops to make deployment a part of everybody’s day job.

Later that year Patrick Debois excited by the idea went on to create the first DevOpsDay in Belgium where the term “DevOps” was born.

Source “DevOps Handbook p. 5” 

The DevOps and I

“To know where we’re going, we need to know from where we came”

I have no idea when I first came across the empty vessel widely referred to as devops but likely it was a couple of years after it’s inception as a thing over at “el Reg” and no doubt like many people from a technical operations and production support background I looked at it with something akin to dejection. “Another word to add to the lingo bingo of tech talk,” I thought. On the surface, the language used to describe devops function tends to revolve around the web, Greenfield deployments and startup ventures with nothing much to offer the enterprise. 10s (at the time) of deployments a day, globally distributed presence at a flick of a switch, self-service for developers so on and so forth, wicked but can you get Jenny in systems her new laptop on time and will the bacs system be up for payroll run? Can you tell me anything about how we get this monolithic java enterprise app running? No? Ah well.

Another thing about these early years of mine and no doubt others exposure to the concept of devops was that a lot of it sounded like things we already did, using scripts to provision resources, having monitoring systems perform self-healing, trying to help developers with their local environment builds. Nothing I’d heard coming out of the devops space seemed like it wanted to solve these problems in an enterprise or legacy setting, often hand waving and the “let devs run wild on production” which would make most operations peoples blood run cold.  Now many of us are no fools, we know that if we get the dev some level of read access or a way to aggregate logs to them it’ll speed up resolution of issues, but actual production access is concerning on a number of levels particularly if you’ve been in the game for a number of decades. We’ve all had similar conversations to the below

Dev "It works on my local system"
Ops "But you don't run firewalls and everything is on the same system"
Dev "Sure it's quicker that way and it works"
Ops "You're supposed to use the test environment"
Dev "That things always broke, I raised a ticket a month ago to get it fixed"

As the years went by and nothing particularly insightful came on the overall principles around devops a number of really useful tools and concepts started to emerge namely central configuration management tools like puppet and chef allowing for “Infrastructure as code” and the idea of Test Driven Infrastructure. From an operations point of viewpoint, these technologies and ideas helped solve real problems and were a successor to the system administrators toolbox of bash, perl and powershell scripts operations had since the Unix days.

Roll forward again and everyone is talking about bots, and I get interested so go off to do a quick Microsoft academy session on bots as the framework had just come out and they recommended two books, “The Lean Enterprise” and “The Devops Handbook” okay I’ll bite. It may have been about azure container services actually, anyway if you’re bored I’d suggest going to have a look at the Microsoft academy it’s pretty good.

And Lo There were Principles!

Page XIV of the DevOps handbook preface, the following two and a half pages lay out the devops myths that permeated most of the blogs, consultants, management speak and, readily available online discussion I had encountered to that point.

“DevOps is only for startups”
“DevOps is incompatible with ITIL”
“DevOps is incompatible with security and regulatory compliance”
“DevOps means eliminating IT Operations”
“DevOps is just infrastructure as code”

There were two others but these were some of my main areas of interest, then the book in quick succession moves onto its introduction “Imagine a World Where Dev and Ops Become DevOps” the very first paragraph asking you to imagine a world where all the various main roles in the delivery of IT services to the customer all work together, not just to help each other out, but towards overarching organisational goals! Holy Mother I’m holding dynamite I thought, it then goes on to explain the IT Death Spiral (I’ll dive into these later) and I’m just going “Yep, I know this, I’ve seen this, are they in my office?” Of course, they weren’t it’s simply that the same story is being played out in organisations around the world all the time there are likely hundreds of thousands of organisations spiralling the drain as I write. I didn’t get much further into the book at that point but I came away with two things.
Number One, for the first time in well I can’t really say it felt like I had had an epiphany. This could really change things, for everyone, forever!
Number Two, I had to read more, I immediately picked up the Pheonix Project (a novel about a fictional organisation that finds DevOps) and Toyota Kata. Why Toyota Kata? Well because in Toyota lived the principles that the DevOps handbook and Pheonix Project alluded too.

For me, devops had become DevOps.

The Friction at the Heart of IT Services

I’ll use IT Services as a catch-all for the all-encompassing mass of an organisation’s various technology obligations including but not limited to security, projects, quality, testing, development, servicing systems that customers directly use, core and remote infrastructure, servicing systems required by end users to do their day job and generic support.

At the core of a non-DevOps organisation, there is an overwhelming friction between “development” and “operations” illustrated below

With these two major arms of the IT Service in a state of constant conflict, it’s not entirely surprising that heated confrontation is often routine and we end up in a state of cold war with the two sides often passively undermining one another.

Often a release into production becomes akin to throwing a ball over a wall… though as me and a friend in QA management often say it’s more like they polish up a turd and then throw that over the wall. But let us pretend it’s a ball.

"Development are idiots, they've shipped buggy code again!" Says Ops girl.
"Operation are idiots, they've deployed the wrong tar ball again!" Says Dev boy.

As a result of every failed release Operations add a new administrative step or an additional manual test to stop the problem from happening again while development gets dragged into trying to fix a problem they can only see in the rear glass mirror which with every new step gets smaller and smaller.  At the same time, the time that is supposed to be being used to develop the next feature is getting smaller which will lead to less testing time and increases the chance of new problems in production. Everything just keeps getting worse as pressure at both ends of the supply chain gets higher, downtime windows get longer, the frequency of releases drops, fear builds with each new deployment, fixes upon fixes, patches upon patches, bodges upon bodges, heroic firefighting from all sides, we are going down the drain faster and faster. Before you know it you’re down to two releases a year and months of planning before each one, invariably followed by months of firefighting and emergency out of order patching.

This is the conflict at the heart of most organisations IT Services and It is the source of the IT Death Spiral.

You know you’re in the death spiral if, tick as applicable:-

  • Every release is met with dread.
  • Development is producing dozens of pages of documentation detailing every tiny thing.
  • Release meetings that take hours spread over months.
  • Everybody and their grandmothers are in those meetings but rarely anyone from development or operations.
  • Operations spend weeks preparing their documentation and doing test runs.
  • Everyone is trying not to be part of the deployment team.
  • You need a deployment team!
  • Everything is done on site.
  • You do the release over a weekend (or even better, bank holiday weekend!)
  • You’ve got a change process even your auditors think is thorough.
  • The feature set of the release is likely a tenth of what it was supposed to be and you already know there are bugs in it.
  • Nobody really knows why you’re putting the release in.
  • Nobody in the business is excited or expects it to work.
  • The development cycle is shot to pieces.
  • The release window is guaranteed to overrun.

Now I’ve fallen into the old trap of only talking about releases, but I am attempting to highlight the core conflict, I shall get onto the mundane but critical items later on.

Lean and DevOps, Here to Help

Jeez, we having nightmares yet? Well, all hope is not lost!

“Start by getting the boring stuff right”

So let’s cut to the chase, in my opinion, DevOps is no more a technical skill set than the Toyota Production System is. In The Pheonix Project the first time we see the fruits of everyone’s labor is when Bill gets his laptop delivered to him, he can’t believe that his laptop could possibly have been replaced so he goes off to complain to Patty who points out that yes they’ve done all the laptops and that amazingly they can now accurately predict when they will get future laptops to users! What has this got to do with cloud deployment skills, continuous deployment or automated environment management? Nothing of course.

So what is DevOps? What do we need to reach DevOps and break the self-destructive IT death spiral?

One thing we need to do is we need to determine where we are and where we want to be. High-level organisational goals that are well understood should be by everyone and every project should be aligned with those goals this is part of understanding the current state. Once you have goals you can go through everything and check to see if it will affect those goals if it doesn’t then it should be considered for dumping. Having high-level ephemeral goal is also important for an organisation overall as it gives you a True North to align yourself towards when you’re wandering through the unknown territory that is the now.

Communication is key, break down barriers that inhibit the accurate transfer of knowledge and make sure everyone is on the same page and aligned with the organisational goals. It’s a lot easier to push a boulder if you’re all pushing from the same side.