DevOps promises greater innovation, speed, and automation—along with a more engaged and motivated team. With this list of benefits, many organizations are working to bring DevOps to their teams. However, with all the companies jumping onboard the DevOps transformation train, there are still many cases in which the transformations fail.
I recently found myself at a Meetup where half of the attendees were from a local front-end bootcamp class. They were connecting, looking for future job prospects, and practicing their…
Remember as a child how much of your time involved play? Whether it involved Barbies, Legos, or creating an empire in your backyard based off a leaf-based currency, you were…
Incorporating DevOps into your organization is not a zero-sum game. It is a journey. And like most journeys, it can be measured. When measuring your DevOps journey, you need to show progress as well as setbacks. Additionally, it’s critical that you make sure these measurements are accurate, automated, and visible—just like your DevOps.
There’s a common misconception that’s permeated our profession: Architects don’t need to write code to do their jobs. Now, this may seem like a harmless approach. After all, writing code is what developers do. And architects should be busy with more important tasks. However, keeping architects from writing code can limit the potential of your development teams. It can also result in an architectural mess when requirements and business needs change.
We often focus on code fails. But what else have we seen and done that makes us drop our heads in shame and frustration? What else do we laugh (and cringe) at when reading code? The comments! Whether they’re redundant, unreadable, confusing, or there’s just no comments at all, we can learn a lot from failure. And to spice things up, I’m going to throw in a biking analogy. You’re not sure if that’ll work? Me neither. But let’s go on this ride together and find out.
You’re a clean coder. You use descriptive names for everything. You’ve refactored your app into a shrine of single responsibilities. Even your slightly crazy, off-the-grid uncle can follow the code. (Hi, Uncle Joe!) The app not only documents itself, it documents life. Or does it?
You were sold the promise of the cloud. The performance gains were going to make everything better. Costs would go down since you’d only be paying for the resources you were actually using. Unfortunately, when all was said and done, the cloud didn’t deliver. So where did things go wrong? Is it your app? Is it the cloud itself? Or was there something else that caused this pain?
Your application is deployed. But what does that mean for your customers and partners? Does everything work for them? And what about when things do go wrong? Are you the first to know? Or do you only know there’s a problem when your customers tell you something’s wrong? When that happens, are you able to diagnose the issue quickly?
There has been a big push lately to have enterprises focus on entrepreneurship and innovation. The Lean Startup began as a system for, well, startups. Now it's seen as an important component in the enterprise, large and small. But if you're an enterprise trying to act like a startup, where do you start? How can you capture that entrepreneurial spirit within your organization? Let's start with some basics.