devopsy.kinsta.cloud

Tag: custom software development

  • Jellyfish Adds Tool to Visualize Software Development Workflows

    Jellyfish Adds Tool to Visualize Software Development Workflows

    Jellyfish today unveiled a tool that identifies bottlenecks in software engineering processes using data the company collects via Git repositories and project management software from Atlassian.

    Krishna Kannan, head of product for Jellyfish, said Life Cycle Explorer provides managers with a tool that makes it simpler to identify the root cause of a process breakdown.

    Life Cycle Explorer goes beyond providing simple top-level metrics to calculate the time consumed at each stage of a workflow for any given process and then visually map it to surface trends, noted Kannan.

    That makes it possible to identify gaps, see where work areas overlap—indicating parallel processes—and drill into how outlier events may be impacting the overall life cycle of a development project.

    The launch of Life Cycle Explorer comes at a time when there is more focus on the efficiency of DevOps teams than at any time in recent memory. During uncertain economic times, organizations of all sizes are looking to optimize DevOps workflows to ensure maximum efficiency because many organizations are hesitant to hire additional full-time engineers.

    The important thing to remember when analyzing DevOps workflows is there is no such thing as the optimal “Goldilocks” workflow that can be universally applied, noted Kannan. Instead, most DevOps leaders will discover one team excels at one segment of a DevOps workflow while others are more efficient elsewhere. Life Cycle Explorer makes it easier to identify those best practices in a way that makes them simpler to replicate when appropriate, said Kannan.

    Life Cycle Explorer follows the addition of a benchmarking tool and DevFinOps offering that addresses cost capitalization reporting for research and development. The core Jellyfish engineering management platform is designed to ingest data from the tools an organization already uses to build applications and then applies proprietary algorithms to create a comprehensive view of workflows across an organization. The challenge many organizations encounter today is they often lack visibility into workflows that have each been individually constructed by a diverse range of DevOps teams working on very different types of software projects.

    At the very least, DevOps teams need to establish a baseline that surfaces the current rate at which software development occurs. Once that baseline is established it then becomes possible to measure the impact changes to software engineering practices are having. Today many organizations make educated guesses about what changes are needed without really understanding the impact they might be having across the entire software development life cycle.

    Of course, it will be up to each organization to determine the degree to which they want to measure workflows. The Jellyfish platform makes it simpler to identify workflow issues, but there are also value stream management (VSM) platforms that track the impact software engineering workflows are having on specific business goals. Those VSM platforms are typically much more challenging to implement and maintain. The Jellyfish approach focuses more narrowly on improving the efficiency of DevOps teams.

    Regardless of approach, things that are not measured are not being managed. At a time when organizations are more dependent on software than ever, the need to manage software development life cycle as efficiently as possible has become a lot more important.

  • Survey Surfaces Agile Development Challenges

    Survey Surfaces Agile Development Challenges

    A survey of 3,220 software development professionals published this week found that among the 80% of respondents that embraced Agile practices for building software, just under half are tracking on-time delivery (47%) and business objectives achieved (44%).

    The survey, conducted by Regina Corso Consulting on behalf of Digital.ai, a provider of a value stream management (VSM) platform. The survey also found a total of 19% of respondents were not sure what metrics were used to track software development progress.

    At the same time, 40% of respondents noted they are dissatisfied with Agile at their organization; a clash with company culture was listed as the leading cause (41%) of unsuccessful delivery. Half of respondents use a combination of Agile, waterfall and/or iterative processes, but 27% noted this combination of frameworks was a struggle for them.

    The survey also noted that just over a third of product and application owners (36%) that participated in the survey have adopted Agile.

    Derek Holt, general manager of Agile and DevOps at Digital.ai, said that percentage suggests that Agile principles are now being adopted beyond the engineering teams that construct software. As that appreciation for Agile principles continues to grow, the organizations these individuals work for also tend to start tracking value stream metrics, he added. That transition typically begins with a few pragmatic metrics before the organization matures enough to justify the adoption of a VSM platform, Holt noted.

    In time, however, that VSM platform not only helps organizations identify bottlenecks but also identifies potential quality issues and risks to the business, Holt added.

    Overall, the top three top Agile development priorities identified by respondents are to accelerate time-to-market (52%), delivery predictability (44%) and lower risk (31%). However, from a business perspective, the top three priorities are company goals (54%) and end customer satisfaction (43%) followed by time-to-deliver (35%).

    More than half (51%) of respondents, however, also noted that DevOps teams are not incorporating business feedback regularly. Well over half (58%) said the most valuable improvements to DevOps teams would be end-to-end visibility and traceability from business initiative through development, test and deployment to end users, while 55% said the ability to measure cycle time, wait time and bottlenecks would be an important improvement.

    Regarding Agile tools used, Scrum led the pack at 87%, followed by Kanban at 56% and Scrumban at 27%. The Scaled Agile Framework (SAFe) framework has been adopted by more than half of respondents (53%), while Scrum@Scale/Scrum of Scrums was adopted by 28% of respondents followed by Lean Management at 8%, according to survey respondents.

    The top benefit of Agile is increased collaboration (69%) followed by better alignment with the business (54%) and better work environment and increased visibility in the application development life cycle at 39% each.

    The debate over the merits of Agile frameworks, of course, remains fierce and no two organizations may ever have the same level of adoption. However, as the pressure to deliver quality software faster in the age of digital business transformation continues to mount, the more crucial it will become to align Agile and DevOps best practices.

  • Looking to the Future of Developer Experience

    Looking to the Future of Developer Experience

    Developer experience is where it’s at! Developer experience (DX) means taking a user experience approach to the developer journey. DX (also abbreviated as DevEx) is commonly applied to areas like documentation, sandbox environments, SDK ergonomics and more. By improving a developer’s experience with a tool, software providers can increase stickiness and retain more users.

    Nowadays, having a sleek developer experience is a competitive advantage—especially since developers often have the discretion to purchase new tools. And amid an ongoing skills gap, maintaining quality DX for internal software ecosystems is also important to retaining happy engineers and avoiding burnout. All these factors mean developer experience is becoming a C-suite objective. So, where is DX heading? How will the developer workflow change in the near future?

    I recently met with Ash Arnwine, director of developer relations, Nylas, to ponder what’s on the near horizon regarding developer experience. According to Arnwine, DX is still a very new concept. Yet, it has become an integral aspect of positioning modern software, especially for public-facing SaaS, and will undoubtedly drive purchasing decisions in the year ahead. Below, we’ll share some predictions of how DX will evolve within four general categories: onboarding, building, deploying, and maintaining.

    State of Developer Experience

    First off, what is the state of developer experience within the tech world at large? Well, Arnwine is quick to note that the concept is still relatively nascent. “Developer experience was something that we didn’t talk about that long ago.” Yet, the idea is growing in mindshare as developers exercise greater control over the software life cycle.

    In fact, the 2022 StackOverflow survey found that 66% of professional developers have at least some influence over their organization’s purchases of new technologies, up from 56% in 2020. Furthermore, the way developers learn is changing. The new generation of programmers is primarily self-taught, relying on coding bootcamps or other online resources. An impressive 70% of developers learned how to code from online resources.

    What we end up with, said Arnwine, is a growing developer population with a much wider range of skills than in the past. And since no one is there to hand-hold them, the technology itself must be usable and intuitive—the onus is on the software provider to craft frictionless self-service workflows. And with developers’ growing influence in purchasing, DX becomes a competitive advantage and an executive talking point, said Arnwine.

    Onboarding

    Developer experience is a broad topic, but it’s most often associated with the time it takes to get started with a tool. This is often referred to as ‘Time to First Hello World.’ But although it’s an important step, the metric might doesn’t always carry much significance. Time to value, on the other hand, said Arnwine, takes this a step further and is a better gauge of success.

    For example, onboarding to a web API would likely involve the signup process, creating an account, getting API keys and perusing the documentation—all before a first call is sent. According to Arnwine, there are techniques to apply at this stage to help developers move faster throughout the onboarding process to reach value sooner.

    Here are some ways in which developer onboarding is becoming more streamlined:

    • Automatically generating keys upon signup.
    • Providing a terminal within the developer dashboard to test sample code.
    • Handing developers the code they need to be customized to their specific stack.
    • Using specifications as a single source of truth for documentation.

    Building

    What can SaaS companies do to help improve DX while building? Well, one way is to enable auto-complete within IDEs. When developers onboard with a new tool, they are often handed an SDK and reference documentation. But, it doesn’t add value to send programmers back and forth between a browser to look up method names. Instead, Arnwine believes developer tools should be “baked into the IDE in a way a modern developer would expect.”

    One example of auto-complete on steroids is Fig, a next-gen command line that supports auto-complete for over 500+ popular CLI tools. Taking this a step further is GitHub Copilot, an AI assistant that can take natural language prompts and generate pretty complex code suggestions. The industry appears to be heading toward more AI-fueled low-code software development—a trend that could significantly improve a developer’s experience during the construction process.

    However, one potential downside of increased software development automation is ensuring the AI suggests correct code snippets. Thus, Arnwine said he anticipated possible troubleshooting and debugging problems. Furthermore, SaaS providers will have to vet systems that generate glue code to ensure it’s accurate and up-to-date with the latest versions. His advice to SaaS providers is to meet developers where they are, but do their best to maintain a quality experience that they can control.

    Deploying

    For a long period of software development history, IT administrators were the only ones able to deploy software. The old-school method required getting a hosting provider, installing Ubuntu and plenty of other legwork. Nowadays, however, software deployment has become far more drag-and-drop. DevOps has become more democratized in recent years, and we will likely see greater usability emerge in the years ahead.

    One way to increase developer experience for deployments is through more custom automated routines via GitHub Actions or similar event-based systems. And plug-and-play pre-built actions could reduce the barrier to using such systems. Such connectivity is necessary to enable a docs-as-code approach, said Arnwine.

    Maintaining

    Another area that could use a serious developer experience upgrade is dependency management. Software dependencies go through a life cycle. They are versioned, updated, retired and sometimes replaced outright. As such, keeping track of an evolving surface area of third-party dependencies can be a headache. To make matters worse, software supply chain threats have complicated the integrity of many open source dependencies consumed by most applications.

    Although it’s imperative for organizations to maintain parity with dependencies, a single person is rarely tasked with continuously checking dependencies and monitoring for security threats. Therefore, more automation for dependency management and security monitoring is necessary. For example, Arnwine uses Snyk, which sends a weekly report on the state of his dependencies.

    Final Thoughts

    Assuming you have the killer functionality to back it up, an investment into developer experience can help a developer tool stick out in a crowded marketplace. But of course, improving the DX means many different things depending on your context. It could be a subtle user interface tweak, adding relevant code samples or making your documentation more intuitive.

    On the other hand, a negative developer experience can turn away potential users and cause frustration throughout the application support life cycle. This can instill a poor reputation among programmers.

    To review, in the near future, we’ll likely witness the developer experience evolve in the following areas:

    • Enhanced methods that streamline the signup process.
    • Auto-complete and AI-driven code suggestions that understand a developer’s stack and meet them where they work.
    • More intuitive, automated deployment models.
    • Increased automation around the maintenance of dependencies.

    While developer experience is a growing concern, it shouldn’t be the only measurement of a SaaS — the ongoing value it brings developer consumers and end users is just as (if not more) important to consider.

  • Why IT Teams Need Continuous Improvement

    Why IT Teams Need Continuous Improvement

    In the dynamic world of software delivery, an ‘if it’s not broke don’t fix it’ philosophy won’t get you very far—even when your software and systems are working as planned. 

    Software is more complex than ever and innovation is exploding across markets. To keep up with constant innovation from your competition in a global marketplace, you should always be thinking about how to improve your products and services. 

    The teams and organizations focused on continuous improvement simply outperform those who settle for the status quo and fear the unknown. Let’s look at why continuous improvement is important in IT organizations; how to avoid common mistakes when measuring success and tips for getting started. But first, let’s define what continuous improvement is.

    Defining Continuous Improvement

    Continuous improvement is incrementally improving a project or process several times based on feedback. Feedback can come from various sources, including users and automated testing.

    Advantages of Continuous Improvement

    Making small changes over time offers many benefits when compared to a “big bang” change. Often, a “big bang” change is made with little to no feedback until it is almost too late. 

    By making smaller changes, a team can try something, listen to feedback and adjust. If a change is poorly received by end users, little time was spent working on it, so it can more quickly be completely reworked or scrapped altogether. This encourages experimentation with the safety net of knowing nothing is permanent.  

    Think of it like swimming from one end of a murky lake to another. You could dive underwater and not come up until you hit land and, hopefully, you are in the right place. Or, you could periodically pop your head above water, check your bearings and adjust course.  

    Who Benefits?

    Today, it’s hard to imagine a situation where IT teams wouldn’t benefit from adopting a continuous improvement methodology.  Any IT team whose responsibilities include writing software and delivering it to users benefits from continuous improvement. Smaller, incremental changes generally mean a smaller risk of something going wrong. Making a small change to a piece of software or tweaking the software delivery pipeline to shave 30 seconds off the time it takes for each deployment environment adds up over time.

    What do IT Leaders Get Wrong?

    Continuous improvement is all about incremental changes over time to streamline workflows and cut back on waste. In the moment, those changes and improvements can be very subtle, making them harder to justify. When IT leaders don’t look at the big picture, it’s easy to miss how these small changes contribute to overall improvement.  

    For example, let’s say a team is completely focused on measuring deployment time. But the first fully automated deployment to production took just as long as a manual deployment. With a proper feedback loop, the team sees that it took just as long because there were a few misconfigured items. The next deployment takes less time, but only by a few minutes. 

    Each subsequent deployment takes less and less time. But it took several months and multiple attempts to go from two-hour manual deployments to 15-minute automated deployments. With an intensive focus on deployment time, this may not seem like a significant improvement given how long it took to get there. However, in this scenario, the team was so focused on deployment time that it missed other important measurements, such as the number of emergency fixes created after the team started automating the deployment. 

    If they examined those numbers before automation, they would have realized that they pushed out a handful of emergency fixes after a manual deployment—but, almost overnight, those emergency fixes stopped after introducing automation. Critical measurements and improvements like these are easily overlooked when leadership focuses too narrowly and avoids the “big picture” view.

    Getting Started

    When working in IT, there are many problems to solve with a finite number of people and limited time to fix them. It’s tempting to try and solve the problems at the same time. After all, you are only making small changes. 

    However, for real change to occur, you must make several small changes over time. Pick one or two problems to solve and focus on them until you reach a good stopping point; then, move on to the next problem.

    Also, know what and where to measure. With data in hand, you can take an informed approach to designing improvements. Never settle for thinking there are no further improvements because, inevitably, you will be proven wrong when your competition does it better and faster. 

    Ensure that your organization or team is dedicated to lifelong learning, perhaps by experimenting with chaos engineering to see how the system responds. This will spark important conversations and justification for improvement, as well as invaluable feedback. 

    Every IT organization benefits from adopting continuous improvement and will find that it promotes innovation and helps maintain a competitive advantage. It is easy to take too narrow a view of the small changes. But with a high-level, strategic view of continuous improvement, leadership will see the benefits. 

  • Choosing the Right API Solution

    Choosing the Right API Solution

    There are more choices than ever when it comes to APIs–and that’s a good thing. But it also means you’ll need a strategic plan for choosing the right API solution.

    Two questions I’ve found can help guide that decision: 

    1. What problem are you trying to solve right now? 
    2. What functionality will you need in the next five to 10 years? 

    Once you’re clear on the answers, you can evaluate API solutions based on the following five criteria to choose the one best suited to your needs.

    Performance

    In a highly competitive global market, it’s not enough to have reliable uptime. Speed also matters–a lot. A site that loads in one second has a conversion rate three times higher than one that loads in five seconds.

    To accommodate current customer expectations for page speed, API response time should be no greater than 90 milliseconds. One way to blazing-fast API speeds is to take a client-side approach where data is delivered to an edge node of a CDN network instead of stored on a server somewhere in your data center.

    But let’s return for a minute to the first question I introduced above: What problem are you trying to solve? If you’re an online retailer, you want your site to load fast so your customers don’t click away and you want everything on it to be accurate–for example, if an item sells out while a customer is browsing, they shouldn’t be able to put it in their cart.

    Not every function requires the same level of speed. Product description content, for example, is mostly static, while inventory is not. So content delivered by your CMS’s API may not require the same speed as data from a transaction engine. 

    While high performance is important for every API you use, the actual performance benchmarks each one needs to meet vary based on function and on the end-user problem you’re solving.

    Documentation

    Thorough documentation is a must-have for any API solution you adopt. Without thorough documentation, your team will be forced to figure out how to use the API via trial and error supplemented with time-consuming support interactions. Strong documentation lets developers use APIs more effectively and, ultimately, ship products to market faster.

    But even among providers that offer thorough documentation, there are more and less helpful varieties. I’ve read plenty of documentation, for example, that is written with the assumption that the person reading it already understands how the API works. This makes it harder for newer developers to learn and understand the capabilities of an API.

    As you consider providers, look for those with documentation written for someone who is totally new to the API–which you and your team will almost certainly be. As a stylistic guide, look to documentation from Mozilla, MDM and W3 schools, which I think do an excellent job of communicating for non-experts.

    To gauge the helpfulness of a potential provider’s documentation, I recommend having your team read some of it and asking the partner team how often they update it. A best-case scenario is that they consider documentation an ongoing project that will never be complete.

    Security

    Security is pretty self-explanatory, so I won’t spend a ton of time on it here. Any API provider should offer robust security to ensure that the API cannot be used nefariously by bad actors or hacked to expose sensitive information. REST APIs almost always follow standards like 0Auth and TLS to maintain security. It’s worth looking at how the API you’re using describes its security practice.

    Flexibility and Extensibility

    Your team should have the freedom to create whatever they want with the APIs you use, meaning they shouldn’t be hampered by roadblocks in the API’s design. This freedom to create should exist in all aspects of the API: It should let your team create whatever customer experiences they can dream up, and it should let you manage back-end information in whatever way makes sense for your organization.

    In other words, an API solution should be well-defined but should not define everything you can do with it.

    Pricing Model

    The final piece to take into consideration is the API’s pricing model, by which I mean not only its actual cost but also the way the provider charges to use its service.

    For example, does it charge by order? By bandwidth? By number of records? Again, this comes back to the problem you’re trying to solve: If you have a lot of requests to make, for example, don’t choose a service that restricts requests per minute.

    And even if a pricing model works for your business today, will it work as you scale? This question brings me to my final thought.

    API Solutions Should Make it Easy to Grow and Evolve

    I started this piece with two key questions to guide the process of choosing API providers: What problem are you solving and where is your business going?

    If you’re exploring APIs as part of a replatforming project, there’s a good chance you chose a platform 10 years ago that could do everything–but that can’t keep up with evolving customer expectations or that restricts your team’s creativity today. The APIs you choose should let you meet current needs and make it easy to make changes–including swapping one API provider for another–as your needs evolve.

    In other words, when you choose the right API solutions, you should never need to do another replatform.

  • Forget Automation: Why IT Should Take UX Cues From Fine Dining

    Forget Automation: Why IT Should Take UX Cues From Fine Dining

    As a college student, I worked at a five-star Italian restaurant where I learned the discipline and practice of customer service. The general manager knew exactly which corner to stand in to get a view of every single table during service. They would gauge diners’ experience according to how they were interacting, their microsignals, how much food was left on their plate and the way they glanced around the restaurant. What does this intense attention to detail and individual customer experience have to do with running a service-oriented technology business? Everything.

    The tech industry is notorious for automating processes at the expense of personalization, and that aversion can extend to building the relationships necessary to produce a successful end product. Understandably, some companies and their developers prefer to keep relationships with their clients strictly functional because these connections are messy, people are unpredictable and nothing ever goes completely according to plan. It’s a dance we have to do over and again with every new client and project. 

    For those of us who wish to function as service-oriented tech companies, keeping on top of client and customer experiences requires us to stay attentive and listen with active care. Just like the veteran restaurant manager, we have to constantly scan our environment for cues of satisfaction and dissatisfaction.

    Service is More Than an End Product

    Before opening every night, the general manager would make staff hold long pieces of string to measure the angles and distance between tables to ensure they were straight and the edges perfectly aligned. Then, after telling staff the evening specials, he would randomly quiz them about the menu. What color is a fava bean? 

    Seeing the value of such old-school standards left a deep impression and helped me embed attention to detail as a foundational practice across the board, from designing good UX to cultivating relationships. Creating a desirable environment is about successfully orchestrating a million tiny details and always looking for tweaks to make the customer experience better. 

    That seemingly omniscient Italian from my earliest experience in the restaurant industry also taught me that being empathic goes hand-in-hand with the hard-nosed realities of running a service-oriented business. They showed me how to take care of people, how to make them feel good and how to read body language. 

    It might be easy to stereotype tech companies as impersonal dispensers of products (and their developers as cogs in the machinery), but we don’t want to just take orders. Our job is to become strategic partners from the ground up for long-term success, and that requires constant care and continual adaptation. 

    Mapping the Client Experience

    We must be willing to redesign how we work with customers and end users over and over again—it’s always changing because expectations are always changing, and market norms are always changing. The moment that we stop trying to get better through small incremental improvements is the moment we stop being service-oriented.

    In the same way that a restaurant has a sequence of service that maps a diner’s journey from the moment they enter the door, we can architect a customer experience from every touchpoint. 

    In the sales process, it’s valuable to layer in different people to create more relationship touchpoints throughout an organization, so, in our case, a new client meets a member of our operations team and then somebody from our engineering team in order to ensure that they feel fully supported. Then, we set expectations in terms of communication as part of a scripted onboarding experience. In our review meetings, we seek feedback to determine whether we have under-delivered and course correct if necessary. 

    The other thing I learned from that Italian restaurant is that no mistake is irredeemable. It doesn’t really matter if you get it right or wrong the first time, it is how you respond when the unexpected happens that matters. Turning a situation around after making a horrible mistake—even sending out a cold steak—can breed even more loyal customers because it demonstrates that you really care.

    The Creative Heart of Service

    Despite the image of tech as cold and distant, it’s important to recognize that coding and development itself is creative and we should seek to nurture a healthy environment so that people can perform at their best. To that end, it makes sense to think of your responsibility as running the entire length of the chain, from employees to clients and, finally, to end users. Finding humanity in the work along each link is key to building successful partnerships. 

    In the context of building products, we must be creative to design seamless, curated experiences for end users. There are plenty of apps that sit on someone’s phone unused before ultimately being deleted. The only way to grab the attention of people that share the same interests and problems is by understanding their needs. 

    To that end, we must always be asking our clients: What is the easiest point of entry for the user? Creating a low barrier is a quick win that in and of itself is an onboarding experience and an opportunity to build trust. 

    Equally, what may make one customer happy may not actually have any resonance in the wider market. If customers were only hiring us to write code, we would only be interested in meeting their expectations. The goal is not just to build products, but successful products that establish or reinforce a client’s reputable presence in the marketplace. 

    Adding Value Through Relationships

    When we stand in our metaphorical corner of the room to observe the customer experience, we are consolidating data from products that have millions of users and harvesting insight. We are not interested in quick fixes. Customer service and a focus on the end-user experience means being oriented to what the market wants, not designing in a vacuum. We can then continue to build value over time.

    In the restaurant business, the little surprise at the end of dinner adds value because it is unexpected. A complimentary after-dinner liqueur with a pithy origin story is a point of detail at its finest. Creating a richer, fuller customer experience can set a tech business apart in an exploding marketplace. For my old mentors, paying attention to every nuance from the beginning to the end is what defines five-star service.

  • Cosmonic Previews Deployment Platform for Distributed Wasm Apps

    Cosmonic Previews Deployment Platform for Distributed Wasm Apps

    Cosmonic has made available a preview of a platform for deploying applications built using the portable WebAssembly (Wasm) binary format that enables applications to be deployed on any platform.

    Cosmonic CEO Liam Randall said the company is providing early access to the Cosmonic Platform Developer Preview platform to enable developers to experiment with a new type of software artifact that will be used to build a new class of cloud-native applications.

    The Cosmonic Platform Developer Preview platform is based on wasmCloud, an open source application runtime that hosts components written as Wasm modules that can then be loosely connected to build applications. Originally developed under the auspices of the World Wide Web Consortium for building browser applications, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment.

    That approach replaces the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct boundaries. It’s that lack of distinct boundaries that enables malware to flow so easily from one software module to another. The wasmCloud runtime, originally developed by Cosmonic, provides a platform for deploying distributed Wasm applications and is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    Prior to Wasm, Randall noted, every format for building applications led to the creation of ‘walled gardens’ that resulted in developers being locked into a platform. Wasm is the first software artifact that enables applications to run on an platform, including Linux and Windows, without any modification required, said Randall.

    It may be some time before Wasm becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are about to crumble. Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. Just as importantly, those applications will run in a memory-safe sandbox that is more secure than what can be enabled in legacy IT platforms. In fact, as more organizations review the security of their software supply chains, they may decide to accelerate their embrace of Wasm to build more secure applications.

    Naturally, the transition to Wasm will have major implications for DevOps teams, as it represents an opportunity to streamline deployment processes across multiple platforms. In effect, the total cost of application development and deployment would decline as processes spanning multiple platforms become more automated using platforms such as wasmCloud. Ultimately, much of the infrastructure complexity that developers need to navigate today would be eliminated, noted Randall.

    It’s not clear just yet to what degree Wasm will drive a transition to another era of computing, but the potential to change almost every aspect of IT is on the horizon. Ultimately, the issue will be decided by how quickly developers are willing to embrace yet another software artifact for building and deploying applications. What is clear is that the number of platforms that will make it possible to experiment with Wasm are starting to multiply.

  • To Build a Durable SaaS Business, Rethink Your Product Roadmap

    To Build a Durable SaaS Business, Rethink Your Product Roadmap

    During a tech downturn, with enterprises cutting their subscription software budgets and VC funding drying up, SaaS businesses are increasingly shifting their strategic focus from growth to resilience. 

    The standard startup playbook—hunker down, cut burn rate and hope the market improves before you run out of runway—isn’t the right path forward for SaaS businesses. Instead, the key to durability is to lean into efficient growth. By revamping their product strategy, companies can lower the cost of customer acquisition with low-touch onboarding strategies and also increase revenue retention with stickier products, helping to unlock new ways to scale up and sustainably grow revenues. 

    Implementing this approach requires a fresh approach to your product roadmap—because when you scale through retention and expansion, the primary goal is maximizing utility for existing customers so they’ll increase usage and be willing to spend more over time. That means prioritizing core features and usability and not tacking on new features in a bid to draw in new customers with adjacent use cases.

    Getting that right, in turn, requires SaaS leaders to leverage the product itself as a key to understanding which features need attention, as well as a messaging channel and conduit for two-way communication with end users so you can influence user behavior and collect user feedback. Here are four steps that product managers can take to drive durable, resilient growth for their companies:

    Get Serious About Analytics

    Every business wants to use data to drive better decision-making—but many organizations fail to realize that their own product is their most potent source of data. Unlike web analytics which show only the behavior of random web users, product data has the power to help you understand the user journey, what they’re finding useful, what they’re struggling with—and how you can create value to keep them coming back for more.

    That makes product analytics—data showing how your product is being used, along with user surveys, messaging and other more qualitative measures—a powerful resource as you seek to anchor your development roadmap in the things your customers actually need. Armed with user feedback, it’s possible to learn how your customers feel, understand what’s missing—and invest in improvements that align with your users’ evolving needs.

    Stay Focused on Stickiness 

    Your analytics dashboard should have a strong focus on your stickiest features—the ones that keep users coming back for more. Those will include your product’s key value drivers during the early evaluation stage when you’re looking to hook new customers and turn their curiosity into a compelling use case for your product. But they will also include outcome-related features that enable established customers to measure and increase ROI as they scale up. Finally, they will include features that directly drive organic expansion, such as collaboration functionality that drives users to invite colleagues to use your product.

    Product managers (and their bosses) naturally get excited about new features—but by taking a data-driven look at stickiness across the whole customer life cycle, it becomes easier to identify opportunities to innovate around your core functionality and make it more integrated, scalable and productive. Customers won’t renew or expand their contracts because you rolled out a shiny new feature—but they will keep renewing if your team keeps investing in making their outcome-driven features the best they can possibly be so they can be successful at their job.

    Make Space for Quick Wins to Drive Advocacy

    If you view your roadmap as a waitlist for dev resources, it’s tempting to simply add newly identified usability bugs or hiccups to the bottom of the list, and circle back to them months later once your team is done working on building out new features. But in the end-user era, users control the renewal decision, so customer satisfaction isn’t a nice-to-have—it’s something you have to make time for to build and grow a durable business. That means pre-allocating time and resources for quick fixes and small enhancements that reduce friction, eliminate pain points with core features and drive stickiness for existing users. 

    As you track user experience across your stickiest features, you’ll find errors and pain points that need to be remedied promptly to keep your users happy. These are hard to plan for because they’ll emerge on a daily basis based on usage data and user feedback—so the key is to proactively assign resources to address these unplanned issues and turn them into quick wins, enabling you to iterate quickly rather than risking user frustration by adding core-feature fixes to your standard product roadmap.

    Influence User Behavior 

    User enablement is sometimes underestimated by product teams, but the shocking truth is that most customers won’t carefully read through your release notes in search of new features. In fact, they may not even notice your newly released functionality—and those that do might still struggle to understand how that feature supports their core use cases or to intuit the best practices for using it effectively. 

    To increase visibility into new features, you need to leverage in-app messaging, enabling your core users to unlock new functionality in an optimal way so you can capitalize on your product investments. As part of every release process, invest in user enablement by creating effective in-app communication with links to articles and videos that can help users adopt features successfully. 

    Invest in Revenue Drivers

    Of course, focusing on stickiness doesn’t mean slamming the brakes on all new features. The key is to use product data to ensure that innovations aren’t coming at the expense of core-feature usability. Before signing off on a new feature, make sure you have a hypothesis on how it will drive revenues—and remember: Innovative new capabilities might attract a subset of early adopters, but during a down economy your customers care more about must-have features than about nice-to-have add-ons. 

    Be sure to weigh a feature’s projected value—for your users and also in terms of revenues—against the cost of maintaining that feature over time. Every company has a finite amount of dev-hours to dedicate to perfecting its product, so even revenue-positive features can prove a drain on resources. Be realistic about what you can manage and don’t sacrifice long-term stickiness for short-term innovation.

    Remember Your North Star

    To make the right decisions during tough times, every SaaS business needs to focus on its North Star. For product managers, that means taking the time to understand—in a granular, data-driven way—exactly what makes their SaaS product worth paying for. Real resilience comes from leaning into those things and scaling by optimizing the user experience to make the product as sticky as it can be.

    Building durable and resilient SaaS businesses isn’t just about belt-tightening. It requires a commitment to scaling through the product and using it as a vehicle to drive retention and expansion by increasing value across your core features in ways that keep customers coming back for more. That, in turn, requires a fresh approach to your roadmap—because more than anything else, the way you understand and invest in your product will determine your company’s success or failure during the tough times that lie ahead.

  • What Devs Need to Know About R&D Tax Credits

    What Devs Need to Know About R&D Tax Credits

    The research and development (R&D) tax credit was created to reward innovative companies for building and improving products and processes, including software development. Yet software companies often overlook claiming this lucrative credit. Less than one-third of eligible companies take advantage of R&D tax credits from the U.S. federal government. While the software development community may already be aware of R&D tax credits, they often lack the knowledge and resources to make the most of the system. If you’re a software developer thinking of starting your own company or building your own application or you work for a company that would benefit from the credit, here are three important pieces of the R&D puzzle you should know to optimize and defend their R&D tax credits.

    The History

    Each year, the federal government provides billions of dollars to businesses that develop and improve technologies, products and processes. Beginning in 1981 as part of the Economic Recovery Tax Act, the federal government allowed for a temporary tax credit of up to 13% on spending for qualified research on products and processes that have been developed or improved through the application of either the physical sciences, biological sciences, computer science or engineering. This can include costs associated with developing a patent, a new product or service offering or even a new technology that is sold to third parties or used internally within the business.

    In 2015, the Protecting Americans from Tax Hikes (PATH) Act permanently extended the R&D tax credit and expanded its benefits to startups and small businesses. Early-stage businesses can use the credit to eliminate up to $250K per year in federal payroll taxes.

     The Required Documentation: Meeting the Four-Part Test

    While the benefits associated with the R&D credit are significant, documentation is crucial. Historically, the cost and work involved in meeting the documentation requirements has kept many businesses from participating. Fortunately, IRS regulations outline a straightforward four-part test that creates a fairly low bar for qualification. As you read the test, you can see that the development and testing–even time spent questioning if the advancements might work–are things that should be considered.

    1. Permitted Purpose: Are you developing or improving a product, process, formula or software?

    2. Technological in Nature: Is your work within physical or biological sciences, engineering or computer sciences?

    3. Elimination of Uncertainty: Are you asking questions like, “Can we develop it?” or “How do we develop it?”

    4. Process of Experimentation: Are you systematically evaluating one or more alternatives?

    Examples might include:

    • Designing and developing new or improved technologies, algorithms, applications or databases

    • Platform design and testing

    • Compiling, programming and testing software source code

    • Newly developed techniques (architecture, algorithms, databases)

    • Software and hardware development to further communication/interaction

    • Image processing, AI and other specialty tech design

    • OS development

    • Creating mockups, UX design or technical design work

    • Testing automation to ensure quality during development

    • Establishing functional relationships between software modules for internal use or to better serve clients

    • Developing feature enhancements

    • Improving internal processes and conducting QA testing during development

    Although meeting the four-part test can be relatively straightforward, documenting it appropriately can be cumbersome. Technology can help streamline and simplify the process of claiming the credit.

    The Applicability

    External Vs. Internal

    The government has different qualifications for different types of software development: External use/third-party software (like Microsoft) versus internal use software. Internal use software has stricter requirements in addition to the four-part test above, and must meet these extra criteria to be claimed for the credits:

    1. Software must be highly innovative.

    2. Similar products must not be available commercially.

    3. Development must introduce significant economic risk.

    The R&D tax credit is available mostly on wages paid to employees who carry out the R&D work, as well as a part of the wages of contractors who carry out R&D work, as long as they are not based outside the U.S.

    Other items to note:

    • The company must own the intellectual property rights to the software being created.

    • Funded research is not considered for an R&D tax credit.

    • Qualified expenses can range from supplies to cloud computing costs and costs associated with offsite servers.

    • Both traditional IT coding and low-code platforms can be claimed under the tax credit. Low-code and no-code platforms allow businesses to build solutions without major coding investment using flexible templates that increase the experience and overall efficiency.

    If you’re a software developer thinking of starting your own company or building your own application or you work for a company that would benefit from the credit, it’s a great time to consider taking advantage of it.

  • Why App Dependency Mapping Is Critical for Cloud Migration

    Why App Dependency Mapping Is Critical for Cloud Migration

    Software dependencies are a crucial part of efficient, component-based programming. At the same time, they can be a hurdle for fast-paced agile development teams, because they can make it more difficult to deploy, update and migrate software applications. Many applications have dozens or hundreds of dependencies, each with its own transitive dependencies, making the problem worse.

    Dependencies are components that provide required functionality that a main component depends on. They can be incorporated into code using package managers like npm or Maven, Git-based code repositories like GitHub and container image registries like Docker Hub. 

    Application dependency mapping involves discovering and identifying dependencies and interactions between application components, their dependencies and underlying infrastructure. Creating a map of application dependencies is an essential part of gaining visibility over complex application structures and understanding the impact of deploying them in different environments.

    Why Application Dependencies Are Critical for Cloud Migration

    Application dependency mapping ensures you have identified all the components you must migrate to the cloud. You may not need to migrate all components to the cloud, but you do need to ensure all dependencies are identified and migrated together. Otherwise, your application may suffer performance issues because important dependencies remain on-premises.

    For example, if you move an application server to the cloud but keep the application’s database on-premises, your application will experience severe performance degradation and may also cause related applications to fail. Once a dependency is disrupted, all related applications suffer. Therefore, when migrating applications to the cloud, you must include all associated dependencies. 

    How Application Dependency Mapping Tools Can Help

    Application dependency mapping can help you avoid poor application performance and service outages. It is a critical component of the migration process, but is also difficult without automated tools. Application dependency mapping tools check an application and help with the following:

    • Modeling all inter-server relationships 
    • Identifying inbound and outbound connection latency
    • Determining the necessary TCP ports
    • Detecting running processes 
    • Application performance monitoring over time

    Cloud vendors offer specific application dependency mapping tools developed for their environments. For example, Amazon Web Services (AWS), Google Cloud and Microsoft Azure offer proprietary tools to help manage this process. However, these tools are tied to each provider, which means you should use the vendor tool that matches your chosen target cloud environment.

    Alternatively, you can use open source tools that provide similar services but are vendor agnostic. Use these tools if you want an assessment that is not specific to a single cloud vendor environment.

    Mapping Application Dependencies to Prepare for Cloud Migration

    An application consists of a hierarchy of dependent APIs and tools. The hierarchy starts with the application’s interfaces and then goes down through platform tools. Dependency management helps identify combinations of related versions and ensures that the development team recognizes new application dependencies when changes occur.

    Versioning application components

    The first step in this process involves versioning application components. If you intend to deploy a specific software component independently, you need to assign a version number for every revision and then track the dependency chain for this version. 

    This technique ensures you know the specific platform tool versions associated with each application version. If you need to roll back, you know what additional components you need to roll back to ensure version compatibility.

    Changing platform components

    This technique requires changing some platform components, such as middleware, which also requires synchronizing each application’s platform version. You should start from the top of the application dependency chain.

    Each application is designed to use specific operating system and middleware features, expecting “version Y or later” of the tools. As a result, you must validate each tool with a specified version against the tool’s dependencies and continue validating each of these dependencies until you reach the bottom of the dependency chain.

    However, some application dependencies are not as obvious and explicit as others. You may encounter problems if you expect to run a guest operating system in a virtual machine (VM) on a hypervisor platform in a different source. 

    You may also encounter issues if a cloud stack release, like OpenStack, requires a certain scripting language version. You can mitigate this issue by testing every dependency chain against the standard middleware and operating system combination, ensuring that all dependencies are recognized.

    Rebuild the dependency tree

    Once you are ready to move to the cloud, you need to supplement the dependency tree for applications and include all the references to the cloud provider’s APIs and features. Make sure to determine how the provider notifies of changes to tools and APIs and prepare to validate new dependencies these changes can create.

    For a multi-cloud or hybrid deployment, you must compare cloud dependency trees across all the components and applications planned to migrate beyond a cloud platform boundary. Note that having a different dependency tree for each provider can result in problems when scaling or failing over between providers’ platforms. You can avoid this by synchronizing components in advance.

    You should also rebuild your dependency trees whenever you change software platform components. A basic update could undo all the mapping and work you have done, and you can easily overlook a change to a small middleware component. You can mitigate this by setting up a life cycle management process to ensure dependency problems do not arise when incompatible elements are introduced. 

    Conclusion

    In this article, I explained the basics of application dependency mapping, and showed how application dependency tools can make cloud migrations safer and easier:

    • Versioning application components—Understanding what version your application expects for all dependent components.
    • Changing platform components—Determining the impact of switching out certain platform components. 
    • Rebuild the dependency tree—Use the map of your existing dependency tree to rebuild a matching dependency tree in the cloud environment.

    I hope this will help you evaluate the use of dependency mapping and make your next migration a success.