Pragmatism now rules in team structure, technology, engineering practices, and operational innovation.
Ancient history in computer science (2004) provides a gem about the personas that Microsoft envisioned as users of the development environment Visual Studio. They developed three:
- Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems. He focuses on productivity and learns as needed.
- Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learning while working on the solution.
- Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem and typically learns in advance before working on the solution.
These designations received a lot of negative press, particularly around the Mort persona, but I want to focus on Einstein and Elvis.
Formerly, software architects exemplified the Einstein persona: isolated from day-to-day development details, focused on building abstractions and frameworks. The isolation is so common that it spawned its own “Ivory Tower Architect” derogatory phrase. But the realities of building systems that scale as fast as the business does invalidates that approach. Now, Elvis, the pragmatic developer, has ascended to architect while simultaneously descending from the Ivory Tower. Modern architects don’t have the luxury of isolation from the gritty realities of software development today. Pragmatism now rules in team structure, technology, engineering practices, and operational innovation because:
How inclusivity, complexity, and empathy are shaping DevOps.
Over the next five years, three ideas will be central to DevOps: the need for the DevOps community to become more Inclusive; the realization that increasing Complexity of systems is the underlying reason for DevOps; and the critical role of Empathy in the growth and adoption of DevOps. Channeling John Willis, I’ll coin my own DevOps acronym, ICE, which is shorthand for Inclusivity, Complexity, Empathy.
There is a major expansion of the DevOps community underway, and it’s taking DevOps far beyond its roots in agile systems administration at “unicorn” companies (e.g., Etsy or Netflix). For instance, a significant majority (80-90%) of participants at the Ghent conference were first-time attendees, and this was also the case for many of the devopsdays in 2014 (NYC, Chicago, Minneapolis, Pittsburgh, and others). Moreover, although areas outside development and operations were still underrepresented, there was a more even split between developers and operations folks than at previous events. It’s also not an accident that the DevOps Enterprise conference took place the week prior to the fifth anniversary devopsdays and included talks about the DevOps journeys at large “traditional” organizations like Blackboard, Disney, GE, Macy’s, Nordstrom, Raytheon, Target, UK.gov, US DHS, and many others.
The DevOps community has always been open and inclusive, and that’s one of the reasons why in the five years since the word “DevOps” was coined, no single, widely accepted definition or practice has emerged. The lack of definition is more of a blessing than a curse, as DevOps continues to be an open conversation about ways of making our organizations better. Within the DevOps community, old-time practitioners and “newbies” have much to learn from each other.
Think your IT staff can protect you better than major cloud providers? Think again.
I just ran across Katie Fehrenbacher’s article in GigaOm that made a point I’ve been arguing (perhaps not strongly enough) for years. When you start talking to people about “the cloud,” you frequently run into a knee-jerk reaction: “Of course, the cloud isn’t secure.”
I have no idea what IT professionals who say stuff like this mean. Are they thinking about the stuff they post on Facebook? Or are they thinking about the data they’ve stored on Amazon? For me, the bottom line is: would I rather trust Amazon’s security staff, or would I rather trust some guy with some security cert that I’ve never heard of, but whom the HR department says is “qualified”? Read more…
Six months in and there is much to celebrate and plenty of work still to be done.
Implementing O'Reilly's new IT strategy is like swapping out airplane wings mid-flight. We're making considerable change, but at the same time we can't disrupt the services and projects that are already underway.
Understanding why an IT leader operates a certain way can net better results for everyone.
It can often appear there is only one type of person leading IT. That's not the case. Understanding an IT leader's motivations and needs will ultimately benefit all involved.
The best IT managers have a background in IT and general management.
Being a good IT manager is hard. Being a great business leader is harder. What separates them is not just the ability to continually and uniquely inspire, but to also be a well-informed and skilled business manager.
Federal CIO Kundra has released a 25-point plan to reform the troubled federal IT sector.
The Obama administration has proposed a 25-point strategy to reboot how the federal government purchases and uses information technology, including new consideration for startups and a "cloud first" approach to new investments.
We're embarking on a journey that will transform how we deliver and support our technology needs.
O'Reilly's new IT strategy had to consider the company's culture of innovation while introducing the right level of predictability. Too much unmanaged innovation or codified predictability would limit our ability to grow and be a recipe for IT failure.
IT strategies that can reconcile process and innovation often have positive and measurable results.
Predictability and innovation: It's the combination every IT leader needs to consider. Organizations that can reconcile these agendas have positive and measurable results, while those that can't often see lower levels of innovation.
Radical IT change starts not with technology, but with collaboration.
IT transformation must be managed in a deliberate manner. Heavy lifting is essential, but it should not be the first thing that gets done. Radical change must start with the CIO and his or her managers engaging in collaborative discussions across the business.