Introduction

2016-05-05

I am a long time Build/Release/Automation/Devops engineer. When I started doing this, it was rare to find a company that thought that this role would be worth paying somebody for, and nobody thought there was an organized engineering discipline involved. I convinced them differently by learning about Software Development Life Cycle ideas and patterns and finding ways to apply what I learned in the real world.

Over time, it has become more accepted that this is a role most software development projects will benefit from a solid practitioner of, but it's a lot like being a bass player. If you play perfectly, nobody knows you're there, but if you stop or make a mistake, the spotlight comes on you, and it's very damn hot.

There have been various currents during my time in this field, that have seriously changed how things were done:

Agile development

At heart, this is a way to get business people and developers to work out how to communicate in spite of the fact that, up to that time, they had hated and feared the people they now have to work with (not usually in such stark terms, but that was how it felt)

Continuous Integration.

The idea that, if a bunch of programmers are working on a project, it will be a good idea to build and test it frequently, so that when somebody breaks something it's still fresh in their mind. Seems obvious, now that we know how much it helps.

The cloud

It's taken longer than it probably should have to start, for the obvious reason that a business needs to be able to be confident that putting their Intellectual Property on somebody else's storage is not exposing it to theft. At this point, files in AWS are probably safer than ones in your company's in-house data center, if my experience of security practices in software firms is any indication.

Test-driven development

Also, acceptance or behavior driven development, etc: the integration of testing earlier than before in the development cycle. This has the potential to be the biggest win of all, but isn't getting as much attention as the others. Ruby has a language community around it where this is well developed, and wow, what a difference it makes. Your confidence in your product starts much higher than in traditional approaches, and then stays there while traditional approaches erode it to nothing.

Distributed version control

Actually, this is not the revolution people think it is, because for a project to be done by a bunch of developers, you have to have a central master copy, but what this does give you is much, much better branching, and some thought has been applied to this that can make things work much better than they used to.

Infrastructure as code

People have wanted to be able to define what a developer's workstation would be like in a way that could be duplicated without effort or strain, and the same for oceans of servers, and now we have Chef, and Puppet, and Ansible, and lots of other ways to make this dream come true.

Virtual machines and Containers

... like Docker. Now you can run many clean, lightweight, but perfectly sufficient environments on hardware that could never do so much before, and combine their efforts to get great results. This way lies scalability; nothing else that has come along has as much promise as this.

Functional programming

It's not all the rage now, but trust me, it will be everything. Why? Because Moore's Law. You see how CPUs stopped getting higher gigahertz rates? It's because it's not physically possible to go faster, so we are getting more cores. With Functional programming, you can use all those cores without having to do locking and other fragile, unreliable tricks. Doing that with the languages we have been using is a nightmare for even the best of us, which most of us are not.  Get used to Amdahl's law: if you divide a job up equally among 4 processors, you get 16 times more done in the same time.

There are other big waves too, but this is too much for an intro already. I will talk about these things in blog entries as I think of things to say, and I hope it will be worth doing for me, and worth reading for you.
If not, at least help yourself to random selections from my signature quote collection, http://bkhull.com:4567/quote - it's set up the way some email systems want to have a signature generator.