In a previous post, I mentioned that in order to have a successful DevOps experience, there were some key components and principles that need to be implemented. In this post, I’ll cover those components in more detail.
What I want to cover in this post is the experience that I had transitioning from a traditional development role to DevOps and what I learned to be useful in that transition. One of the nice things that I experienced with DevOps was that it pushes developers to take more ownership of their application because they are living through the pains and difficulties of running the application which in its turn pushes them to make running the app easier.
Wikipedia defines DevOps as:
DevOps (a clipped compound of “development” and “operations”) is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.
I like to simplify this definition by saying that DevOps is when you’re not only responsible for developing the application but you’re also responsible for running and supporting the application in your testing and production environments. As opposed to the traditional way of developing where you have the luxury of developing the application then throw it over the wall to the Ops team.
During my career, I’ve worked at various organizations that had different stances toward open source frameworks and tools. Some of these organizations absolutely did not want anything open source near their code base. Others had a small set of “blessed” open source frameworks we were allowed to use. Some of the better places I’ve encountered, had a process for approving and documenting the use of new open source libraries in the code base.
The reason for this is that organizations tend to recognize that using an open source library comes with a certain amount of risk. Their goal is to manage the amount of risk they are taking on while developing software. The risk of using an open source library usually stems from the license of the library.
Newton’s Third law of motion, “To every action there is always an equal and opposite reaction…” is a powerful standard in analyzing team dynamics. I have been leading agile teams for over five years. When I am asked to lead a new team I begin by looking for reactions that are disproportionate. While this may seem like a strange place to focus this is a simple way to identify significant areas of improvement.
Time and time again, I have uncovered issues that have been ignored and/or hidden by exploring “over reactions”. They are indicators that there is more to the story. For example, one of teams that I was leading was very frustrated with how much time we were spending estimating stories. Their frustration eventually culminated in some of the team members refusing to participate in team estimation meetings. As you can imagine this created significant tension between the developers and the business team.
While spending time recently looking for something new to learn that looked interesting, and it still being so close to new years, I was reminded of a bit of advice from the book “The Pragmatic Programmer,” learn a new language every year. But is learning a new language every year actually helpful?
A while back, I read blog post discussing who is the client. Software projects frequently have many different clients, many of whom are frequently underrepresented throughout the development process. Do you know who all of the clients of your application are? What can you do to make their lives easier or better? You might be excited that you’re project is converting an old green-screen application to a web application, but have you thought about the data entry staff? How long did it take for them to enter a widget through the old interface? How about with the new one? How about the people who consume the data that your application will be collecting? Will they be able to access everything they need? Don’t forget the IT staff. Will they be able to support your application?
When developing software, you need to be aware of all of the different customers you have. Even though they might not be represented in the meetings, whether or not your software satisfies their needs will determine your project’s success.
The other evening I attended a technology industry event at a somewhat-trendy bar downtown. The event was intended to foster networking between newer entrepreneurial startups and more established tech companies. I eventually found myself comparing notes with a guy I’ll call “Sam.” Sam is responsible for sales at his company and as with most sales professionals; the conversation with Sam wasn’t too difficult. He clearly wasn’t trying to confuse anyone. As I watched Sam interact with others I began to suspect that he was an expert at getting his message across with an optimal signal-to-noise ratio.
Shortly after Sam and I began speaking we were joined by another individual. I’ll call this guy “Ted”. We made introductions around and then I asked Ted what his company did. Ted seemed to struggle with his description of his business. After Ted circled the bulls eye for several minutes Sam asked him to boil his business model down to the basic value proposition. Ted seemed to struggle with this too and so Sam helped him through the short conversation with some prompting.
I found the conversation about a basic value statement interesting. Once we’d arrived at Ted’s business the conversation became less interesting. Ted began expounding the benefits of his favorite flavor of technology. Before I wandered off I heard things like “no viruses”, “lower cost of ownership” and “a true Unix operating system…”. Not much real information and not much in a message structure that I found entertaining.
Here are a few quick tips for the “Teds” out there:
- Always be ready to quickly describe your value proposition. You should practice that statement regardless of your position in the company.
- Keep the value proposition short and relatively non-technical. It doesn’t need to be so simple that Uncle Joe could understand it, unless Uncle Joe works in your industry, but it does need to be basic enough that others in your industry understand quickly, with minimum effort.
- If someone asks you what you do and you are able to respond with a concise answer then by all means also give them your contact information! Hand them your business card; provide them with a URL or something else memorable. Write that information on a matchbook, cocktail napkin or just scratch it into their forearm with your car keys. Don’t assume that someone will remember your business contact information after a casual conversation, especially if that causal environment also includes libations.
- Read your audience. Be cautious about providing too much detail unless you are confident the person you are speaking to understands your topic and wants to dive into it. There are some people I just don’t get into elevators with. Zealots are always near the top of that list.
There was a post a while back on TechRepublic about how leaders ask questions. When was the last time you asked yourself what could go wrong? What are you doing to prevent it, or minimize it’s damage?
I just got done reading Release It by Michael Nygard. I don’t remember the exact numbers he used, but he made the point that any system of sufficient size should expect to experience more than one “once in a million” situations. Assume that your system performs 1000 transactions a day, 365 days a year; after three years you will have processed over a million transactions. I don’t know about you, but saying something will happen about once every three years sounds a lot different than once in a million. So next time you’re in the car, waiting for traffic, start thinking about “what if.”
Continuous learning is a critical puzzle piece to staying competitive in today’s business world. In the IT world specifically, as we all know, the only constant is the fact that processes are changing and new processes are evolving all the time! In order to keep up with the learning curve, we must make continuous learning a high priority.
At Source Allies, continuous learning takes place in many forms including:
- Training – courses attended over the past year include: AFS & Kerberos Best Practices, No Fluff Just Stuff, Tuning and Improving your Agility and Spring One 2GX.
- Reading – Source Allies has an internal book club that meets on a weekly basis to review a specific book. Books that have been and are currently being read and reviewed include TDD by Example and Effective Java, 2nd Edition.
- Weekly meetings – each Monday, after hours, the Source Allies team meets to discuss current projects and share techologies that are being used on these projects.
- Technical presentations – team members present at least yearly on the technologies they are involved closely with.
The examples above are just a small sample of the continuous learning opportunities available to our team at Source Allies.
Continuous learning should be an important part of your career development goals. What do you want to learn? How do you want to apply what you learn at your client site and to your projects? During this time of year, many of us are reviewing our personal career goals. In doing so, make sure you identify and include your learning goals… but don’t stop there! Make sure you focus on these goals and review your progress often throughout the year.
You’ll notice that when you are focused on learning, it will not only grow your value but it also makes you more passionate about your projects and work in general. It’s easy to get in a rut if you’re not focusing on staying ahead of the learning curve.
Specific knowledge and skills become obsolete with time but learning how to and having a passion for learning is a permanent skill that will carry you throughout your career and beyond!