devopsy.kinsta.cloud

Category: Doin’ DevOps

  • Engineering Practices Can Overcome DevOps Challenges

    Engineering Practices Can Overcome DevOps Challenges

    When I think about the challenges of DevOps transformations, I love the viewpoint expressed by Ryan Harmon, strategic accounts manager at Trace3: “DevOps is a complex maze that has many leaders frustrated. In many large enterprises, ‘DevOps’ is simply a buzzword they are striving to achieve but struggle with what the end state looks like or even where to start. There are many layers across the organization that are instrumental to truly executing on DevOps. DevOps is not something you go get a quote for and simply buy. It’s an evolving journey.”

    In my previous article, The Time Has Come for an Engineering Approach to DevOps, I agree with Ryan.

    Too many organizations launch into a DevOps transformation initiative without considering the full scope of what it takes to engineer a successful DevOps solution. DevOps is more than “just” a CI/CD pipeline or toolchain, as complex and challenging as this alone may be to accomplish, for even one application. DevOps is more than simply a culture change, as difficult as that always is.

    There are 24 DevOps practice categories that need to be mastered to realize and evolve well-engineered, high-performance enterprise DevOps solutions. Not all 24 need to be mastered to begin the DevOps transformation, but, ultimately, all of them do need to be mastered before the solution will achieve the high performance levels to which many enterprises aspire. The good news is, successful enterprises have demonstrated that the investment in people and technologies required for the journey is worthwhile, and a strategic approach will get you there systematically if you follow a disciplined engineering implementation roadmap.

    As explained in my book, Engineering DevOps, the core of every successful DevOps practice includes nine core pillars. These are the pillars to focus on as you start on your DevOps journey. The following paragraphs illustrate requirements for each of the nine pillars.

    Leadership – Leaders set an inspiring DevOps directional vision for the organization, and proactively stimulate and sponsor team activities that help progress toward goals.
    Collaborative culture – The organization encourages cross-functional collaboration, shared responsibilities and works to reduce restrictive boundaries between organizational functions.
    Design for DevOps – Products are architected to support service-oriented, modular, independent packaging, testing and releases, in accordance with the principles of twelve-factor apps.
    Continuous integration – Changes to software code and artifacts needed for releases are frequently merged, built, tested and packaged into executable artifacts for application releases.
    Continuous testing – Software tests that are most important to verify the results of pipeline stages including pre-flight, integration, regression, performance and release acceptance tests are automated as much as possible.
    Elastic infrastructure – Infrastructure-as-a-service (IaaS) resources (i.e., software, computing machines, storage and networks) are integrated into a toolchain for automating builds and testing environments to efficiently support variable workload demands.
    Continuous monitoring – Applications, pipeline tools and infrastructure components are instrumented with metrics, and the collected data is analyzed to manage health and performance.
    Continuous security (DevSecOps) – Security practices, processes and technologies for applications, databases, pipelines and infrastructures are integrated into the culture and pipelines to assure security.
    Continuous delivery – Release artifacts are validated, prepared for deployment to production and may be automatically deployed to production once acceptable deployment measures are achieved.

    A Comprehensive Engineering Blueprint

    While the above nine practice categories are the core of every successful DevOps solution, 14 additional practice categories are essential parts of a comprehensive engineering blueprint for accomplishing high-performance DevOps.

    DevOps infrastructure practices are used continuously by the nine core practice categories as follows:

    Version management systems – Every stage in the end-to-end DevOps value stream depends on keeping track of versions of software source code, configuration data and executable images using source code management systems, artifact repositories and configuration management systems.

    Infrastructure-as-a-Service – Virtualized cloud and dedicated resources must be served up ephemerally to meet variable workload and storage demands, which requires mastering engineering practices for orchestrating dedicated and cloud, hybrid cloud and multicloud services, and deployment of applications to the infrastructure.

    DevOps pipeline practices, which constitute a layer just above the nine core practices, include two additional categories that make use of the nine core DevOps practices.

    Application release automation – Directing and monitoring software changes through the CI/CD pipeline requires process orchestration and data analysis working at a level above the CI/CD pipeline itself.

    Value stream management – A deployed service, composed of multiple application microservices and data services, requires orchestration and analysis of a federated set of services, end-to-end, across the value stream from planning through to operations.

    Management Practices

    DevOps management practices include four categories that make use of the DevOps Pipeline practices, as follows:

    Service catalogs – Organized collections of software stacks, tools and pre-configured pipelines, made available through portals, enable DevOps-as-a-Service operations and simplify access, configuration, control and evolution of DevOps resources needed by enterprise application teams.

    Disaster prevention and recovery – Proactive disaster monitoring coupled with high-availability configurations and disaster mitigation practices, such as automated processes, work together to minimize the blast radius of disastrous events, and orchestrate rapid restoration of essential DevOps services, when needed.

    Site reliability engineering (SRE) – A combination of practices which include service level objectives (SLOs), error budgets, monitoring, work-sharing policies, toil reduction, proactive anti-fragility practices and blameless post-mortems help to “shift left” production wisdom from operations into development, thus improving the efficiency, readiness, security and resiliency of applications and infrastructures in production.

    Governance – The scale and scope of enterprise DevOps solutions are controlled using governance policies-as-code implemented through service catalogs, management dashboards and error budget policies.

    Project Practices

    DevOps project practices include four categories that guide enterprise adoption and evolution of DevOps, as follows:

    Adoption – Enterprise-wide DevOps adoption strategies that engineer and build DevOps capabilities in logical phases. This begins with a small set of representative applications that serve as a model for other applications; this method has been shown to be more successful than “boil the ocean” strategies that attempt to transform all applications at the same time.

    Model applications – Applications – that can serve as a model for greater enterprise adoption – are selected and monitored according to criterion that spotlight the value of DevOps for other applications.

    Return on investment (ROI) – DevOps investments must compete with other IT projects for resources. An ROI model that demonstrates measurable cost savings is an approach that has proved to achieve greater numbers of DevOps project approvals compared to other methods.
    Continuous improvement – Competitive forces and industry trends require that DevOps solutions continue to evolve to keep up with enterprise requirements.

    The Human Element

    Human development practices include two categories, as follows:

    DevOps engineering – The development of DevOps engineer roles, skills and the structure of DevOps engineering within an organization is critical to the success of designing, building, maintaining and evolving DevOps solutions.

    Continuous learning – A DevOps continuous learning strategy is critical for the development and transfer of DevOps knowledge needed to develop and continuously improve DevOps for the enterprise.

    In summary, the importance of practice categories – and specific practices within each of the categories – will evolve as each application does, alongside the changing needs of the enterprise. DevOps is complex, but a comprehensive engineering strategy that considers the 24 DevOps practice categories described in this article can help enterprises achieve the high-performance DevOps solutions they need to justify the investment and to meet business goals.

  • DevSecOps Implementation: Patch Management

    DevSecOps Implementation: Patch Management

    Patch management has been a thorn in IT’s side for decades. While it is undeniably necessary for security and stability purposes, the staggering array of patches that are available make managing them effectively nearly a full-time job – or a job better left to users. Few IT professionals want to be the “patch person,” and yet, nearly all IT professionals want their systems protected by the latest patches. No one wants to find out an intrusion was easily preventable via patching. It goes without saying that the SolarWinds attack has left quite a few IT departments scrambling for an alternate solution.

    The world of patch management has gone through several evolutions that we won’t cover in much detail here. Instead, we’ll focus on what’s available, what you should look for and where the market is headed. Suffice it to say that patch management as a practice has grown from an individual applying patches to servers and server apps while employees were encouraged to patch their equipment, to complex systems that manage the patching themselves, with IT oversight. Currently, patch management is often bundled with endpoint management, simply because many of the patches are going to end points (user machines and devices).

    Out of this growth have come several market differentiators that you should be aware of when looking into a way to manage the avalanche of updates the average organization is seeing.

    • Centralized or de-centralized? Increasingly, patch management is run on servers/cloud and pushes changes out to those machines/devices that need them, or agents on each machine manage updating themselves. Which is best for a given organization really varies. If a lot of machines are running at the edge of their capability, an agent running updates in the background might be too much to ask. In that scenario, a server-managed install environment is probably better. Conversely, if a centralized location to run updates from is considered an architectural weakness (because it requires access to the update pushing engine), agents might be the better plan.
    • OS support. We’re way past the days when single-OS solutions were considered useful. List the operating systems used in your environment, and choose a product accordingly. Most products on the market support Windows/Mac/Linux, but there are variances. First off, make certain your chosen product supports all three. Then ask, “Which flavors of Linux?” Make certain the flavors running in-house are supported by the software.
    • App support. There are a lot of applications out there. Which are supported by the tool? How much leeway does the customer have for adding applications by pointing the tool at update locations? Does it support FOSS updates? There are a lot of those too, and which ones matter. Make certain the tools the organization uses are supported or can be added.
    • Many tools will scan machines for update issues. Understand what your chosen tools scan for, and how the scans impact performance on the target machines.
    • Updates are not 100% perfect. There will inevitably be problems. Make certain the tool can roll back changes. Updating 50 core infrastructure machines, only to find, hours or days later, that the update breaks something demands roll-back capability.
    • Inter-relationships. Updating a piece of software can require that another piece of software or a driver be updated, which can demand that UEFI/BIOS be updated. Or the CMOS on a RAID controller. Understand how cascading updates are handled by the tool, and if the cascading updates can be packaged, so that a failure automatically rolls back the updates applied thus far.
    • Approvals. Speaking of driver and BIOS updates, what tools are available to allow a human to approve changes? No one wants willy-nilly updates to the drivers on core systems – or even to drivers on user systems.
    • Security of the tool itself. We’re in perilous times where IT security is concerned, and frankly, an update command-and-control server is an attacker’s dream machine – take it over, put your back-door update into the mix, and tell it to update every machine it manages. It cannot be understated: an update management tool must be as protected as possible – both by the customer locking down the installation and by the developer making sure the code is solid.

    Once the system is chosen and worked into your DevSecOps environment, updates will be more responsive, which leaves one more thing to consider – does it feed into your agile tools? If the update management tool notifies a project management tool like JIRA when it updates a server, then if code on the server breaks, the developers aren’t in the dark about changes, and will have breadcrumbs to help them track down the source of the problem.

    Imagine if manual updates became a rarity instead of the norm. There is a cost associated with this process, but most of the products on the market can be had for a reasonable price – if you waste a couple hours a month (or for some products, a year) on updating, they’re paying for themselves. Of course, your time is a sunk cost, and the cost of these is an operational cost, so there is an evaluation your organization will have to undertake. Given how busy everyone in DevOps and DevSecOps is, it is likely worth the investment for all but over-staffed organizations. What? There are a few!

    Find what suits your organization, and put it to use. Faster updates, less time investment. The idea is sound, you just need to figure out what suits your needs. And keep rocking it. You are managing updates already, this is just a way to make your life easier. And we could all use a bit of easier in a busy, complex IT environment.

  • Rapid Strategic SRE Assessments Accelerate IT Transformations

    Rapid Strategic SRE Assessments Accelerate IT Transformations

    A Strategic SRE Assessment is critical in helping organizations successfully transform traditional IT operations to SRE

    Site reliability engineering (SRE) is rapidly becoming more important to organizations that need to scale IT operations while maintaining or improving reliability and security, and to modernize operations to match the growth of DevOps in the organization. Without sufficiently thorough consideration given to best practices for people, processes and technologies, the transformation from traditional IT operations to SRE is unlikely to succeed. Despite challenges, the transformation to SRE is compelling because it provides an opportunity to reduce total operations costs and improve security and reliability while scaling services.

    To be successful, IT leaders need a comprehensive understanding of SRE best practices and need a well-engineered, yet affordable strategy and road map that effectively implements best practices and balances the many aspects needed to transform people, proces and technology. A Strategic SRE Assessment approach, based on best practices, is a key tool to help leaders understand, obtain the strategy and create a road map that will successfully transform traditional IT operations to SRE.

    There is no “standard” SRE assessment approach in the industry. This article enumerates a practical and proven Strategic SRE Assessment approach. The heart of the Strategic SRE Assessment approach is a survey of SRE best practices categorized under nine pillars: Culture, Work Sharing, Toil Reduction, SLAs/SLOs/SLIs, Measurements, Anti-Fragility, Deployments, Performance Management and Incidents Management. The survey is used to collect importance and capability scores for each of the SRE practices. As part of the assessment, a survey determines the current state and preferences of SRE practices for an organization for each of the nine SRE pillars.

    The following are examples of best practices for each pillar that are part of the Strategic SRE assessment survey:

    Culture – Leaders need to understand and sponsor a clear vision for SRE.

    • The culture embraces working practices to proactively shifts left the “Wisdom of Production.”
    • The culture encourages learning from failure and continuous improvement.
    • The SRE role is clearly defined and understood and SREs are considered a vital part of the organization.
    • Rules of engagement and principles for how SRE teams interact with their environment are codified—not only the production environment but also the product development teams, testing teams, users and so on. Those rules and work practices help to maintain SRE focus on engineering work as opposed to operations work.

    Work Sharing – Successful SRE requires that work be shared between SRE teams and development.

    • SRE teams are composed of software developers with strong operations knowledge or IT operations people with strong software development skills.
    • SRE workloads are managed to a budget with typically 50% or less spent on operations work.
    • SRE on-call work budgets are typically 25% or less. Developers share on-call work.
    • Technical debt is worked in small increments.

    Toil Reduction – SREs work to reduce non-value-added work through automation and standards.

    • Work standardization and automation—of both tools and processes—is employed to improve scalability, repeatability and other important goals.
    • Work standardization is used to reduce time spent on non-value-added work.
    • Automation is used to reduce time spent on non-value-added work.

    SLAs/SLOs/SLIs – Service level metrics, based on user perspectives, combined with error budget policies, are critical to managing flow and reliability.

    • SLOs are selected to measure availability, performance and other metrics in terms that matter to an end user.
    • An error budget (= 1-availability) internal service level objective (SLO) is established for each service. SLOs are set to be more stringent than external service level agreements (SLAs) promised to customers. The SLO budget considers what level users will accept, alternatives for users who are dissatisfied, and usage patterns of the product at different availability levels.
    • An error budget policy prescribes consequences if an error budget is spent. For example, the service freezes changes (except urgent security and bug fixes addressing any cause of the increased errors) until either the service has earned back room in the budget or the count period resets.

    Measurements – Smart monitoring implements observability to accelerate response times to incidents.

    • Monitoring solutions are designed to produce service level indicators (SLIs) from which SLOs can be calculated automatically.
    • SLIs do not require a human to interpret an alerting domain. Instead, software observability algorithms do the interpreting, and humans are notified only when they need to act.
    • Monitoring systems use telemetry and instrumentation to ensure the data being monitored is accurate, relevant and available in real-time.

    Anti-Fragility – Systems of people, processes and technologies are continuously tested and improved to assure they are resilient enough to serve applications as they scale.

    • Anti-fragility strategies are practiced to proactively assure the resilience of applications, infrastructures and pipeline services.
    • Fire drills are periodically conducted to proactively determine weaknesses in systems of people, processes and technologies that could potentially impact SLOs.
    • Chaos monkey or equivalent infrastructure testing strategies are used to proactively determine weaknesses in infrastructure systems that could potentially impact SLOs.
    • Security testing and DevSecOps practices reduce the risk of security vulnerabilities.

    Deployments – Deployment strategies reduce the risk of deployment failures.

    • Non-emergency deployments use progressive rollouts in which changes are applied to small fractions of traffic and capacity at one time. If unexpected behavior is detected, the changes are rolled back first and diagnosed afterward to minimize mean time to recovery.
    • Automation is used to implementing progressive rollouts, detect problems and implement rollback changes safely when problems arise, because outages are primarily caused by changes in a live system.
    • Deployment strategies such as blue-green, feature flag rollouts, A/B testing and canary rollouts are used to reduce the blast radius of failed deployments.

    Performance Monitoring – Proactive testing and monitoring ensure applications and infrastructures have the capacity necessary to flex and scale when needed.

    • The SRE team is responsible for provisioning and monitoring utilization because utilization is a function of how a given service works and how it is provisioned.
    • The SRE team is responsible for capacity planning and provisioning. Regular load testing of the system is used to correlate raw capacity (servers, disks and so on) to service capacity.
    • Provision to handle a simultaneous planned and unplanned outage without making the user experience unacceptable. This results in an “N + 2” configuration, in which peak traffic can be handled by N instances (possibly in degraded mode) while two instances are unavailable.

    Incident Management – Incidents are managed in an efficient, blameless manner with a goal to use incidents to improve responses.

    • Playbooks record the best practices for human response actions because playbooks produce roughly a 3x improvement in mean time to recovery.
    • Emergency response performance is measured using mean time to repair (MTTR) metrics instead of mean time to failure (MTTF) because the most relevant metric in evaluating the effectiveness of emergency response is how quickly the response team can bring the system back to health—that is, the MTTR.
    • Postmortems are blameless and focus on process and technology, not people.
    • Postmortems are conducted for significant incidents regardless of whether they resulted in a page; postmortems that did not trigger a page are even more valuable, as they likely point to clear monitoring gaps. Find all root causes of the event and assign actions to correct the problem or improve how it is addressed next time.

    SRE Assessment Surveys Are Not Enough

    The survey alone is an essential tool to collect information about the current state and preferences for each of the SRE practices. However, this is only part of the comprehensive Strategic SRE Assessment approach.

    The Strategic SRE Assessment approach starts with workshops to get alignment between leaders and teams regarding big-picture goals prior to conducting the survey. This is necessary so that everyone who answers the survey has a common perspective and can better respond with considered views of importance and capability scores for each of the practices. The results of the survey include an analysis that points out specific pillars and individual practices that have a high gap score in which the practices are scored as important but not yet practiced well. The high-priority gaps are then used to organize a value-stream map working session, that is designed to find the highest priority bottlenecks in people, processes and technology bottlenecks in the value steam, relative to the organization’s goals and gaps. With the goals, gaps, and data from the value stream map in hand, the next step is to formulate an implementation road map that directly addresses the goals, gaps and bottlenecks in the value stream.

    The final step is to obtain strategic alignment of the big-picture plan by reviewing the findings and road map with the leadership and implementation teams. This entire Strategic SRE Assessment approach, from goal alignment through surveys, value stream mapping, road map creation and strategic alignment, varies depending on several factors such as the size of the organization, number of applications and size of the deployment domains to be included in the assessment.

    A Rapid Strategic SRE Assessment for a sample set of model applications typically is conducted in 21 days. More complex Strategic SRE assessments involving many applications may take up to 90 days.

    In most cases the Rapid Strategic SRE Assessment is the best place to start. Most often, it is not a good idea and is too expensive to “boil the ocean” and make changes across all applications and deployment domains at once. By starting with a small number of model applications, it is easier to implement, measure and demonstrate success and use the results at each step to justify ongoing investments needed to complete the transformation across the organization. Another advantage of the Rapid Strategic SRE Assessment is that it is a quick and affordable approach to check-point progress as SRE is implemented progressively across applications and deployment domains.

    Key Takeaways for SRE Transformation Leaders

    SRE offers immense value for modernizing and scaling IT operations reliably and securely and to complement DevOps transformation. Adherence to SRE best practices is essential to reduce risk and assure security as the transformation is implemented.

    Each organization is different and has different requirements and priorities for its applications and deployment domains. The specific SRE practices that are the highest priority vary according to the priorities of applications and deployment domains. The Rapid Strategic SRE assessment approach, based on nine pillars of SRE best practices, is quick, effective and affordable.

    The Rapid Strategic SRE Assessment is a preferred approach to kick-start the SRE transformation. This approach is also a preferred and affordable tool to reassess the direction as SRE is implemented progressively across the organization.

    Summary

    There is no “standard” SRE assessment approach in the industry. The Rapid Strategic SRE Assessment approach described in this article has been tried and proven with large and smaller organizations. The author invites your comments regarding this approach and the SRE best practices.

  • Best of 2020: Cybersecurity: What Programming Language Is Better for Your Career?

    Best of 2020: Cybersecurity: What Programming Language Is Better for Your Career?

    As we close out 2020, we at DevOps.com wanted to highlight the five most popular articles of the year. Following is the second in our series of the Best of 2020.

    As a novice developer, you may be thinking about learning a programming language and starting a fantastic career.

    In fact, this question on Reddit inspired the whole article:

     

    Source: Reddit.

    The thing is, programming languages represent certain philosophies of its authors and tailored to certain types of problems, i.e., there is no such thing as “the best programming language.”

    Source: Reddit.

    Every Tool Has Its Time and Place

    In this article, I describe major programming languages according to its popularity, usage, demand and ease of learning. 

    There is market demand and a potential salary range for each language. These are linked to specific personal goals and prior programming experience.

    What Questions Should You Ask Yourself Before Diving in?

    • What kind of projects do you want to work on? If career flexibility is a priority, then learning Python or C++ will allow you to work with different types of programming. If your passion is web development, learning JavaScript or PHP is a smart choice.
    • How much experience do you have? You won’t want to switch to an advanced programming language, such as Rust, if you don’t have previous programming experience. If you’re new to a language, you’ll want to start at a higher level and be intuitive.
    • What are your career goals? Do you want to become a freelancer, working for an existing company or work with a startup? Are you trying to be better in your current role?

     

     

    If you plan to get a job in a large technology company, learn the programming languages they use, e.g., NASA, Google and Facebook use Python.

    Many programming languages have similar syntax and qualities—so if you learn one of them, it will be easier for others. The more languages you know, the more flexibility you have in your career and development projects.

    In the list below, we will look at the best and most popular programming languages for many of the most common uses, including web development, mobile development, game development and more.

    Source: Reddit.

    Top Five Programming Languages to Start Your Career

    Java

    It is probably the best programming language if you are looking for a common language that will be useful in various situations. As for choosing a programming language to learn, there are many resources for people who are thinking about learning Java. Java was released in 1995, which makes it one of the oldest programming languages. It is used on a wide range of platforms and operating systems, including Microsoft Windows, macOS, Linux and Solaris. 

    That means there will always be jobs for Java developers, making it (perhaps) the best programming language to learn.

    Research shows that Java developers can expect to earn between $80,000 and $130,000 per year. If you are thinking about learning your first programming language, think about taking an online course, for example, CodeGym. This course, which contains 40 levels of game-play classes, will teach you all the basics you need to know to start programming in Java. It’s easy to follow—even if you don’t have programming experience—and it is worth checking out.

    It is also best used for back-end web development, mobile development and desktop applications.

    JavaScript

    This programming language works on several platforms. Therefore, it is ideal for websites that will be accessed through various devices and browsers. It is suitable for anyone who designs websites with effects, interactive features, animations and pop-ups—standard features on virtually any brand website these days. If you want to work in a creative environment and add more experience to the user, this is a coding language to learn.

    JavaScript is the number one language on the web. The growth of frameworks such as jQuery, Angular and React JS has made JavaScript even more popular.

    If you just can’t stay away from the internet, it’s better to learn JavaScript sooner than later. I consider this JavaScript Masterclass an excellent place to start. For cheaper alternatives see this list of free JavaScript courses.

    It is also best used for front-end and back-end web development

    Learning PHP

    PHP—another old language, first appeared on the stage of programming around the same time as Java in 1995. It is a general-purpose language widely used for web development from the early days of the web.

    Unlike other languages, which can be quite tricky to use with HTML, PHP can be built directly into the HTML code block. Start and finish instructions are used to enter and exit PHP, making it very easy to use. Although PHP is not as popular as Python or Java, it can be a suitable language to learn because of its simplicity. It is convenient for beginners and you can write your first scripts just a few hours after you start your PHP course.

    Again, the popularity and wide use of PHP means that work opportunities are relatively easy to find. An average PHP developer can expect to earn around $80,000 per year. However, there is potential to make much more as a freelancer.

    Take an advanced PHP course, which will teach you everything you need to know to find your first job as a programmer. It doesn’t matter if you’re studying your first language, or if you’re an experienced developer looking for the best programming language to add to your resume—PHP is a great choice!

    It is best used for back-end web development.

    Python

    Source: Reddit.

    Python is a useful step toward more advanced forms of programming languages. Python provides a high degree of website readability and is used by companies such as Reddit, Google and even NASA.

    It is seen as entry-level programming that does not require too much prior knowledge. It may be ideal for relatively new professionals to help small businesses that want to expand their presence on the internet without having to resort to advanced professionals. Python is a relatively simple programming language that is very easy to pick up if you already have programming experience. That makes it one of the best to learn if you are already working as a developer and want to increase your resume quickly.

    The code on Python is designed to be readable. It uses a lot of white spaces, which makes it a pretty easy language to learn while you’re studying it.

    One of the most useful Python’s features is its compatibility with data analysis systems and scientific applications. It is a popular language in scientific communities and is often used by researchers to write their programs.

    An average Python developer can expect to earn about $100,000 per year. However, there is little room for wage growth.

    If you think Python is the best programming language to further your career, consider enrolling in a BitDegree course. The Python Basics Course includes everything you need to know to start writing programs on Python and contains less than four hours of lecture material.

    It is best used for back-end web development, desktop applications, and data analysis.

    C#

    C# is another object-oriented, general-purpose language based on C. It is considered a suitable programming language for building applications native to Microsoft platforms. Microsoft initially developed it as part of its .NET framework for building Windows applications. C# uses a syntax similar to other languages such as C++. Therefore, it is easy to pick it up if you come from a different C family language. 

    C# is not only a suitable language for developing Microsoft applications, but also a language used by mobile device developers to build cross-platform applications on the Xamarin platform. Besides, anyone interested in VR development should think about learning C# as it is the recommended language for building 3D and 2D video games using the popular Unity game engine, which produces one-third of the best games on the market.

    If mobile application development or virtual reality is your business, consider learning C#. Many mobile device developers use C# to create cross-platform applications on the Xamarin platform. Although it is not the most convenient programming language for beginners. 

    If you are interested in any of the above areas, please see the section “Learning the code when making games – Udemy’s Complete Unity Developer in C#.” I see that more than 200,000 students have enrolled in this course, which indicates its popularity.

    It is best used for mobile and game development.

    What Are the Best Programming Languages to Learn?

     

    Source: Reddit.

    As was mentioned at the beginning, there is no best programming language to learn. The best language for you will depend on your experience, your current knowledge and reasons to learn a new language. 

    While there are many options, you should be able to narrow down your language choice by what you want to learn from it. 

    Remember to consider the following:

    • Programming experience, because some languages, such as Python and Java, are more suitable for beginners who have never programmed before.
    • What you want to do with the language. Different languages are used for different things.
    • How much time do you have? Some languages are much more demanding than others.

    Make your choice based on your interests and the type of software development you want to get into. Here is a brief summary:

    • External web development: JavaScript.
    • Internal web development: JavaScript, Java, Python, PHP.
    • Mobile development: Java, C#.
    • Game development: C#.
    • Desktop applications: Java and Python.

    To Sum Up

    Programming and developer communities are evolving faster than ever.

    Various new programming languages are emerging that are suitable for different categories of developers (beginners and experts) as well as for other applications (web applications, mobile applications, game development, distributed systems, etc.).

    This list simply scratches the surface of existing programming languages. Still, the simple fact is that with the right coding skills, you will be perfectly prepared to offer valuable technical support and become an asset to any organization.

    — Dmitrii Borodin

  • Leading Effective Incident Response Without Interminable Bridge Calls

    Leading Effective Incident Response Without Interminable Bridge Calls

    There are easier ways to manage incident response without creating war rooms and packing IT staff onto bridge calls

    Your phone vibrates at 11 p.m., and you know that can only mean another major incident with one of the business’ critical systems. You get geared up for the war room, dial into the bridge call and start reviewing the major incident report. You do this instinctively because it’s the third major incident in as many weeks, and you wonder if there’s a faster, easier, less stressful way to keep critical systems running, especially during periods of operational uncertainties.

    You’re not the only one recognizing that having too many major incidents is a significant issue. In a recent survey on the future of monitoring and AIOps, 94% of respondents stated that issue resolution is critical to their business, but only 28% are satisfied with their handling of major incidents. Too many organizations feel that their only path toward improving their incident handling capabilities involves redesigning their critical business applications, facing down their technical debt or building out an SRE practice.

    There are easier ways to manage major incidents without creating war rooms and packing IT staff onto bridge calls. When used well, AIOps techniques can address the pain points in resolving major incidents that drove business leaders and CIOs to establish war rooms and bridge calls in the first place. To understand what AIOps capabilities are needed, it helps to review the history of war rooms and bridge calls and why they are inefficient in solving today’s operational challenges.

    Furthermore, IT organizations can take advantage of AIOps platforms much faster than re-architecting applications, addressing technical debt,or hiring more site reliability engineers.

    How Bridge Calls Became the Status Quo in Incident Response

    No one wants unreliable or poor performing business systems. It’s why IT teams have become extremely proficient at recovering from incidents, especially the ones that are easy to diagnose and easy to resolve. Problems such as web servers going down, databases running out of storage or services stuck in deadlocks are relatively easy to diagnose with today’s monitoring tools. In fact, over the last few years, many IT Ops groups have used tools to automate the recovery from these common issues.

    But more complex issues are harder to solve. Issues such as:

    • Problems causing a cascading failure of dependent systems that are all sending frequent alerts.
    • Issues right after major application deployments or infrastructure changes.
    • Bottlenecks in customer-facing applications that are experiencing unusually heavy loads.

    IT’s history of solving these complex incidents isn’t great. The incident management team responds and calls in help from Tier One support. With so many things going wrong, operational teams have no choice but to call in higher levels of support, including developers. By the time someone communicates to the business on the incident’s status, leaders are irate over the lack of communication, and the time it is taking to recover from the issue.

    CIOs and IT leaders dislike being yelled at and seeing long outages. Their easiest management response is to get all the experts in the room, often called the war room, in the hope that having more people involved is better. War rooms often include bridge calls to allow remote people to attend, and bridge calls are standard practice for major incidents occurring off-hours.

    Bridge Calls Don’t Solve Incident Management Problems Better

    It surely isn’t better for the operational engineers to be responding to off-hour incidents regularly. It’s not better if a seasoned major incident manager is needed to oversee the bridge call and ensure differing opinions don’t escalate into arguments or finger-pointing. It isn’t better if the recovery times miss business objectives and if root causes are never identified. It isn’t better if the resolution times to recurring problems don’t improve.

    It’s also really bad if the number of complex issues is increasing. This is likely to be the case as application architectures based on hybrid cloud or containers and microservices add complexity while frequent releases from DevOps teams add to risk. Also, global events such as COVID-19 create usage uncertainties and network bottlenecks during periods of increased business importance.

    Solving for the Root Cause of Inefficiencies

    Bridge calls and war rooms are inefficient practices to solve complex problems. They require too many people, take too long and require too many more follow-ups to identify the root cause.

    IT has built up an arsenal of tools to better manage myriad operational domains. We’re using one set of monitoring tools for the data center and a separate one for the public cloud. Every database, API, microservice, application component and type of IoT device has different tools to monitor performance. In fact, according to the future of monitoring and AIOps survey, about 20% of respondents reported having 25 or more monitoring tools. In addition, there’s also all the system, network and application log files that often have the most critical information when troubleshooting a complex issue.

    That’s many tools, considerable data and countless alerts to sift through under the pressure of a major incident. These tools often require different skills and subject matter expert participation, which is another reason why bridge calls and war rooms are so crowded.

    Now, AIOps can mean many different things to different people. But if it’s going to improve major incident recoveries without requiring bridge calls or war rooms, then it must:

    • Aggregate all the data from these monitoring tools.
    • Aggregate data from all of your change and topology tools, so you can find out which changes led to an incident or what’s affected by the incident.
    • Sequence the data into a time series showing what issues came first.
    • Correlate the hundreds or even thousands of alerts into discrete events that operators should review.
    • Present the information in an easy console for operators to assess during major incidents.
    • Enable engineers to automate steps in the recovery.
    • Integrate with different workflow, collaboration and communication tools to automate incident response steps.
    • Share the event sequence with engineering and development teams.

    During incidents, the differentiator is that machine learning models have gotten a head start in processing all the data. Instead of dozens of tools requiring lots of people, the start of the incident review can begin by examining information in a single platform. Instead of IT Ops being inundated with too much noisy data and alerts, machine learning has already processed and correlated events into a more easily decipherable storyline. Instead of manual recovery steps, automated steps can be centralized and orchestrated from a single console. Lastly, since the organization’s workflow, collaboration and communication tools are integrated, no one should feel out of the loop on issue status and postmortem steps to make improvements.

    IT teams often celebrate when a legacy system is shut down because operations have fully transitioned to a modernized platform. Isn’t it time to do the same with war rooms and bridge calls?

  • DevOps Deeper Dive: ServiceNow and DevOps, One Year In

    DevOps Deeper Dive: ServiceNow and DevOps, One Year In

    It’s now been a year since ServiceNow launched its DevOps integration initiative. Since then, thanks to the arrival of the COVID-19 pandemic, the way organizations manage IT has utterly changed. With more employees now regularly working from home, more organizations have shifted toward relying on IT service management (ITSM) platforms that, like ServiceNow, run in the cloud.

    At the same time, the overall IT environment has become more complex as a greater number of applications based on microservices that span everything from containers to serverless computing frameworks are deployed in production environments. Most of those distributed applications are being built and deployed by DevOps teams who are finding it necessary to collaborate more with IT operations teams who still rely on ticket-based workflows to manage jobs and tasks.

    As organizations invest more in digital business transformation initiatives fueled by these applications, the pressure has intensified to bridge the cultural divide that has long existed between traditional IT operations teams and application development teams that have embraced best DevOps practices.

    At the core of that divide is a desire on the part of DevOps teams to automate IT process management. Tasks that once required IT personnel to implement manually increasingly now are being automated by developers employing tools and platforms that expose both APIs and command-line interfaces (CLIs). Not every IT task can be fully automated just yet, but with the rise of machine learning algorithms and other forms of artificial intelligence (AI), a great leap forward is clearly being made.

    In fact, the rise of AI coupled with a need to more aggressively reduce costs are motivating organizations to investigate how they can better unify the management of IT, said Judith Hurwitz, principal analyst for Hurwitz and Associates, an IT consulting firm.

    “It’s a major change,” said Hurwitz. “There’s a lot more focus on the issue of managing errors.”

    ServiceNow is investing in AI to address that issue, including partnering with providers of DevOps platforms to gain access to the data required to train AI models. That effort will simultaneously improve the developer’s experience at a time when organizations need to accelerate the rate at which applications are being developed, deployed and updated, said RJ Jainendra, vice president and general manager for IT business management and DevOps at ServiceNow.

    “The change management process is becoming automated,” he said.

    ServiceNow, which has more than 1,000 customers and contract values in excess of $1 million, is not the only provider of an ITSM with similar ambitions. Not only are providers of rival ITSM platforms moving down the same path, but new entrants have also emerged in the form of vendors that are extending DevOps platforms into the realm of ITSM. Atlassian, for example, has launched an ITSM initiative aimed specifically at DevOps teams looking to eschew a ticket-based approach to IT in favor of workflows that are managed directly by DevOps teams.

    As the responsibility for managing IT end-to-end continues to shift left toward DevOps teams, many won’t embrace ticket-based workflows. Eventually, DevOps platforms and legacy approaches to managing IT using tickets will converge. ITSM platforms are still the systems of record for recording IT events, so integration between DevOps and ITSM platforms is required.

    In the meantime, replacing IT processes that employ ticket-based workflows which adhere to frameworks such as ITIL will not be easy, said Mitchell Ashley, CEO and managing analyst at Accelerated Strategies Group.

    “Ticket-based workflows are incredibly sticky,” he said. “It’s not a question of undoing them as much as it is unraveling them.”

    In fact, Ashely said a ticket-based approach to managing IT may be too deeply ingrained in the psyche of IT teams to be replaced.

    “Ticket-based systems are a lot like email,” said Ashley. “They will be with us forever.”

    As long as ticket-based approaches to managing IT workflows remain in place, however, the potential for culture clash across teams that have divergent approaches to managing IT will remain high.

  • Design Systems: Development Choices for Meeting User Expectations

    Design Systems: Development Choices for Meeting User Expectations

    Modern software development trends involve design systems and modernization, and if we drill down further, the trend within the trend is about creating better user experiences. This means improving usability, emerging technology and performance enhancements. This is easier said than done. What does it mean for developers?

    Employing Design Systems

    What a designer sketches, a developer tries to replicate, often with varying degrees of success. When we introduce multiple screen sizes and form factors, the experience can vary greatly if the collaboration between design and development is not in sync. To combat this, many modern software development practices are beginning to employ the use of design systems to provide an outstanding experience to the end user and streamline processes internally.

    Typically, a design system consists of UI components and visual style guidelines, both in the form of reusable code and reusable design artifacts. The system could include UI patterns, foundational elements and design principles or guidelines. Many go as far as defining what tools should be used for optimal UI and UX. For example, one of the most widely known design systems—and most used, due to its open source nature—is Google’s Material Design.

    With a design system in place, developers and designers are singing from the same sheet of music. This eliminates many delays and inconsistencies and provides prescriptive guidance for both the visual and functional experience of the app. It allows developers to deliver the beautifully styled, feature-rich responsive experiences the end user has come to expect.

    Choices for Modernization

    For .NET developers, this could mean exploring Blazor, Microsoft’s answer to JavaScript, which allows developers to build interactive web UIs using C#. It could mean diving into.NET 5, which is the next step in building a unified platform, allowing developers to use it to target Windows, Linux, macOS, iOS, Android, watchOS, WebAssembly and more. Or, it could mean getting a jump on .NET MAUI, the welcome evolution of Xamarin.Forms, combining the best of Mono and .NET Core and allowing developers to build truly native desktop and mobile apps for any operating system from a single codebase and project system from their preferred IDE.

    For the JavaScript developer, modernization could mean looking toward Vue 3, which is a faster, smaller and more maintainable framework. Or, it could mean exploring Angular 10 and its warnings for CommonJS imports. Or maybe it’s truly understanding and appreciating the downplayed release of React 17, which now allows multiple versions of React on one page, making it easier to use React with other frameworks. Modernization is all about staying relevant, learning and leveraging the latest the industry can offer.

    Popular Frameworks

    For front-end development, React, Angular and Blazor are some of the most popular frameworks at the moment. Blazor is so new enough that you aren’t going to find anyone with years of experience, but it is a framework that is incredibly adaptable and easy to learn if you are C# developer.

    React and Angular are more mature and with their latest releases provide even more compelling reasons to build your web apps with them. The soft skills—the ability to communicate and collaborate—are some of the most in-demand skills today.

    Regardless of your front-end preferences, the proliferation of frameworks and new versions means that developers have more choices than ever for creating rich, interactive, modern experiences for multiple platforms and devices.

  • The Future of Application Development

    The Future of Application Development

    What lies ahead for application development? Can we look forward to a less hierarchical system?

    The current state of application development has an often overlooked problem: It’s inaccessible.

    Top tier companies such as Google, Microsoft, Apple and Facebook are at a major advantage. With their large capital, they can invest in innovative development tools and round up extensive workforces of leading talent to use them—which matters, especially amid an ongoing developer drought. Meanwhile, companies lacking these privileges must make do with a leaner toolset and smaller, less cherry-picked workforce—which is not to say that they don’t make smart, creative use of what’s available to them, but that they deserve to play ball on a more equal playing field.

    Unfortunately, the pandemic compounded this issue, at times bringing even greater advantages to the tech giants. To overcome what some consider a trend of software elitism, efforts have been made to accelerate the pace of application architecture for all. Employing no-code and low-code tools, for example, could help the smaller guys compete. However, as Robson Grieve, CMO of enterprise software company OutSystems sees it, “these latest approaches are mostly point solutions solving a limited set of problems.”

    I recently invited Grieve to share more of his take on this issue and how he envisions a future of application development that works inclusively for a wider set of companies.

    Application Development: The Other 99%

    “It’s frustrating that the best, most advanced development tools have traditionally only been accessible to the largest, richest companies,” said Grieve. “Everyone else suffers with ballooning backlogs and struggles to take advantage of the latest, greatest technologies.”

    While it may sound like a platform out of a Bernie Sanders speech, recognizing the advantages of the top 1% in the application development world brings up a valid line of questioning as to whether maintaining this status quo is really how we want to go forward. After all, wouldn’t it be better if more companies had access to the best technologies? Wouldn’t we all benefit from that?

    Creating a More Equal Playing Field in Application Development

    Luckily, we are already feeling the winds change in this department, as top tier companies are beginning to lose their stronghold on the crème de la crème of development tools. What’s beginning to change, Grieve believes, is “access to the most sophisticated tools and advanced technologies are being democratized … sophisticated, feature-rich, beautiful, and mission-critical applications are no longer the sole domain of the elites.”

    How is this being realized? In many ways, it’s coming from the makers of the development tools themselves, who are bringing careful thought and creativity to tool design. Some of the strongest approaches in Grieve’s eyes include the following:

    • Holistic approaches that streamline the most critical innovations into single, integrated platforms.
    • Low-code approaches that help accelerate development while retaining the power and expressiveness of traditional code.
    • Platform approaches that offer design, development, deployment, monitoring and management capabilities in one place.
    • Multi-functional approaches that serve a diverse team, support the full DevOps life cycle and, in effect, improve productivity and collaboration. For example, platforms crafted to serve the unique needs of UI/UX experts, business analysts, professional developers and architects.
    • Automated approaches that allow applications to be continuously updated and seamlessly modified once they’ve been deployed, using an AI-powered automation layer that underpins the tool, managing application dependencies and providing self-healing capabilities to ensure that regardless of what changes are made, the tool never breaks.

    One thing that stands out here, according to Grieve, is the idea that broad, multi-functional development platforms reign supreme. As Grieve noted, “the most valuable tools are the ones that solve the broadest set of problems.” In general, approaches that keep in mind security, scalability, reliability and availability will be robust solutions for diverse teams, both large and small. A bonus is if the tool is visually appealing and model-driven for the best ease of usability and user experience.

    All for One, and One for All

    The issue of software elitism is one problem that can be seen as a clear opportunity, and that opportunity is not being missed among the smartest makers of development tools. As Grieve said, “Modern application platforms have the potential to help the vast majority of the economy succeed by offering a better approach—one that takes state-of-the-art technology and makes it more approachable, accessible and adaptable.”

    Again, we see a version of AI democracy at play. This is an exciting shift for many companies and teams that exist outside the elite tier. As an example, Grieve said that instead of “procedural code or minimalistic point solutions,” modern applications platforms “harness the power of advanced technologies and AI to create efficiencies for companies outside of the tech bubble.”

    This could be one way to level the playing field and allow companies of all sizes to complete the work needed, shrink backlogs, overcome developer drought with tools that are friendlier to citizen developers, support team collaboration, accelerate efficiency, and—for the underdogs—compete with the big dogs.

    Looking to the Horizon

    So, what does Grieve see for the future of application development? To him, it is bright if we continue on the current trajectory. “More and more,” he said, “successful development projects will require business and IT to work together and collaborate closely.”

    This means investing in sophisticated technologies, with powerful built-in AI, that can help companies ensure that even though applications are built quickly and efficiently, they are built securely and reliably—and in ways that can be easily scaled and evolved.

    If this is all to be realized, Grieve forecasts that we can look forward to “a bright future that is welcoming of a much more diverse and representative community of people who build applications together to solve all the most pressing problems.” It’s an optimistic view, but one that many will welcome as a fresh breath of air in what have been some particularly trying times.

  • Gravitational Becomes Teleport to Streamline Access Management

    Gravitational Becomes Teleport to Streamline Access Management

    Gravitational today announced it has changed its name to Teleport and launched the Teleport Unified Access Plane, an open source security gateway that comes in the form of a single binary that acts as a proxy for remotely accessing Linux servers and Kubernetes clusters.

    Teleport Unified Access Plane (UAP) for managing those gateways can be either deployed by an IT team or accessed via a cloud service managed by Teleport.

    Offerings included in Teleport UAP are Teleport Server Access, Teleport Kubernetes Access and Teleport Application Access, which combined enable IT organizations to lock down access to an IT environment.

    Company CEO Ev Kontsevoy said Teleport UAP gives engineers via a single login access to just the IT resources they have permission to access. That approach reduces the myriad credentials that IT organizations currently need to manage across multiple networks.

    Teleport automatically discovers all the resources in an IT environment along with the protocols needed to access them. It provides a unified audit log in a JSON format that enables IT teams to track what resources are being accessed when and by whom.

    Access control is becoming a bigger issue because the overall IT environment is becoming more complex as the infrastructure stack required to run applications grows. Teleport provides a way to streamline access management across servers, clusters and databases.

    That issue is also becoming a bigger challenge with IT personnel now working from home to help combat the spread of the COVID-19 pandemic, added Kontsevoy.

    That fine-grained approach to access will ultimately eliminate the need to rely on virtual private networks (VPNs) at a time when the network perimeter continues to dissolve. In effect, Teleport enables IT teams to move toward a more identity-centric approach to unifying the management of access, he said.

    In general, he noted, Teleport enables organizations to manage security as code rather than having to rely on separate overlays. As such, they can shift responsibility further left toward DevOps teams.

    It may take some time for IT teams to aggregate all the access control protocols they currently employ under a single proxy. However, Kontevoy said, the massive amount of time and effort spent managing access control today will drive organizations that have embraced best DevOps practices to look for ways to automate what today is a very manual process.

    The challenge, of course, is finding the time to achieve that goal. Teleport is betting a single binary in combination with a control plane accessed primarily as a managed service will make it too simple for DevOps teams to ignore. Regardless of approach, however, it’s clear there needs to be a better way to manage access within the sea of servers, databases and applications that now make up the typical IT environment.

  • How to Cut Design Sprints in Half

    How to Cut Design Sprints in Half

    Any company that has created a product in the digital sphere will no doubt be familiar with the purpose of design sprints. Traditionally both back-end and front-end developers, designers, marketing teams and other stakeholders in the company come together over the course of five days to prototype ideas, gather insights on users and validate them before building solutions with company resources.

    Like most startups we are always extremely busy and getting people to work for five days felt like a lot—even two days was a stretch for some, so we decided to see if we could come up with a way to get the same results in a fraction of the time.

    Traditional design sprints are held over five key days to help:

    • Understand –  Map a challenge and particular focus area.
    • Ideate – Come up with many design solutions.
    • Decide – Turn those design solutions into a storyboard.
    • Prototype – Create a prototype based on those storyboards.
    • Test – See how live users interact with the prototype and learn to iterate further.

    For our design sprint this time, we wanted to test another approach for the first three steps in the process (understanding, ideating and deciding). Instead of taking three days to complete the majority of the design sprint, we wanted to test if we could deliver similar results in four hours. We did, handing off storyboards to our designer for testing and iterating with live users. This cut a normal five-day design sprint in half. This is how we did it.

    The Purpose of Our Design Sprint

    We were creating a top-secret brand new feature we wanted to add to our product that required the design sprint in the first place. At Usersnap, as a customer feedback company, it is probably no surprise that we use our product to collect feedback from people using our products, do extensive research on that feedback and take our findings directly to a design sprint for ideation and prototyping.

    Preparation Is Key for Shortened Design Sprints

    If you want to cut your design sprint in half, make sure you have the following in advance:

    1. Research on our target personas (we conducted 20 interviews and collected 130 survey responses).
    2. A clearly defined and agreed-upon challenge for your design sprint team to tackle.
    3. The deliverables at the end of the session.

    Desired outcome: Make sure everyone is clear and aligned on the challenge to tackle.

    You may wonder: “Why would you prepare these things beforehand when all of this could be discussed during the design sprint?”

    We wanted to give people time to sit with the challenge and have ideas to present during the design sprint, and save the time that was used just getting everyone up to speed.

    Understand (1 hour)

    Instead of a full day to understand the challenge, we used one hour. How is this possible, you ask? Our participants came prepared in advance and our in-house researchers had extensively analyzed the findings from our research stage.

    Presentations (15 minutes)

    First, each expert presented the findings of our target persona and their pain points. There were three researchers who each had five minutes to present the qualitative, quantitative and nuanced aspects of the persona’s pain points. With a short period of time, our researchers were forced to focus on the most important problems of our persona.

    While presenting, the other participants wrote down “How Might We’s” (HMWs) on post-it notes. HMWs frame challenges in question form and these post-it notes are integral to the ideation stage.

    Desired outcome: Understand the persona of the chosen design sprint challenge.

    Expert Interviews (45 minutes)

    Second, researchers were interviewed by the participants to learn more about the persona’s challenges. We set the timer for 15 minutes for each researcher and fired away with our questions.

    Desired outcome: Expand on particular points that participants wanted to know more about.

    While Q&A continued, respondents continued writing HMWs on post-it notes.

    Ideate (1.5 hours) and Decide (1.25 hours)

    Ideation and decision takes two days in total, according to the design sprint manual, and we gave ourselves less than three hours.

    Problems Worth Solving (30 minutes)

    First, we set the timer for three minutes, and all of us came up with our top three HMWs to put on the wall. When time expired, we presented our HMWs and placed them on the wall in order of our persona’s job steps. If a HMW is repeated, we either replaced it because it’s more relevant, or threw it away.

    From there, we all received three stickers, set the timer for three more minutes and proceeded to vote on which three HMWs were most relevant to the persona’s pain points. The voting is not meant to eliminate less relevant HMWs, but to clarify what the group thinks is most important.

    Desired outcome: Focus the group on problems to solve within the persona’s challenges.

    Crazy 8s (1 hour)

    Next, we did two rounds of Crazy 8s. At this point, we were breezing along, and even my own expectations were exceeded: We were getting close to designing something in a fraction of the time it normally takes!

    The steps to Crazy 8s are simple:

    1. Take a large piece of paper, and fold it into eight parts (“tiles”).
    2. Set the timer for eight minutes, and begin.
    3. Provide up to eight screen designs based on any of the HMWs written down (those that made it to the wall and those that didn’t).
      • Less than eight screen designs? No problem.
      • Want to present a flow with multiple tiles? Go for it.
    4. When the eight minutes are up, place each piece of paper on the wall.
    5. Present three of your eight ideas to the group and explain what problem the design should solve.
    6. Repeat the process a second time; combine ideas from others or expand on them.

    Desired outcome: Demonstrate how we could solve a problem related to the persona’s pain points.

    Decide (1.25 hours)

    Storyboards (1 hour, then 15 minutes)

    Next, we broke up the design sprint team into two groups, making sure there weren’t too many participants with substantial design sprint experience in a group.

    We set the timer for one hour, and each group came up with a storyboard flow with five sheets of paper. We didn’t give clear guidance on how to design the storyboard, but it should represent five key steps to reach a goal. If both groups approached the problem in the same way, it provided good insights on the nuances of the problem. If each group approached the problem differently, it provided perspective to the problem itself.

    Desired outcome: Design screens in an order that tackle the challenge of the design sprint for our persona.

    We then presented our storyboards. Each group had five minutes (set your timers!), and time for quick Q&A afterwards.

    Retrospective (15 minutes)

    Finally, it was time to conduct a quick retrospective. Each participant had three minutes to provide their thoughts:

    • What did you like?
    • What didn’t you like?
    • What could we improve?
    • Any additional comments?

    Handover for Prototyping and Testing

    From there, we handed the HMWs, Crazy 8s solutions and storyboards to our designer to develop a prototype, do user testing and iterate on the design. From previous prototypes, we knew that we would hear a lot of the same feedback from the participants. So we decided to change relevant and obvious flows right away and test an already modified version with the next participant. This process allowed us to achieve a more relevant flow in a shorter time.

    In the end, none of this was or would be possible without customer research. It was the foundation of our design sprint, and we used our own product to collect feedback and organize it in a way that gave us sound insights leading up to our design sprint.

    Those four hours yielded great results for the type of challenge we wanted to solve, and we didn’t use three days to get there. It took us longer to get to a tested prototype, but only one or two people were involved and they didn’t dedicate 100% of their time to the prototype iteration. This process fits better to our day-to-day schedule.

    Trimming Design Sprint Time

    We found the process very helpful and will do it again, always re-evaluating where we can improve. For anyone who would try this method:

    1. Be sharp and clear on the goal.
    2. Have well-prepared participants.
    3. Keep your timers handy.
    4. Question the quality of your results.
    5. Let us know if we’re onto something.

    Happy sprinting!