devopsy.kinsta.cloud

Author: Don Macvittie

  • Looking Ahead, 2023 Edition

    Looking Ahead, 2023 Edition

    DevOps is in a perpetual state of change that keeps all of us engaged and busy, but makes a mess of things overall. Do you cloud-first? Are your APIs GraphQL yet? Are you doing SDN to connect to the VPN so you can put files on the CDN and build closer to the market? Sorry, had to do it. You get the point.

    The point is that the ground is forever changing under us, and often things that seem straightforward are not. Like “cloud-native,” including Kubernetes. Yeah, I get it, you mean software-defined infrastructure that works well with infrastructure-as-code (IaC); this field is confusing enough—calling it cloud is dumb when, these days, cloud has a specific meaning in the minds of IT.

    In our current round of change, a few patterns are showing up. Automation is king. Sometimes it is sold as AI/ML because those are the buzzwords of the day, but it is just continuing the trend of automation to make IT more responsive and predictable. We are rapidly approaching a point where the entirety of the application development/deployment process can be automated reliably and configured to create predictable results. By that I mean that development has more assistance writing code, test has more assistance running tests and processing results, deployment environments can be grabbed from application release automation/orchestration tooling and the final product all of that means that builds can be deployed with very little human interaction unless something breaks.

    Highly automated systems are a prerequisite of high-volume output, though – automobile factories are the easiest example of that statement. My problem is that we don’t seem to be asking “Should we be high-volume producers?” Does the average enterprise require non-stop development? I think that the initial answer is yes, and the more considered answer is “Only because the business wants more, consistently.”

    At some point, the gains we received from DevOps need to be looked at from the “What value is added?” perspective. And that is a business function with IT input. Before SaaS and DevOps made IT easier (to get something running; not minimizing our work here), the business had to consider carefully if it needed that application or that change to an existing one. Today, that consideration is pretty much “Because we want it, put it on the backlog.” But all of our new development adds to our technical debt. While the wave of automation we have been living through since “The Pheonix Project” was first published is keeping us ahead of the curve, we will inevitably need to consider flattening the curve. I suggest that the time is now.

    Getting started with this is actually pretty easy. For many organizations, simply stating, “We do not need two ways to do that” will yield benefits quickly. Other organizations will have to ask “Why can’t we use the functionality of existing tools/apps to do that?” and yet others will need to ask the business, “Do we even need to do that?” Prioritization still exists, and management does an okay job of pushing back at all of the organizations I talk to. Still, at some point it goes beyond “prioritize your wishlist,” and IT managers will have to start asking if a project is even necessary–even if doing so makes waves.

    Continue to rock it, but we’re past time to look for redundancy, synergy and misdirection. There is more complexity coming, and more sweet solutions to problems (both known and unknown) are right around the corner. But, as I’ve said before, simplify as you go because you need to be able to handle the next wave, and eventually, automation won’t cover the gap.

  • Don’t Hire for Product Expertise

    Don’t Hire for Product Expertise

    We all know the jokes about talent recruitment that “requires a century of experience in AI/ML.” With the number of layoffs, no doubt this type of approach will get worse. But that is not generally a tech problem; it is an HR problem–the problem of having people hire in tech that aren’t active in or knowledgeable about tech.

    The real concern that is very much a tech problem is hiring for product and/or technology. I will say outright: Stop doing that except in very special circumstances. Hire for the ability to find information. One of the other things we all joke about is increasingly convoluted interviews where the hiring company wants you to solve their problems in a fraction of the time it would actually take them to do it. Again, if you’re a hiring company doing this, knock it off.

    IT is an ever-evolving field, more so once Agile and DevOps are taken into account. Indeed, we would not be far off if we renamed the field Continuous Evolution, because tomorrow is guaranteed to hold different solutions, no matter what. The idea that requiring experience in Grafana or mastery of Python is an indicator of long-term success is downright farcical. There are positions where this is tolerable–if a position is for maintenance of a traditional app that is not going anywhere and is not getting massive updates, then a list of what tools are desired for the role is easy to build and will be lasting. But I would argue that hiring specifically for that application’s needs is not in the best interest of the organization as a whole, because that person is not portable and adaptable. For modern development, particularly of new products that are just now being architected, the needs are going to change in the process, so claiming you want X years of experience in Spring (when it may use a different framework by deployment time) is not productive.

    As we move into belt-tightening yet again, employees who can do the job and know how to look up new information will be worth their weight in gold. Having a person who can work on existing applications and drive innovation in future applications all in one body is important. Giving them a chance to exercise that drive to learn is also important, but is a separate issue. None of the areas I cover–applications, operations and security–are standing still or even coming close to standing still. The need for people who can go find out what is needed is huge.

    And while the internet is a horrendous mix of good and bad, the ability to find information—and even solutions to problems—is undeniably better than it ever has been. Having people skilled at using that information resource is the key to moving forward.

    So, find people that can solve problems given a modern context. Hiring for technology will solve today’s problems, but problems are not restricted to today, so solve ongoing problems. Gate for basic tech knowledge and skills, then evaluate for the ability to find answers. A far better use of everyone’s time during interviews would be—using email as an example—“Hosted Exchange just went down. Walk me through your troubleshooting steps. You have a couple minutes.” Or—using development as an example—“We just discovered that an OSS library we use has unacceptable vulnerabilities. Walk me through how you would find instances of it and what steps you would take to find replacements. Compliance is breathing down our neck, you have a couple of minutes to show us.” You get to see how they approach likely problems, they get to ask about the environment. Far better than “Show us all the steps to get BGP routing configured,” or “Develop an entire B-Tree while we watch,” questions. Certainly better than any question that ends with “And don’t use the internet.” Are you kidding? Can we talk about the field and what year it is?

    As I’ve said off and on over the years, you want the best coworkers you can get or the best employees you can get. Either way, hiring for expertise with a given tech product is not the best route to that goal. You rock—so get people with you who do, too. It’s not going to get less complex, so have peeps that can keep up and carry a load, no matter what tomorrow’s technology looks like.

  • Complexity is Still With Us

    Complexity is Still With Us

    We have come a long way and had a lot of improvements over the years, but we still struggle with the ability to simplify things faster than we create complexity. It isn’t enough that each new wave of Really Important Bits™ comes with its own issues and layers and complexity; we also haven’t been cleaning up our previous Really Important Bits™ projects. We haven’t cleaned up the successful ones and we haven’t cleaned up the failures.

    It is time to start. Honestly, we are looking at an extended stretch of ‘Do More With Less,’ and we need to get our houses in order. Want to do more with less? Start by standardizing. Yes, that one project that used Really Important Bits™ (or its companion product Really Cool Tech™) was neat and all, but keeping a technology and its layers and pieces laying around for a single project is not great management. In fact, it isn’t management at all; it is letting things happen. I’d call it chaos, but then we’d have to have a whole conversation about Dungeons & Dragons and, frankly, it is happening in the forum of the overall enterprise architecture so it’s not actually chaos, it is simply excess technical debt.

    DevOps was never meant to be a destination, but on this cross-country road trip, our IT car will get filled with garbage if we don’t take the time to clear out the Really Important Things™ of last year or the last management team or the latest merger. We cannot continue to layer more on without relieving pressure somewhere. AI has the potential to offer some pressure relief in some areas, but we were already behind, so for a variety of reasons, it isn’t the silver bullet we need. Those reasons are simple–it is less secure to leave 50 different ways to do the same thing laying around. AI is resolving some problems and freeing up time, but you’re still wasting time and money on redundant or unused Really Important Things™.

    Some things simply cannot be cleaned up without a massive investment. That’s fine—I hope after years of using DevOps methodologies you have them on a list of things that you’d like to upgrade/replace, but it just isn’t feasible to do so. Focus on the things that you can simplify. The famous low-hanging fruits are fine, just like simplifying things in the early days of DevOps meant that each piece of low-hanging fruit freed up more time to focus on other issues, the same is true now that the low-hanging fruit is generated from DevOps. Or DevOops, in some cases.

    How did I get here, you ask? I was writing a simple overview of Git, CI/CD, DevOps, DevSecOps, GitOps, etc., etc. for a newer technologist, and realized that in between those important parts are a whole lot of tools and technologies we thought were important, but which are no longer terribly useful or necessary. I did her the favor of not including the by-the-wayside technology spaces and product markets. I removed the complexity, you could say.

    And keep rocking it. No matter how far along you are in your IT career, you can look back at all of the things you have learned. Apply that learning to simplifying and improving. Reduce overhead by reducing redundancy and look forward to the next Really Important Thing™ you’ll get to learn about. Keep improving—both your knowledge and the environment. And we’ll keep cheering you on.

  • Are We Delivering?

    Are We Delivering?

    I had an interesting conversation today where I was told, “We do great with CI but terrible at the CD part.” My immediate reaction was to point at all the great CD activity going on in vendor space right now. But as I stopped to ponder, I realized that we’re doing all of that great CD activity to play catch-up.

    DevSecOps has us covered in spades—the toolsets allow for scanning and protection all through the process, from the first line of code to application retirement. I would argue that after being left out in the cold, DevSecOps has done a better job than DevOps at the right side of the equation.

    In DevOps, the various “cloud-native” deployment models (I use scare quotes because they’re not really cloud-native. If you dig into them, nearly every one of them includes Kubernetes in their definition of cloud) are starting to do the job admirably, but in shops starting to automate the entirety of the process, the CI part has been automated and code delivery accelerated for a good long while.

    In short, adoption seems to prove, once again, that the benefits of rapid development are more important than the benefits of offering a stable, repeatable deployment environment. This makes one wonder what, exactly, we should be doing to convince IT and business leaders in orgs smaller than web monsters that security and repeatability both demand the implementation of capable continuous delivery.

    I think we failed the audience when we allowed pundits to blather on and on about deploying thousands of times a second when most applications in most orgs need to deliver at a significantly slower pace. And not only that, but want to deliver at that slower pace, given the “Don’t fix what isn’t broken” rule. Even if the environment is stable, rolling out for a single minor bug fix is possible but it’s not the best use of time—both computer and human.

    But we are catching up. We have things like GitOps and Kubernetes automation catching up with the rate of development; security is already there and test automation is ready to find issues before deployment. It is simply implementation that is behind and, as time goes on, more orgs will get the implementation part nailed.

    And through that process, you’ll be there, rocking it. Step up and make sure it is done right. The entire process is there; you could sleep better at night knowing that it is all in place and you are not likely to get a midnight call. Your org loves stability, you love good nights of sleep … Go out and get it.

  • Product Evaluation Discussions

    Product Evaluation Discussions

    Instead of doing a predictions blog like 99% of the punditry, I figured I would do an awareness blog to wrap up 2022. Every year, you deal with a wide variety of people trying to tell you about products that may (or may not) be useful to your IT efforts. Some of the products even make it to the evaluation phase and while a few get installed, a smaller number get used.

    One of the many ways to minimize your time investment when talking about the bewildering array of new DevOps technologies and products is to know where the information you are consuming comes from. Here is my start at a list of information sources, where the information they impart comes from and how to get the most out of these sources.

    Marketing: The marketing team at any organization exists to spread the word about the product’s good points. Most marketing professionals only admit weakness in the underlying product if pressed. This is expected–if the sole purpose of your job is to tell the world why the product is needed, blathering on and on about the weak bits is not going to work out. But we all know there are no perfect products, even before you account for all of the environmental differences we’re installing into. So listen – they will present the product in the best light possible and have useful knowledge, particularly early in the evaluation process.

    Sales: The sales team wants to sell products, but they also are invested in happy customers. A good sales rep in high-tech is building relationships because organizations can create an income stream if the product’s value is realized on their site. This makes them practical. Their goal is definitely to represent the product and company positively, but in a light that admits more weaknesses and offers workarounds for the deal breakers.

    Sales Engineers: A lot of the sales team’s practicality comes from the team’s engineer(s). They’re the ones that have to help you get things installed and running, so they have a vested interest in the organization knowing ahead of time what will require work and what the risks are. Given a choice, talk to the SE alone before signing a contract–not because sales lies, but because the SE is there specifically to note issues that might crop up and how to get around them.

    Crowd Evaluations: Two things to remember about crowd rating sites–the participants are volunteers on the best sites, paid contributors on others. For paid contributors, well, the motivation is pretty clear. For many voluntary participants, the motivation is that they either love or loathe the product. Most of these sites allow vendors to respond to commentary, and some even allow vendors to have evals removed. No one offers a service where glowing vendor reviews can be corrected … keep that in mind. These sites are useful, and a few of them are mostly people that want to help. So find the good ones (I’m not advertising anything here, so no links–sorry) and use them.

    Analysts: Nearly all of the analysts I know–be they GigaOm analysts or a competitor–have experience in the field. They have done it, and most of them continue to keep their hands in the mix somehow. While I have not written (or maintained) a line of code in months, I do attempt to do so regularly. At the individual analyst level, the thing to watch is how long it’s been and how current they are. Some do pure analysis and haven’t touched the toys in a decade or more, and for C-level analysis, this is great … but for implementation recommendations, best to find a different source.

    Analyst Firms: This is where the real issues in analysis creep in. As an enterprise architect, I dealt with an analyst firm that–at the time, at least–would say whatever we wanted them to say. Totally useless in evaluations, but it worked well when convincing our technical advisory committee to approve the right approach. Each firm comes at the problems with its own lens, and being aware of a given firm’s slant is a good step to understanding how to use them–or if you should rely on them at all.

    Press: The age of pure-play press is largely dead, leaving a lot of “Paid for publication” out there. While there is still non-sponsored content being developed (one of the few rules Techstrong Group has for my writing of this blog is that I should avoid mentioning products; for example, making sponsorship they may pursue more about their vendor relationships and how many of you are reading my drivel), the majority of what is published as “articles” is “marketing” and should be treated as such. Reading this content can be useful for early education but not so much for evaluations.

    Internal Champions: Not the mandatory sponsor most projects require, but the person inside that is driving the org to look at a solution. These people are generally key. They know the environment, they know the product, they have ideas on how the product could help the environment, and they have a history in the organization. Whether their ideas about how various products help the company have panned out with other tools, for example. Of course the usual caveats apply… Security people still think you should be doing more to lock out bad actors – that is what they’re paid for, but that influences their evaluation of a new security product and how it fits in the org. Awareness of that type of vested interest can help filter internal champion input.

    There are others, or course, but I’m keeping this blog-length, and most–like MSPs or hosting providers–can be viewed as an extension of one of these (MSPs and hosting providers generally act like extensions of their chosen product’s sales and marketing, for example).

    And keep rocking it. All these people can help you understand how to make the environment better or your role easier. They can’t do it for you; that is your skill. Listen to what they all say and then act in the organization’s best interests. When I’m not a pundit, I tend to use marketing/crowd rating to get a feel for the space, then analysts and SEs to tell me about the space and specific products in it respectively. But figure out what works for your org and be aware of what viewpoints the various actors bring to your learning.

  • Best of 2022: CI/CD is the New Lock-In

    Best of 2022: CI/CD is the New Lock-In

    As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    Welcome to 2022! Let’s start this year’s blogging off with a bang, and point out that we are in the process of creating the biggest lock-in that we have ever had. And I do mean ever. Maybe the hardware lock-in of the old days where vendor A was incompatible with vendor B was worse, but at least that one we acknowledged when we signed the contract. This one is growing on us as I type.

    Our DevOps environments in 2022 cannot run without what I like to call the “toolchain controller”: GitLab, Github CI/CD, Atlassian, CircleCI, Jenkins—whatever you are using. Like you need some form of faucet or flow control to make running water work, you need the CI/CD environment to make DevOps work.

    You. Can’t. Live. Without. It. And just like any other vendor solution, CI/CD vendors are not going to be in a rush to help you move to a competitor. It won’t be easy or cheap to switch, largely because we are moving everything that might have been on a computer that once had developed code running on it into the toolchain.

    Sooner or later, we’ll back off the kitchen sink definition of “What is DevOps?”, but I predict even then we will have to answer “…A lot of what we do,” because DevOps is, by definition, end-to-end. It is about the process and all the steps from design to production.

    No matter how long or complex the process through which an organization’s CI/CD tool runs, a plan must be in place to replace it. A workable plan, not a check box plan. When Atlassian decided they preferred cloud-based customers, their customer base was shocked. Atlassian was wise enough to leave an option for customers who really had to have an on-site solution, but it is not difficult to imagine them phasing that option out, or to imagine another vendor dropping on-site support altogether. Some of the more competitive offerings in the space—GitLab springs to mind—are online-only already, making that option more appealing to other vendors as it’s now proven viable.

    So, have a plan. This is more important, IMO, than cloud vendor lock-in. Cloud vendors are a small community, and each understands the others, so if push came to shove you could find help moving between the big three cloud vendors. There are dozens of DevOps master controller-type solutions in regular use, and some of them are not at all CI/CD solutions (application release orchestration tools and software infrastructure management tools are two areas doing CI/CD duty at some orgs, for example), so there is not going to be much help moving between them unless you manage to find a very specialized skill set that matches your desired move.

    So, have a plan. Yes, I am indeed repeating myself. Know what you’re going to have to do before you have to do it. Include what to do if the master DevOps controller goes down. Because it will, sooner or later.

    And keep rocking it. Protect your masterworks by protecting what builds them. And keep rolling out the tools your users need. It’s a new year—learn a new skill and use that to turn out even more cool stuff. I haven’t picked a new skill yet, but I’m taking that last bit of advice myself. And again, in the new year, thank you, for all those who don’t know to say it.

  • Best of 2022: Return to the Office? Nah.

    Best of 2022: Return to the Office? Nah.

    As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    I was watching Charlene O’Hanlon’s interview with the CRO of Rollbar, discussing the slow growth of “return to office” policies. High-tech, because we are more mobile, had more options than many people—the janitor, for example, must be physically at their job to do it. High-tech employees did not have that issue—or if they did before the pandemic, they certainly didn’t after a few months of lockdowns. And now our infrastructure allows us to work from anywhere.

    One of the things that some companies are considering is requiring that all employees come back to the office. I rarely say things super bluntly, but this time, I need to be blunt.

    Fight that tendency if it shows up at your organization. At this point in history, that way lies corporate doom. Okay, maybe not doom, exactly, but certainly bad things. Some people back in the office is fine, a choice about coming back to the office whenever your state/provincial/local government decides to allow it? Fine. A required return for everyone? No.

    Of course, one cannot make such a blunt statement without an explanation. Do I think that remote work is somehow better for the company? No. Some people are more productive working from home, while others are distracted by the many non-work things around them that they want/need to do. So it is a mixed bag that requires monitoring. In all my years working from home and mentoring others just starting to do so, I’d say this split is closer to 50/50 than you might think. To paraphrase a sergeant from my army days, “Those who most want to are sometimes those who absolutely should not.” He was talking about living off-post, which is outside jurisdiction in much the same way that working from home is. And I’ve found some truth in that statement when applied to WFH. In fact, one interesting thing for me to watch were the success rates for companies that went 100% WFH. It’s gone better than I expected, probably because it was a broader swath of staff than just those who wanted to.

    So why would it be better if I, who have worked from home for more than 20 years at a number of different companies, think it’s a mixed bag?

    Hiring and retention.

    We know that we’re short-staffed. We know that it is hard right now to find any flavor of IT peep, but it’s brutally hard in InfoSec and pretty tough in DevOps. A decent percentage of employees is going to want to keep working from home, and in the current environment, they can change jobs faster than you can say “retention bonus” if you give them a reason. I don’t have hard numbers, but let’s assume a hugely conservative 10% of IT staff preferred working from home. Can you afford to lose that number of your staff? Or even half that number, assuming some won’t leave? Probably not, considering the openings versus employee counts we’re currently seeing. More to the point, can you afford to never hear from that percentage of applicants because they don’t want to work somewhere that mandates their physical presence in the office? From talking to people, it seems money doesn’t resolve this issue. Working from home is a tangible benefit, and whatever a company offers, the next one might match with the WFH option.

    There was a slow change going on in IT, where a significant percentage of staff were working at least part-time from home; the pandemic just sped that process up—shifted it left and iterated, so to speak, and now HR and management are going to have to deal with this reality head-on.

    I’ve felt that some of the positions I’ve held at some of the organizations I’ve worked at/for were best performed on-site. But we have enough successful 100% virtual companies now to acknowledge this might be a corporate culture issue and not a “job fit” issue.

    I don’t know how companies will handle it, but absolutism is not the way forward here, IMO. Charlene and Michael Davis had some thoughts on WFH and returning to the office you might want to listen to.

    After all, you all are kicking it, and I know some of you don’t want to go back to the office. Can your org afford to lose you? Not if there is an easy way to avoid it.

  • It’s a Toolchain!

    It’s a Toolchain!

    I was talking with some friends the other day, and we got to discussing how inaccurate the word “toolchain” is. We pundits–and even a lot of marketers–use the word toolchain regularly and, while it’s not a terrible encapsulation of what we’re doing, it is, at best, a hasty generalization. There are a lot of reasons for this.

    The biggest reason is that “your toolchain” can have meaning when talking to a single DevOps team, but an organization rarely has just one. And increasingly, even single teams will use different tools depending upon the project they’re currently focused on. There are a lot of languages, targets, environments, specialized tools, frameworks, etc. that are unique and interdependent. Any organization that actually ends up reaching “one toolchain” will keep that honor only until the next merger. Or until the next project starts up. Because in the end, IT is about solving problems and while some things like OSes get standardized, others do not, as they are focused on solving those problems.

    Then we have the variations. Even ‘one’ toolchain is really not the same chain of tools; it is the same CI/CD tool managing a pool of others. This has really interesting connotations for the idea of the “weakest link in the chain,” whether we’re talking security, compliance or testing, because the weakest link might depend on which tools are spawned this run. To take an easy example that doesn’t overlap with the biggest reason above—targeting containers for test and virtual machines (VMs) for deployment. Some organizations do this type of thing regularly due to licensing or space issues. Two different deployment steps in ‘one’ toolchain. There are more instances like this than you would think. “This project uses make, that one uses cmake” is an example of the type of scenarios we’re talking about. These minor variations are handled by what gets called from CI.

    Finally, most of the real-life organizations I stay in touch with are both project-based and are constantly evolving. That makes both of the above scenarios the norms, not the exceptions. While they would love to have one stack and one toolchain for all projects, no one realistically sees that happening anytime soon. Some organizations that crank out precisely one type of application for one type of audience (dynamic web apps for a particular market, for example) can get to a single DevOps toolchain, but most do not.

    A windbag like myself claiming that we’re using the wrong term—and that toolchains should always be plural when having these discussions—does not make it important. I do think it matters though because what is useful for one toolchain is not for the next. The oldest, most established and, arguably, most thorough code analysis tools are for C/C++. Talking about how we have a solution to help add testing to your toolchain is not terribly useful if the point is to extoll the virtues of those code analysis tools and the audience is full of people from primarily Python or Go shops.

    Right now, important tools for you to consider are those that make your work easier. Consolidation should be high on your list of priorities; we have far too many DevOps tools. Merging should be a consideration. Yes, Python and Ruby have different needs, but if there is a single tool that can offer build or test for either based on information contained in the pipeline, grab it so two toolsets don’t bifurcate your build process.

    And keep kicking it. Seriously. In the grand scheme of things, we’re entering a bit of a rough patch in IT, but you all have been managing to keep the org online and functioning for plenty of rough years. Don’t stop now. Your users would thank you if they weren’t annoyed by that spelling error on the button of the “About” page. So I’ll do it for them. Thank you.

  • We’re Doing More Less Development

    We’re Doing More Less Development

    My roots are in software development. I’ve written tax software, SmartGrid firmware and servers, enterprise integration code for many developed and purchased servers, mapping software, cell phone firmware—the list goes on. The point is development is in my blood. When I look at something that impacts software development, I look at it through a practitioner’s lens as much as an analyst’s. And there is a lot of change going on in the realm of software development.

    For a very long time, there have been options out there that reduce the amount of software we develop. And those options are often popular. There was a time where the most common phrase in enterprise IT was “Develop core systems, purchase support systems,” and the message sank in enough that we don’t need to say it anymore. There was a time when enterprises cobbled together systems as essential as email–some developing their own systems, but most working hard to integrate available offerings. We have completely flipped that equation, and now almost no one would consider spending significant IT resources on email. Not on development, not on integration. There are of course corner cases that do have to–our industry could be defined as a collection of sharp-corner cases we haven’t yet smoothed out–but few, if any of those reading this blog have had to worry about those corners. So, change number one: Purchasing IT solutions is massively successful at reducing our time. From CRM to email to security, we’re using far more tools written by others.

    There have also been code-generation tools forever. While the most well-known ones have historically been UI-focused, 4GLs generally tried to address development with less code. Again, time, failures and iterations have given us useful code-reduction techniques. From pre-formatted ‘if’ statements that we just plug in variables to API generation through (sometimes AI-powered) initial program generation engines that give us code to start a project. The requirements for writing code are less per-project.

    And the big one: Open source. There are entire software markets for which it isn’t worth developing solutions because there are good open source solutions on the market. If it is popular but even vendors cannot afford to make solutions because everyone is using the OSS solution—well, that reduces the amount of code developed. There are several companies whose entire business model is simply offering enterprises service and support on OSS. No development required, even for the “vendor.” Large portions of any given application we develop these days are based on open source that we include to solve one piece of the problem. We’ve had some spectacular hacks and failures based upon that model, but it is undeniably an enabler for more solutions.

    With all of these (and arguably more–like API-first and API standardization) reducing the amount of code we’re developing, you would think developers would be less busy, right?

    DevOps and Agile streamlined our development and shortened delivery timelines for subsets of a given project, but haven’t—and weren’t designed to—reduce the amount of software developed. Indeed, quite the opposite. With faster iterations, more could be tried out.

    But it is wrong to think there is less development effort. There are several reasons for this, but I’m going to focus on the big one. People invested in the company—business leaders, etc—have always had a massive pent-up desire to improve software to increase efficiency, competitiveness, etc. And IT was the bottleneck. Agile/DevOps are by no means perfect, but they offered a pressure release valve for that pent-up demand. And we’ve been at it long enough to know that rapid iterations in response to those demands inspire more new ideas, creating another iteration… So it will be unlikely to stop. Indeed, we all know what technical debt is, but there seems to be a disconnect between knowing intuitively that more code means more debt in the form of maintenance overhead. So developers are doing more because the organization has good ideas that need implementation, even though we have plenty of tools to reduce development effort. Some organizations have reduced developer headcount, but not many. And that might slow, but that’s unlikely. In the coming highly competitive environment, more features and solutions will be desired, not less.

    And you’ll be there, continuing to rock it. Pay attention to ways you can further reduce code effort. This is a long-term process, but the goal should be to reduce the growth rate in staff time. It is unlikely to go down overall–because maintenance overhead plus new projects is a constantly growing number–but slowing growth helps developers and working managers stay sane and take the time to find good hires.

    And just keep doing more less development.

  • Faster and Better Testing?

    Faster and Better Testing?

    The whole concept of Agile and DevOps was to iterate development faster and deliver results in a more timely manner. As we learned more about both methodologies, processes and policies were put into place that improved the quality of what was created. Early ideas of quality like, “We can just do another iteration,” still exist, but are largely not used. Rollbacks are a thing in most orgs, and though the environment is more complex, rollbacks are easier to manage in the smaller development changes that iterations generally represent.

    And once we got past the whole, “Anything that slows the process down is bad!” mentality that permeated early implementations of both DevOps and Agile development, we started seeing amazing things. But including things like security and functional testing were not viable in the fast-iteration world that Agile and DevOps created. And they really weren’t viable at most orgs in the slow-iteration world of waterfall, either. Staffing and time constraints made them fall far short of optimal in the vast majority of organizations. But putting them into the DevOps process challenged vendors to find a way to do things faster and challenged organizations to look at quality and security a little differently.

    And now, we have tools that can test—be it functional, integration or security—at the speed of DevOps. Tools that enable Agile development with an eye toward security. A far larger number of developers now acknowledge their part in application security and are creating more secure code.

    Keep an eye on how AI/ML is being used in testing—all forms of testing—and how it evolves in the next year or two. The same with full-on automation. I’ve made no secret that I view AI/ML in the testing space as advanced automation because of what it enables, so maybe “Watch what AI/ML-enabled automation is available,” is more accurate. The ability to create, run, process results and even modify code to resolve issues are all out there today, and getting better. Faster, more accurate, more automated.

    Much like back when intrusion detection became intrusion prevention, I would not just turn it on and walk away, but think about the ability to upskill developers; “Here is a list of things the automated system found, and a list of fixes it proposes.” They are literally being shown how to do their craft better.

    I’ve been a developer, so I’m not being offensive, here. If you get something that tells you, “This is an issue; here is why it happened and here is what to do to fix it,”take the opportunity to get better at coding. Look closely at the what, the why and how to fix it and incorporate that into your work.

    And keep rocking it. We’ll be making more stable and secure code, but you’ve kept systems running without that feedback and fixed the errors along the way. This just makes it easier to find the errors early—before they crash production and make a fire drill.