Month: March 2017

You Should be Good at One Non-Engineering Discipline

I have a theory that the best software developers are also really good at some discipline that involves putting things together that is tangible. By ‘tangible’, I mean that software engineering generally involves resources that you can’t actually hold, like time or code or computation. It’s much harder to understand consequences when all your problems are abstract.

So take, for example, cooking. If you wanted to prepare the following meal for your family:

  • Pasta with home-made tomato sauce
  • Chicken, marinated for over 30 minutes
  • A simple salad

and the goal was to have dinner ready at 7, with each of the 3 parts done at the same time, so that the hot dishes were hot and the kids got to bed on time, you need a pretty complex project plan. It doesn’t have a lot of elements, but it does have a lot of parallelism and mode switches, plus some dependencies. Continue reading “You Should be Good at One Non-Engineering Discipline”

Possible But Not Practical

I recently was working on a project and got in one of those discussions where I was not communicating at all. I was trying simultaneously arguing that the software was something I could build, but one that would not work. I felt pretty confident in my abilities to build and deliver it, and, in fact, that it would be pretty cool once built.

However, I was also trying to indicate that because of its complexity, it would have the characteristics of an unstable nuclear isotope – it would not last long. The system in question wold require so much more human intervention to keep it correct than was available within the organization that every month of operation would put it further and further out of true. It was ‘Possible, but not Practical’. Continue reading “Possible But Not Practical”

The Incident Pit

I’ve been reading Alastair Reynolds‘ work since I stumbled upon his short story ‘Galactic North’ in an anthology in 2000. His work is awesome and interesting, and one thing that has stuck with me as an engineer is the idea of an ‘Incident Pit’ from Pushing Ice.

When I went back and googled it, it turns out that this concept has a whole wikipedia page about it (albeit a short one). It’s worth checking out. TL;DR: it’s when a project or scenario’s incidence of errors begins to rise faster than they can be handled. It’s based in diving, where there are constant errors, and if an inflection point occurs, and error rates grow too fast, fatal mistakes can happen. Continue reading “The Incident Pit”

Vertical Integration

One of the coolest things about Tesla’s business, apart from its success and all that, is the use of vertical integration. Elon Musk does this as well with SpaceX. I think software engineers have a lot to learn from this. We have a tendency to specialize, and it leads to inefficiencies in what we do.

One area of interest here is Development Operations. A common case with DevOps is that the DevOps technicians are shared resources, and developers sort of shrug and assume someone else will set up the Web server, security, load balancers, etc., and DevOps in turn assumes that the developer has taken these same things into account as they wrote their software.

Increasingly granular models of SDLC, which have moved to digestible ‘stories’, have further moved the developer away from the infrastructure and servers. Continue reading “Vertical Integration”

Good Metaphors

When I started a job a few years ago, I was assigned to a project on a Marine Base. There was one member currently on the team as it was undergoing  staffing transition, and he had perhaps the best and most memorable welcome I have ever received, which was a great example of good metaphors in IT.

He said something along the lines of: “We have only one rule here, and it was said best by the Rock: Know your role and shut your mouth.” Continue reading “Good Metaphors”

Bad Metaphors

Several years ago, I left a dinner table of colleagues wishing a question had gone unasked. We were having dinner before a big release which included a major migration for a business unit, and a product manager said something like ‘This is like the night before the big game to you guys, right?”

I sat upright, and launched into, what was, to me, an impassioned motivational speech about comparing a multi-year software project’s final deployment to a game where the likelihood of success stood around 50%. I think it’s very important to keep in mind that modern engineering requires at least a 90% delivery probability, if not 100%. Sports is a competition whose mechanics can be good metaphor, but whose outcomes probably can’t. Continue reading “Bad Metaphors”

A Quantum of Programming

As I’ve worked through almost two decades as a software developer, I’ve often wondered about the relationship between time and features. Basically, should the ‘explainability’ of a feature be proportional to its time to develop. I think it should. This can be generalized as: A small feature should take a small time to develop.

In physics, a quantum is the smallest divisible amount of energy that a thing can have. In software, I think that a ‘Quantum of Programming’ is the smallest unit of work that is actually a piece of usable software. Continue reading “A Quantum of Programming”

Welcome. A blog has to start somewhere

Welcome to my Blog. After years of considering it, I’ve decided to put together a site that allows me to jot down my various musings and ideas about my profession. I hope that I can help someone out somewhere, and that maybe I have some original ideas to contribute.

My main interests here are not technology per se, but but to be a good manager, build good teams, and then replicate this, so that one can continue to deliver good software and engineering over the course of a career.