devopsy.kinsta.cloud

Tag: development

  • Is AI the Answer to Devs’ Documentation Problem?

    Is AI the Answer to Devs’ Documentation Problem?

    I have written this blog half a dozen times over the years, but every once in a while something comes up that makes me realize I should revisit it once more for those in the back. This time, it was a social call with a group of friends, some of whom are in high-tech, all of whom are smart and often insightful. One member of the group, a tech lead for a company that you do business with, was talking (in vague terms, of course; this person is a professional) about work he is doing, and the group started to make fun of documentation.

    Let’s face it—since the very first line of code was written, we have sucked at documentation. It is a rare project that (a) gets just enough documentation and (b) keeps that documentation up-to-date. What we most often get is no documentation or documentation that records the initial design but, by the end, bears little resemblance to the code’s actual workings. The worst of all types of documentation is the “It’s self-documenting!” kind, which has gotten another boost based on the idea that OpenAPI/Swagger will be a tell-all about what is actually happening with the API. Like far too much API testing, it does a good job of telling you about inputs and outputs and, in most cases, absolutely nothing about what is done with the inputs or what magic happens to get you the outputs.

    After our call, I got to thinking. What can we do to adequately document the code? I mean, with AI becoming all the rage and the set of lines of source code available for training being so massive, you would think we could do better. Maybe we can—but right now, the language processors that we currently pass off as AI are too busy being conversational or generating the code itself. Both of those spaces are going to take a while to get “good enough” to rely upon without review (not as long as many think, but certainly not tomorrow). Maybe that point will be when some enterprising engineer will turn it on source. Though I think that it will take a documentation specialist and not a coder—after all, we coders created this problem and haven’t fixed it in decades.

    Many of us truly believe the “self-documenting” part when that is and absolute lie. It may be self-documenting to someone who wrote it or, in the best cases, someone with deep domain knowledge, but certainly not to the person who has to pick it up. We all have horror stories of working on that application—or porting/rewriting an application—that claimed to be documented or self-documented and was not even close. The saving grace in all of the cases that I worked on was that the code actually worked and performed the job required. Given some extra time to step through it, it could be rewritten even without good comments and docs. (Hat tip to the dev that had to pick up one massive porting project from me because I left to go write about storage—the project was huge and was a blast, but having to hop in halfway through probably made him crazy.)

    If you are planning for the future, I recommend a ton of things, but for documentation, only two. First, write design docs, discuss decisions and put them in Git with the source code. Require that they be reviewed and updated after each sprint. Then, make sure that there are comments in the code. Using naming conventions to document code is helpful, to be sure. But more is needed—particularly as code morphs into whatever it is going to be in long-term final form. We have all seen that method or function that has a name … and then doesn’t do what the name implies. Or worse, that does what the name implies but also applies half a dozen side effects because devs needed somewhere to put new functionality. And we haven’t even talked about complexity like feature flags.

    So do both, and require that devs spend a bit of time on each during each sprint—not to be a jerk, but to pave the way for dev #327 that inherits this code and has to make sense of it. Help them get productive quickly.

    And keep rocking it. We have documentation problems because we solved business problems rapidly. That’s a good thing, we just have to think about the next gen of devs that will be on this project, and give them that little boost into productivity that documentation offers. And maybe you’ll help the compliance team while you’re at it, but that’s a different blog.

  • 8 Ways ChatGPT Can Help Developers

    8 Ways ChatGPT Can Help Developers

    ‘Adapt or perish’ is the mantra in the tech world, and it holds particularly true if you’re a developer.

    Because of how dynamically technology evolves, developers face greater pressure than most to be ahead of the curve in adapting and becoming proficient in the best tools becoming available as a result. ChatGPT is the latest such tool.

    While there has been talk of ChatGPT being a “job killer” and horror stories are making the rounds about a dystopian future in which it renders half of humanity meaningless, the reality is much more nuanced. The market will evolve as it has with the advent of any technological advance, and those who can leverage such leaps to their advantage will continue to be effective.

    For developers, ChatGPT represents a chance to introduce efficiency in their tasks, scale up productivity and minimize errors and deficiencies. Used wisely and appropriately, it can help developers become better at their jobs by honing their abilities and enabling them to work more creatively within their existing functions.

    Here are just some of the few areas where ChatGPT can bring tremendous value to developers:

    Testing

    Writing code is a complex process. Debugging it is harder. And in between those two is the process of actually testing the code. ChatGPT allows developers to enable real-time or prompt-driven code testing at different instances to ensure the coding process becomes more efficient.

    ChatGPT provides a wide array of suggestions and assertions based on the functions and variables used in that particular code to allow for wholly tailored testing of the code for that particular environment. Doing so can be particularly helpful in the subsequent debugging and documentation phases.

    Debugging

    Ask any developer what the worst part of their job is, and debugging is likely to be relatively high on their list. As an old saying goes, “An average developer spends hours writing code and days debugging it.”

    However, with ChatGPT, that may soon become a thing of the past; it can be leveraged to debug thousands of lines of code for error identification and then debug again based on any error message received.

    Regardless of whether you’re a seasoned veteran or just starting out, in this particular case, ChatGPT can be invaluable when scanning code and suggesting possible fixes. Used effectively, this can help developers perform their functions more efficiently by eliminating the laborious hours spent identifying the problem to fix.

    Furthermore, this should prove particularly helpful when writing test cases and documenting the debugging process to identify what caused the bug in the first place.

    Documentation

    As mentioned above, ChatGPT can be leveraged to assist in or, in some limited cases, perform the entire process of documentation.

    It can analyze complex code, contextualize and understand its logic and develop an appropriate explanation of the code’s functionality. More importantly, the specific language used in such documentation can be adjusted to ensure it is tailored to the skill and comprehension level of the person reading it.

    Imagine not having to explain and re-explain how the code works based on who reads the documentation. As a result, developers can spend more time coding rather than documenting what their code does.

    Code Generation

    The most exciting, if not the most effective, way ChatGPT promises to revolutionize what it means to be a developer is code generation. With its code generation functionality, ChatGPT effectively functions as a personal coding assistant that understands the users’ coding preferences and natural language and turns that into executable code.

    Doing so promises to bring unparalleled efficiency to all code generation, as simple command prompts can be used to produce code. In other words, code generation that would have taken minutes can now be done within seconds.

    Moreover, this allays the fears of complete code generation by ChatGPT, as programmers can assume an oversight role over its generated code. This, coupled with some of the other benefits discussed, has a lot of time-saving potential and it can maximize productivity.

    Data Preprocessing

    Machine learning is yet another exciting aspect that promises to drive the future of coding and development in general. ChatGPT can be used across the board to clean, transfer and appropriate particular datasets to be used for testing and training.

    With the ability to deal with issues such as missing values and miscoded variables, ChatGPT can enhance the overall value that can be driven from any particular dataset while bringing more efficiency to the table.

    3D Designs

    This is where the expansive aspect of ChatGPT, as mentioned earlier, comes into play. ChatGPT is more than just a programming developer’s friend. ChatGPT is fully capable of being integrated into the Unity Editor. This is particularly significant as this allows for extensive 3D modeling and in-game designs.

    Digital prompts can be converted into usable 3D images and models, allowing faster and more elaborate renders. This promises better productivity, with the scale of in-game designs set for unprecedented growth in terms of both details and content.

    Threat Detection

    ChatGPT is already pushing the limits and boundaries in terms of generating and documenting code. Additionally, it addresses another vital issue related to coding and programming as a whole: Identifying potential vulnerabilities.

    Using security tools such as a firewall or password manager is not enough protection. ChatGPT can be leveraged to generate code and peruse and review existing code to weed out any potential vulnerabilities. Not only can it point out potential vulnerabilities, but it also helps carry out parallel quality assurance to enhance the overall security and quality of that code.

    Pair that with the conventional and reliable privacy and security elements, and you’ve generated near-impenetrable code for secure deployment.

    Customized Extensions

    Perhaps the most hyped-up benefit of ChatGPT is the proliferation of extensions available since its release. While the use of automation to oversee the completion of tedious and monotonous tasks is nothing new, ChatGPT allows for an unprecedented degree of customizable extensions. Developers can generate extensions based on their own usage patterns and preferences.

    Final Thoughts

    As is the case with any new technological wonder, ChatGPT is a resourceful tool, but its full potential can only be leveraged by those that understand it and know exactly where and how ChatGPT may prove most productive. However, the very fact that we do not yet understand the full extent of its capabilities should be cause for caution.

    ChatGPT has already faced mounting criticism related to how it handles users’ data privacy, particularly that of minors.

    It is critical for organizations to devote appropriate resources to fully assess exactly how ChatGPT may bring the most value to them without negatively impacting security and data privacy.

  • Things We Should Acknowledge, Part Two: Skills Are Less Relevant

    Things We Should Acknowledge, Part Two: Skills Are Less Relevant

    This is perhaps the toughest issue for all of us to acknowledge: The longer you are in the space, the more skills you have filled out on LinkedIn (or wherever you are tracking your career for HR reps to look at) but the skills you possess today are, by definition, a subset of the skills you will possess even a couple of months from now if you change roles. Note that I said “change roles,” not “change employers.” The fact is that we use an insane number of tools in the development, DevOps and operations environments, and we’re addicted to adding new ones (that might be a hint about part three of this series). Changing roles within a company can involve minor changes, or it can take you to a whole new environment where no one cares that you are a Java genius; they want to know how fast you can pick up Python and be truly productive. Or they nod at your talk of configuring servers and ask if you can do that with Ansible on containers. It’s just not as important anymore for most employees to have a specific skillset. That’s a major contributor to the problems I talked about in part one.

    Of course, there are roles in IT that involve far less change. Email administration, for example, isn’t all that different from the way it has been since, well, forever. We have changed how/where the server is configured and many orgs have added SSO or multifactor authentication, creating new issues, but it’s all evolutionary. When NoSQL systems came out, it looked like a major change in DBA work, but it really wasn’t. Within a year, reality put SQL over top of NoSQL stores and DBAs kept chugging along.

    But DevOps has impacted both development and operations in profound ways. We pretty much standardized on Java, with all of its warts, because it was object oriented, general purpose and could be compiled if needed. Though embedded largely stayed with C, there was no serious competition in the enterprise for Java and Java-like (.NET) languages. Knowing them meant you could do everything but real-time/embedded development jobs—and even some embedded work shifted to Java as prices for miniaturized compute power dropped.

    But that changed. The inflection point was JavaScript, and from there, we went a little bit crazy. When JavaScript took off, full-stack developers needed to know one front-end and a couple of backend languages. Other languages still existed—the staying power of both Perl and PHP is somewhat surprising to me; they’re both good languages but have limitations. But still, no serious competition. But Node.js took JavaScript to the server, Ruby was popular for backends, Python came along for quick scripting … And now we have apps written in those and a dozen more languages floating around.

    I chose languages to fit the whole story into a blog because they see less change than the operations side, where we’ve gone from annual big releases to rolling deployments updated frequently and all the support tools changed in the process. Infrastructure has changed, data stores have changed, mobility has changed, UI targets have changed—basically, it’s a chaotic mess.

    And you’re in the heart of it, keeping the data flowing and the org running. It’s astounding, and you deserve more kudos than you’re likely getting. So approach hiring differently. Some orgs are already there, but skill-based hiring is still too prevalent. Hire broad technical knowledge and a desire to know more. As someone I know honestly said in a job interview once, “No, I never used it, but it is just another programming language. I’ll be productive in a week.” She got the job and delivered as promised. For all but those few corner-case roles, hire for potential and achievements and skills will follow.

  • 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.

  • Shift That [bleep] Left

    Shift That [bleep] Left

    Seriously. The more you can shift things like security and test to the left, the more responsive the DevOps process will be. Some things are better shifted right … But only while solving the problem with shifted-left work. A good example is blocking zero-day attacks proactively while the development process fixes the code to stop the attacks permanently.

    One thing we in IT are terrible about is following up on that “fix it” part—because we are very busy. Once a problem is blocked, we tend to fight other fires because we have too many things going on. We have absolutely got to get better about that. But I don’t want to get sidetracked. Today’s topic is about fixing bugs/vulnerabilities as they are created.

    One of the issues with the way we used to handle test and security was that by the time we had “This is an issue we need to fix,” feedback, the developer was off doing other things. But with the increasing inclusion of security and testing in the DevOps process, we now have the ability to provide feedback far more quickly.

    My favorite innovation in the DevOps space is not some wild new bug/vulnerability detection feature, nor is it rampant use of AI (though some uses of AI do come close to being my favorite). It is the humble IDE plugin.  As a developer, writing buggy or insecure code is never the goal, but it happens every day. IDE plug-ins, hooked into test and security software, allow developers to get a heads-up that there might be an issue while writing the code. This not only addresses the problem while it is fresh in the developer’s mind, it also allows developers the opportunity to improve their craft simply by understanding which issues they create often and learning how to avoid them.

    We have all written bad code. I once actually over-wrote databases for a bank; it was a great humbling and learning experience for a young hotshot who needed to be reminded he was not perfect when coding. Others no doubt have similar, if less catastrophic, stories to tell. The ability to get warned about issues—but quality and security—while writing the code cannot be overestimated. Some developers will hate it because it is more intrusive than the old school “Okay, all the code is written, you can test now,” process, but it is powerful precisely because it is more intrusive and proactive.

    The challenge for those in the testing and development security spaces will be to keep false positives at a minimum. I’d say zero, but I’d rather get the occasional “Oh, that. Yeah, not an issue in this case,” than go through having it tell me things throughout development and still end up with buggy/insecure code.

    You all are still rocking it. The amount of software in use every day across the world is staggering, and you’re cranking it out and keeping it maintained—whether you’re working on internal applications or commercial packages. You’re making it work. Take a look at QA and security IDE plug-ins, make an honest assessment of whether they could make your work more secure and/or higher quality. I think they can for nearly all of us. And they can save time by doing it earlier in the development process. And maybe you’ll get recognized for rocking it. Okay, probably not, but it is possible.

  • Break Open the Black Box of Software Development

    Break Open the Black Box of Software Development

    If you asked an airline executive what their biggest expense was just a few decades ago, they would’ve easily answered, “Jet fuel.” These days, you’d be hard-pressed to find an executive in any industry that wouldn’t answer with, “Software.” But here’s the difference: With jet fuel, that executive would have told you that they can fly x number of seat miles per gallon/liter of fuel (or pounds of fuel, if we’re being technical). With software development, the expense is becoming more material–and far more variable–but the return on that investment is rarely clear. Over the past decade or more, software development has readily assumed its position as the fastest-growing (and often largest) expense line item in virtually every industry. All companies are adding software experiences to or around their products, and they need the people and tools to build, support and continuously optimize those experiences. And that costs money–a lot of money.

    The problem is that the language, the metrics and the world in which software development exists do not translate into operational or financial terms that business leaders can readily understand.

    “We invested X million dollars into software development last year,” a CFO might say. “And what do we have to show for it?”

    Meanwhile, a technology leader might respond with, “We’re doing X deploys a day!” or, “We wrote X thousand lines of code!”

    They might as well be speaking different languages because, in practical terms, they are.

    And the problem is, that you can’t manage what you can’t measure. To continue our airline theme, software development continues to be a ‘black box’—this hidden-in-plain-sight source of information—that financial executives can’t seem to peek into.

    Why the Black Box?

    It’s not likely that technology leaders are being purposefully elusive toward business leaders–it’s more likely that they simply are not aligned on what, fundamentally, they need to do to speak the same language.

    The question at hand is, actually, “Are these investments we’re making turning into our desired business outcomes?” But the question technology leaders feel compelled to answer is, “What do your people do all day?”

    These are questions that Agile and DevOps don’t solve–translating Agile or DevOps metrics (also known as DORA metrics) into actual, actionable metrics for business leaders to understand. Although these metrics are tremendously useful for teams, using them to steer the business is a mistake.

    Misaligned in purpose and using different language, business leaders and technology leaders talk past each other as software development costs continue to rise.

    But the cost of software development is too high for business leaders to continue to tolerate this ‘black box’ of ever-rising costs. It’s the fiduciary responsibility of financial leaders to understand the value of software investments and figure out how they are affecting business outcomes–or their jobs could be on the line.

    In case this seems like a distant threat, it isn’t: I saw a headline recently about a prominent automobile executive who lost their job because they weren’t able to gain the necessary insight into, and business outcomes out of, their significant software development costs and that was affecting the competitiveness of their entire company.

    It’s happening. And it’s on both business and technology leaders to break that black box open and start speaking the same language.

    The next question, of course, is, “How?”

    How to Bridge the Communication Gap Between Technology and Business Leaders

    For far too long, business leaders have made do with the activity metrics provided by technology leaders–they’ve tolerated this lack of visibility and found other ‘strategic’ ways to justify the rising software development costs. Perhaps they’ve been questioning how A leads to B–how an increase in funding for software development might result in greater customer retention or app usage, for example–but they have not had a tangible way to prove to themselves, much less to investors, whether this is actually happening.

    In order to understand and quantify software development costs, we have to start demanding more from our technology leaders: Working with them to establish realistic objectives and key results (OKRs), and holding them accountable to business metrics that actually relate to outcomes. That means insisting on business results–and not accepting activity metrics in their stead.

    Stable-Fund Products, Not Projects

    Here’s a hard pill for finance to swallow: When it comes to delivering software-enabled customer experiences, it’s not about optimizing costs. It’s much more nuanced than X dollars in equals X dollars out. Funding by projects might help make the numbers neat, but it doesn’t reflect the reality of the business.

    Project-based funding also tends to keep project leaders in a cost-center mentality: It makes it seem as though all resources are fungible; as if the work and the people performing it are interchangeable.

    One of the goals of Agile is to maximize value for the customer. But when we fund by project, we often stop funding a piece of work–declaring it done–before it actually starts generating value. We have this false end date that doesn’t reflect the actual ending of the value that we funded to create.

    Instead, finance organizations should move to the stable funding of products: Funding an outcome and giving teams the ability to stop, change or extend their work to achieve the business outcomes of the product.

    This is a shift that one prominent UK bank has been going through in recent years–from traditional portfolio management to lean portfolio management, including the shift to stable-funding projects. You can learn more about how NatWest Group (formerly Royal Bank of Scotland) has made this shift in this webinar.

    Visualize the Flow of Value with Flow Metrics

    Finally, we have to stop treating the collection of technology metrics and business metrics as two separate, unrelated efforts. Agile and DevOps are great at accelerating the throughput of your software development … but vanity metrics around how quickly teams are delivering are not enough to justify the growing and material investment in software development.

    Finance leaders have the opportunity to be the Babelfish between technology leaders and business leaders. As mentioned above, one way to encourage clearer communication between teams is to use OKRs to naturally tie software development objectives to tangible business results. The more we practice drawing connections between technology and business metrics–the closer we get to finally breaking open that elusive black box.

    A key part of this is communicating operational metrics differently: Developing a core set of metrics for tracking the flow of business value in software delivery, and providing a mechanism that correlates the investment in flow for each product’s value stream with the business results for that value stream.

    Visualizing the flow of value in a software development process may not be as easy as watching value flow on a manufacturing floor–but that doesn’t mean it’s impossible. Thanks to the vast number of data and visualization tools at our disposal, it is possible to make software products and their value streams just as visible as production lines.

    The Flow Framework, created by Dr. Mik Kersten, addresses the pivotal challenge of breaking open the black box of software development and bridging the gap between business and technology to optimize the flow of business value to customers.

    Break Open the Black Box with Value Stream Management

    The black box of software development is, at its core, a communication issue. It’s on both business and technology leaders to bridge this communication gap. Business leaders need to demand more from technology leaders and insist on translating activity into business metrics. Technology leaders need to practice tying their efforts to tangible business outcomes to help justify their growing expenses.

    Of course, it’s helpful to have tools purpose-built to facilitate this visibility and communication.

  • Software Quality is the Heartbeat of the Best Organizations

    Software Quality is the Heartbeat of the Best Organizations

    JPMorgan recently announced it was hiring 2,000 engineers, despite the gloom in global economic markets. Is this not an odd risk for an organization to take, given the demand for (and cost of) software developers today? What’s happened?
    JPMorgan’s hiring drive is no mystery. Virtually every company in the world is leveraging software, with many transforming themselves into software organizations to drive new efficiencies, widen profit margins and create new markets. Software has been disruptive, so much so that the current era has been dubbed the “third industrial revolution.” Consumers are benefiting from switching providers at the click of a few buttons and most consume services through software. Bad software experiences today mean rapid customer churn and competitive disadvantage.

    Quality Should be the Heartbeat of any Organization

    In spite of quality’s importance, testing is still perceived as a secondary discipline and a check-the-box exercise. This reflects practices developed for assembly lines during the original industrial revolution. A product gets assembled and testers verify its quality as it leaves the production line. Testing’s goal in this context was to identify problems before they reach end-users. This same approach has been applied widely to software development and is still used by “waterfall” organizations.

    Yet, software development has been revolutionized by new methodologies and practices. Software today is constructed at incredible speed. Notice I’m using the word “constructed” and not “built”—the best developers leverage libraries or APIs to assemble software using existing components. They then add a few pieces of custom business logic to define the intellectual property of an application. Many organizations don’t even code software, instead customizing off-the-shelf software with vast configurations to modify functionality.

    The assembly-line approach to software development is no longer appropriate. When testing is left late, defects are found before a release or even in production. Release cycles are longer and products poorer quality. Yet, many organizations still stick religiously to this approach, with testing teams operating in distinct silos.

    The Role of the Tester is Evolving

    The best organizations in the world are changing how software is built. Testing is no longer a check-the-box exercise at the end of the assembly line. It is transforming into a discipline that revolves around evangelizing and driving quality throughout an organization.

    Quality should be baked in as early as possible, touching every artifact produced. Ideally, this should occur from the start, as a requirement is formulated, all the way through to the software being shipped. The idea of siloed teams working on different pieces is outdated. For quality to thrive, teams must collaborate.

    Modeling offers one approach to driving quality and collaboration throughout an organization. Its journey starts with a requirement. These are typically formulated by business analysts or product owners. Having been a product owner, I found that this usually involves lots of scribbles on paper before communicating to stakeholders on a whiteboard. The preliminary requirement then gets reviewed and refined.

    At some point, the requirement will be converted into walls of text in a project management tool. Modeling intervenes at this stage, adding visualizations that make requirements more consumable, less ambiguous and easier to understand.

    The word “modeling” may seem a scary concept, but it need be no more than a flowchart that encapsulates a requirement. The benefit of modeling is not only that it provides a digital collaboration asset; models can also generate coverage-focused tests before a line of code is written. Modeling creates requirements that are quality-driven and quality-driving.

    The Journey of Quality-Driven Requirements

    • Models Provide Data Upfront

    Developers today require rich data to develop, while testing is only as good as the available test data. Yet, many organizations still feed slices of production data into developers and test cases.
    This approach is problematic for several reasons. First, it often risks legislative non-compliance. Second, production data features large volumes of low-variant data. Data may not then be available when developing unusual-but-important scenarios. Imagine an overdrawn account with several beneficiaries: What should happen when a transfer is attempted?

    Modeling defines data explicitly in requirements. It allows engineers to understand a requirement explicitly, including the relevant data. From the modeled definitions, correct data can then be masked and subset, or generated synthetically. Data can further be delivered on-demand and at scale using database virtualization.

    • Models Provide Understanding

    Once the requirement and necessary data are available, code can be developed. Using text-based requirements, misinterpretations often lead to incorrect functionality. Visual models instead align closely with business logic, and we often see developers enriching models with additional context so that models align with the actual software implementation.

    • Models Generate In-Sprint Tests

    Once the code is developed, the same tests which were created earlier from the requirements can be executed against new functionality. This facilitates reuse and means the test cases are ready to be executed immediately.

    Some tests might further be selected for automation. In this instance, automation can be overlaid onto the requirements model, reusing code to generate scripts. These scripts then become part of the standard regression pack as new features are added to the product.

    A Change Request Comes In

    With iterative development, change requests are common. This typically creates havoc for quality, since it is difficult to understand the impact of a change, and time-consuming to update artifacts like tests and data.

    Traceability is key to overcoming this challenge. Models can connect to external DevOps tools to provide end-to-end traceability, from a requirement, all the way to code and tests. The impact of a change can then be identified directly. Models can be updated, automatically synchronizing test data, test cases, and automation to bring everything up to date.

    Testing for the Fourth Industrial Revolution

    Software is playing a vital role in virtually every organization, as already recognized by organizations thriving today. Baking quality in early is the only way to ensure quality software. The role of testing must change on a large scale. Models offer a way to achieve a “shift left” and collaborative approach to quality while testing earlier and more rigorously by automating and optimizing test and data creation.

  • How Automated Testing Closes the Development and Delivery Gap

    How Automated Testing Closes the Development and Delivery Gap

    For the past two years, companies have leaned into digital transformation projects to keep their digital offerings at pace with their in-person operations. Rather than become a stopgap, this digital approach became the new standard for the modern employee and customer experience. It also creates friction between a company’s development team and its user base. How long should customers wait for new or updated applications in our increasingly fast-paced business environment? Companies need time for development and testing to deliver quality products, but will the demands of their users force them to cut corners?

    Consider each stage of a customer’s journey. Visiting a website or app and putting something into the shopping cart is only the beginning. Behind the scenes, systems that monitor availability, sourcing, loyalty and promotions come into play. Following checkout and payment, there are systems for picking the product, packing it and delivering it with timely notifications along the way.

    Businesses find themselves in a bind when they have to decide which of those areas to cut back on. There’s really no good answer—enter the continuous delivery mindset. We like to say there is no continuous delivery without continuous testing, but those two areas are often at odds with each other.

    The good news is that there is a way to close the gap between customer demand and necessary development time: Test automation. Here are three ways that test automation can help companies satisfy both the needs of their business and their customers.

    Relieving the Testing Bottleneck

    Moving fast is becoming a competitive advantage for many companies. That speed-to-market opportunity has been heightened as cloud-based, low-code/no-code apps like Salesforce, MS Dynamics, Workday and Oracle have become an industry standard. Today, while plenty of development activities may be handled by low-code/no-code platforms, the test automation of these apps remains a high-code, high-maintenance activity.

    To keep from becoming a bottleneck, teams should plan automation and testing strategies early in the process. This is where continuous development includes continuous testing. Suppose companies can make test automation accessible to more people by removing the need for specialized knowledge and daunting technical constraints. In that case, they will be able to streamline ongoing development cycles.

    Ensuring Higher-Quality Output; Aligning Development and Testing

    One of the keys to putting out a higher-quality product is by adopting in-sprint testing, which aligns development and testing efforts. Each feature is tested and automated as soon as it is implemented so that teams can more easily catch errors early rather than at the end of a development phase.

    The automation also elevates the area of regression testing, as teams make sure new changes haven’t broken existing functionality. As automation moves into the mainstream, a wider range of collaborators become more involved in testing each additional feature.

    Creating a Better User Experience

    Historically, testing has been extremely focused on function and is very technical while user experience efforts remain focused on the stylistic and usability end of the spectrum. But creating satisfying end-to-end user experiences is a critical part of any application adoption, so the two sides should work toward a common goal.

    That common link lies in a company’s business processes. Each process is the starting point for building and designing a test scenario. From start to finish, everyone understands the user’s journey and works together toward making that path as effortless as possible.

    Conclusion

    Today’s modern customers don’t expect a measurable difference in experience between online and in-person. Expectations are at an all-time high, leading companies to push updates to their websites and apps more quickly and more frequently. As companies increase their dependence on software, the way to test that software is evolving to keep pace with development speeds.

    Automated testing can simplify and speed up the testing phase, catching many of the basic errors and leaving testers to focus on more complex functionality.

     

  • Bringing Development Environments Into the Modern Age

    Bringing Development Environments Into the Modern Age

    It’s time to rethink how we deliver distributed access to software development environments.

    We know how to write code. And there are plenty of well-established tools, techniques and processes for doing so.

    We know what kind of code to write: Functional, scalable and efficient code that’s inherently secure and that we can readily modify whenever and however we need to modify it.

    We know why we write code. We write it to enhance the value we offer customers, to expand our market reach, outperform the competition, cut costs, minimize risks and otherwise engage in what we call “digital transformation.”

    We know who writes code—or, more accurately, the various “whos” who write it. We need developers with a diverse range of skills. And as our needs keep changing, we keep adjusting the mix of in-house and contract developers accordingly.

    We also know when to write code—which is now and for the foreseeable future.

    The one thing we still struggle with is where to write code. Not ‘where’ in the physical sense; we’re way past that. We know that for development teams to be optimally productive, we have to enable everyone to work from any physical location at any time. COVID-19 has dramatically reinforced this principle.

    The ‘where’ we struggle with is the virtual ‘where’ of the developer workspace. Yes, we already provide developers with remote access to development resources. Sort of. But there are a lot—a lot—of problems with the way we do that. These problems adversely impact development every day by, among other things,

    • Bogging developers down in annoying technical problems that hamper their ability to set up their environments.
    • Forcing developers to wrestle with the maddening complexity of configuring and managing the multiple dependencies associated with each project.
    • Trapping developers in an endless cycle of building, terminating and recreating environments as projects begin, end and are resurrected for updates and enhancements.

    Unfortunately, we’ve become so accustomed to these problems that we tend to accept them as normal. But we cannot afford to accept them any longer. Here’s why.

    Development Environments: Insecurity, Lost Productivity and Technical Debt

    One big problem for both developers and the enterprise is that developer workspaces aren’t fully portable. The methods we use to give developers remote access to their environments invariably come with unacceptable insecurity. There’s also the issue of onboarding. When a developer joins a team—whether as a new hire, temporary contractor or current employee switching to another project—it can take days for them to get them fully up to speed with access to all the project-specific resources they need. That ramp-up time invariably frustrates developers.

    On the other hand, offboarding developers can be a security and compliance issue. Piecemeal provisioning of the multiple resources developers need inherently results in the piecemeal deactivation of those same resources. So when a developer quits or is fired—or when a contractor’s contract is up—we can’t be 100% certain that all their permissions have been revoked.

    Moreover, what happens when a developer needs to go back into a project that no one has touched in months or even years? How does a developer recreate the full workspace associated with that project and have high confidence that they’re doing it right?

    The answer is that we can’t. Instead, some unfortunate developer inevitably has to spin their wheels trying to piece together a long-dormant project. All your aging code is thus guaranteed to become “legacy” (which is just another name for ‘code no one is quite sure how to work on’), thereby guaranteeing that your organization will forever be burdened with an ever-growing mountain of resource-draining technical debt.

    The Shoemaker’s Children

    So how can we re-engineer the delivery of remote workspaces so we make life easier for developers while also fulfilling the security and compliance requirements of the enterprise?

    Here are a few ideas to consider:

    • Host developer workspaces in the cloud. Developers provide everybody else with a wealth of cloud resources, yet rarely take full advantage of the cloud themselves. Some resources they need may reside in the cloud, but the complete workspaces they require to be fully productive do not.
    • But why not? Everything a developer needs for every project should exist as a complete, unified, project-specific workspace that’s available to them anywhere—just like all the other SaaS solutions developers build for end-users every day.
    • And given the sophistication of today’s browsers, cloud-based workspaces can be made available to developers without requiring them to install a desktop client. The cloud also enables workspaces to be hosted anywhere to avoid latency delays.
    • Nothing should leave your secure workspace repository. Ever. To ensure the security of all developer work-product, no actual code or data should ever leave the hosting environment.
    • Only screen pixels and keystrokes should move across the network. This remote-access model makes developers’ workspaces fully secure and fully portable. It also provides the best protection against data exfiltration.
    • Simplify the definition and administration of project-specific workspaces. You don’t want developers looking around for tasks in progress, relevant datasets or process workflows. Instead, administrators should be able to configure workspaces that give developers access to all the resources they need for each project via a single sign-on (SSO).
    • Leverage containerization into your workspace hosting. Better, safer enterprise development isn’t just about re-engineering remote workspace access. It’s also about making those workspaces easier to manage on the back end. The best way to do this is containerization, which allows you to flexibly mix-and-match workspace elements. That way, you don’t have to build every workspace from scratch.

    And those workspaces don’t exist as monolithic, “all or nothing” environments that you pray you’ve gotten right. Instead, with containerization, you can build project-specific workspaces more quickly, at less cost and with less risk.

    Effective hosting of fully portable developer workspaces requires other important functionality as well: Inactivity time-outs, cloud cost/utilization controls, etc. Before addressing these details, however, development leaders must first come to terms with the fact that developers need a much better way to work remotely—and that every remote workspace must be a secure one.