Elisabeth Greenbaum Kasson asked me recently for advice on working with legacy applications. Check out her piece on it. Here’s the full reply I sent to her in email: Her topics: - The steps someone could take to get themselves up to speed on their employer’s legacy software. - How this knowledge can make them indispensable (I know that term is relative) - Why this type of expertise is so necessary, especially when it comes to integrating said software with new and/or evolving products.

tl;dr Recently, I’ve been in conversations where people throw some doubt on DRY. In the cloud native, microservices mode of operating where independent teams are chugging along, mostly decoupled from other teams, duplicating code and functionality tends to come more naturally, even necessarily. And the benefits of DRY (reuse and reducing bugs/inconstancy from multiple implementation of the same thing), theoretically, no longer are more valuable than the effort put into DRYing off.

A kingmaker in the making. I’ve talked with an old colleague about pitching a developer-based strategy recently. They’re trying to convince their management chain to pay attention to developers to move their infrastructure sales. There’s a huge amount of “proof” an arguments you can make to do this, but my experience in these kinds of projects has taught me that, eventually, the executive in charge just has to take a leap of faith.

Hey, I’ve not only seen this movie before, I did some script treatments: Chief Executive Officer John Chambers is aggressively pursuing software takeovers as he seeks to turn a company once known for Internet plumbing products such as routers into the world’s No. 1 information-technology company. … Cisco is primarily targeting developers of security, data-analysis and collaboration tools, as well as cloud-related technology, Chambers said in an interview last month.

This post is pretty old and possibly out of date. There’s an updated version of it in my book, Monolithic Transformation. In contrast to the way traditional organizations operate, cloud native enterprises are typically comprised of self-motivated and directed teams. This reduces the amount of time it takes to make decisions, deploy code, and see if the results helped move the needle. More than just focusing on speed of decision making and execution, building up these intrinsically motivatedteams helps spark creativity, fueling innovative thinking.

Satisfying the mythical auditors is often one of the first barriers to spreading DevOps initiatives more widely inside an organization. While these process-driven barriers can be annoying and onerous, once you follow the DevOps tradition of empathetic inclusion — being all “one team” — they can not only stop slowing you down but actually help the overall quality of the product. Indeed, the very reason these audit checks were introduced in the first place was to ensure overall quality of the software and business.

Working at home, with a family, is a challenge, as this nice overview piece at The Register goes over. You think you’re trading all those interruptions from co-workers talking about the sportsball or just complaining about the daily grind, but you’re actually trading in for a different set of co-workers, your family. And their requests for your attention are harder to stonewall than chatty cube-mates. And then there’s the whole “out of site, out of mind” effect with management at work.

There’s just as much pull for DevOps in government as there is in the private sector. While most of our focus around adoption is on how businesses can and are using DevOps and continuous delivery, supported by cloud, to create better software, many government agencies are in the same position and would benefit greatly from figuring out how to apply DevOps in their organizations. Just 13% of respondents in a recent MeriTalk/Accenture survey of 152 US Federal IT managers believed they could “develop and deploy new systems as fast as the mission requires.

I’m always wanting to do a talk or write a series of items on the white-collar toolchain, or surviving in big companies. Here’s one principal about presentations in corporate settings. Slides must stand on their own Much presentation wisdom of late has revolved around the actual event of a speaker talking, giving the presentation. In a corporate setting, the actual delivery of the presentation is not the primary purpose of a presentation.

Donkey teamwork What’s the point of it all? Why are we doing this? These questions pop up frequently in IT teams where the reason for doing your daily activities — like churning through tickets, whizzing up builds, or “doing the DevOps” — seems only that someone, somewhere told you to do it. If you’re in this situation — you have no idea how your activities are helping your organization make money — you should stop and find out quickly what your company’s goals and strategies are to make sure you’re not wasting time.