The challenges of DevOps--a cultural change, learning new technologies, and making a big-picture impact for a software project team--are possibly even more challenging in contract work. In this blog post, I'll expand on some of my past experiences as a contract software developer and discuss, in retrospect, how DevOps could have worked in different scenarios.

In my experience as a contractor and sometimes remote employee, I often would daydream about early, productive planning sessions where somebody in operations and somebody on the security team and myself, a developer, would whiteboard a great system. And then, when that's all been documented and everyone is on board, we work toward our goal within a well-defined feedback loop, continuously integrating and testing. Then I would wake up and realize that there was no way I could ever achieve this level of process being a temporary member of the staff. After all, the company was set in its ways, and what difference could I make anyway? I might as well resign myself to the established organization and get the job done as well--and as quickly--as I could.

The problem with the kind of attitude I had as a contractor was that I was ignoring my own needs as a developer. Yes, an organization can wall-off its teams and still produce a decent piece of software. But how reliable and secure is it? How well do the teams meet deadlines? How frustrated are the people on those teams during the development process? And doesn't my satisfaction with my work environment matter?

Companies contract with development or technical talent often to help wrap up a project that is overdue. In such cases, there may not be much hope for a successful DevOps revolution. Contractors are there to get a job done as quickly as possible and get out. But shouldn't DevOps make it faster? At first glance, one would think so; however in DevOps, the delivery time is saved by tackling operations concerns early so that the actual release is seamless and implementing automation early so that continuous integration is possible without slowing down development. The key word here is early. Late in the project, especially when the staff is panicked (the reason you were contracted in the first place), trying to plan the release or introduce new technology will only divert resources from where they are most desperately needed: on the front lines of development.

If your contract brings you into the project at an early stage, however, you could have a positive impact on the process. Let's first take the case of a larger, more structured organization. Your primary challenge is unfamiliarity with the people and the processes that they are already used to. You're still hired talent, and unless you are a consultant that is expected to bring about change, your job is probably just to get the work done and get out. Similarly, if you are in a junior role, it will be harder to break out of your development duties to convince your senior co-workers, let alone management, that it's worth the risk to expend effort doing things like setting up continuous integration, testing, and delivery.

This is not to say your DevOps dream can't be realized as a contractor at a large company. After all, this will be your working environment for the next six to 12 months, possibly longer, so it makes sense to invest the energy. If you do find yourself in the early stages of a project in a senior or consulting role, it's worth pushing for what you feel is important. Stress the need for early involvement with operations, offer to host a brown bag presentation or two to introduce the technologies you're familiar with, and expect to take on the brunt of the extra work that's going to be required to transition the environment. It's also worth your time at the water cooler to get a sense of what DevOps concepts your coworkers might already be keen on and tap those resources in your quest for change. As long as the project stays on track, a reasonable management staff will support your efforts, and your coworkers will be grateful for the benefits.

The most return you'll see in introducing DevOps comes from getting into a project at the beginning in a small organization. Small or start-up organizations, especially ones in non-technical domains (such as politics or even healthcare), are often low on technical resources, in which case they are relying on your expertise. While this is closer to an ideal situation for DevOps involvement due to the high level of autonomy you'll likely have, it still comes with many challenges. Foremost on the list is getting everyone else past the misconceptions of what your job actually is. Without an in-house technical presence, smaller organizations are sometimes used to tasking non-technical people with requirements gathering, crafting project timelines, and even designing the user interface and creating wireframes, thinking that the developer only needs to be involved when it comes time to write code, and worse yet, not accounting for an IT operations role at all. These misconceptions are sometimes tough to correct, as it could easily degrade to stepping on toes and disrupting a delicate balance of work. Another way to educate your team in the scope of your responsibilities is to host a lunch-and-learn session about the expertise you can provide. This can sometimes serve as a polite nudge in the right direction.

Note that you may not be able to evangelize DevOps immediately at a start-up. While the magical and exciting start-up atmosphere engenders innovation, the budget and schedule will likely be tight, and there can be pressure to stick to the plan. Things like automation, continuous integration, and feedback loops may not be seen as relevant or even welcome. In this case, if you are the technical lead and wearing many hats, the best course of action may be to do your job the way you know it should be done and follow through. Don't muddy office conversation with philosophy, but rather express your priorities nonverbally by driving daily stand-ups, taking the time you need to set up automated configuration and deployment, and publishing documentation for all of it. Because DevOps works, the team's attitude toward software development will gradually shift away from the approach of simply coding to meet requirements and coming back when it's done to an expectation of needing everyone at the table to discuss the next feature rollout.

Overall, the objective of a DevOps-driven contract worker is to be consistent with the philosophy. Being practical about where change can be most effective and continuing to set a good example--even in the face of resistance--can yield great results.