Tag: software development

Survey Surfaces Tension Between Software Speed and Quality

A survey of 600 software professionals at organizations with more than 1,000 employees published today by OverOps, a provider of software analytics tools, finds the need to ensure quality still trumps the need for speed within most organizations.

According to the survey results, 70% of respondents say quality is their paramount concern and they would rather delay a product road map than risk a critical error impacting their users. More than half of the survey respondents (53%) said they encounter such critical or customer-impacting issues in production at least one or more times a month. Two out of three survey participants report spending at least a day per week troubleshooting issues in their code, with 30% spending anywhere from two days to a full week.

Nevertheless, organizations continue to invest DevOps (58%) to accelerate application development. Among those organizations, continuous integration (54%) and continuous delivery (42%) platforms were the top priority.

Other areas of investment include microservices/containers (45%), static analysis (37%) and dynamic code analysis (27%).

Nearly half of respondents (45%) said pressure to move fast was one of their top software quality challenges. More than half of respondents (59%) said they release new code/features anywhere from bi-weekly to multiple times a day.

Despite investments in DevOps, however, a quarter of participants also said that over 40% of critical production issues are first reported by end users or customers rather than internal systems.

OverOps CTO Tal Weiss said the survey makes it clear there needs to be more focus on software quality. The challenge organizations face is finding a way to achieve that goal while still accelerating the rate at which code is delivered. Too many organizations are measuring the lines of code delivered without taking into account how often they run into issues in production environments because of the quality of the code deployed.

Of course, whenever a project falls behind one of the first places any organization looks to make up ground is by reducing the amount of time allocated to testing. However, many organizations are also integrating testing within CI/CD platforms to make sure critical testing processes are not skipped in the name of making a deadline.

It’s not clear whether software being deployed today is any higher or lower in quality than software developed using legacy waterfall approaches. As long as humans write code, there will always be issues. Proponents of DevOps will argue that deploying smaller amounts of code more frequently helps mitigate that issue. If errors are discovered, it’s easier for DevOps teams to not only roll back that smaller update but also more quickly discover the source of any issue. Sometimes that issue may have more to do with the platform the code is being deployed on than the code itself.

Regardless of the approach to developing software, there is clearly more at stake than ever. As organizations embrace digital business transformation the quality of any software update can have a major impact on the business. The challenge is first eliminating as many of those disruptions as possible and then, secondly, minimizing their potential impact on the business as quickly as possible.

June 2, 2020

5 Reasons Why Your App Needs an Error Monitoring System

All software applications have errors. Bugs are simply part of software development. That’s why engineering organizations need to know exactly what errors are occurring so decisions can be made around which bugs to fix.

The fastest way to identify and fix application errors is to implement error monitoring software. However, not all solutions are created equal, and the best error monitoring systems do more than error alerting. They provide insights into the stability of the software, give developers metrics for addressing technical debt and enable better decision making around building features versus fixing bugs.

The result? Happier developers who build better apps that match customer expectations.

Here are five specific reasons why engineering organizations should adopt an error monitoring system.

Error Monitoring Improves Application Health

At its core, an error monitoring system addresses the challenge to find, fix and prioritize software bugs. However, what makes an error monitoring solution stand out is stability scores, which make it easier to maintain a healthy app.

Calculated with real-time error rates and session data, stability scores reflect the percentage of successful user interactions per release.
They tell the real story about the impact of errors and technical debt and provide a single, unifying metric that speaks directly to the overall application health.
Stability scores can be used across teams to set stability targets (critical stability and target stability), which in turn can determine whether the app is healthy enough for building new features, or if it’s time to fix bugs.

An Error Monitoring Solution Increases Team Productivity

With a lack of detailed information about the source and factors contributing to a bug or crash, developers must conduct research to pinpoint errors, which is a time-intensive process.

Without Error Monitoring	With Error Monitoring
Sixty percent of developer time wasted investigating and fixing errors, often in code they didn’t write.	Forty percent increase in developer productivity with the exact location and source of the error provided by error monitoring solution.

From detection to resolution, error monitoring with stability scores determines whether debugging needs to be part of the workload and which errors should be addressed first. In addition, the best error monitoring tools help prioritize business-critical and revenue-impacting errors to ensure alignment from top to bottom within an organization.

Understanding Your Application Errors Can Reduce Costs and Increase Revenue

With an error monitoring service that catches errors quickly, engineers save time, avoid critical errors and deliver crash-free applications that users want to spend money on. New features can also be rolled out on time with fewer errors, which makes developers and users happy.

On average, companies lose $1,500 per engineer each month over debugging.
Knight Capital Group lost $440 million in a mere 30 minutes due to a software bug.

Technical issues are the number one reason apps get deleted. Thankfully, companies that deliver smooth app experiences benefit from loyal users who trust and spend money on their brand.

Error Monitoring Retains Development Talent and Boosts Morale

Technical debt is hard on engineers, both from a productivity and emotional perspective. Without a common language to explain its impact to other teams, developers often become frustrated at bearing the burden of technical debt, which can cause disengagement and encourage developers to leave.

Error monitoring management and stability scores bring complete visibility and cross-team agreement around software stability and prioritization of errors. Stability scores provide:

A common vernacular for discussion between engineering, product, QA and release teams about when it’s time to fix bugs versus build new features.
A metrics-driven reflection of the impact of technical debt on the product and clear demonstration about when it’s time to address it.
A singular goal for application stability, which turns development and product teams into allies and increases morale across the organization.

Error Handling Impacts User Satisfaction and Usage, and Safeguards App Store Ratings

Apps play an important role in our personal and professional lives. Widespread app adoption and daily usage point to why application errors are becoming unacceptable to users, who aren’t shy about speaking up when errors do occur.

Ninety- six percent of mobile app users write bad reviews for sub-par apps.
Forty-two percent of 0-star app ratings in the Google Play Store mention app stability and bugs.

The best way to ensure users have a positive customer experience is to use error monitoring to catch errors in real-time so you can respond immediately. Error monitoring provides a hope for avoiding poor app store ratings and for keeping customers satisfied.

June 1, 2020

Application Architecture

June 1, 2020
CloudBees Extends SDM Service Reach

CloudBees has extended the integrations embedded within its software delivery management (SDM) platform to add support for additional services provided by Google.

Moritz Plassnig, senior vice president cloud and general manager for SDM at CloudBees, said these integrations with Google Cloud Build and Tekton pipelines are being provided as part of a long-standing alliance between the two companies to advance the adoption of best DevOps practices. The CloudBees SDM service runs on the Google Cloud Platform (GCP).

As part of that effort, CloudBees has been making investments in an SDM platform that enables DevOps teams to pull metrics from any tool or platform. That data is then fed into an analytics cloud service through which CloudBees surfaces insights that identify, for example, how delays to a project might impact overall revenue goals.

Interest in software delivery analytics has risen in the wake of the COVID-19 pandemic as organizations accelerate the building and deploying of digital business applications, said Plassnig. With employees and customers alike working from home to combat the pandemic, organizations are investing more in creating applications that provide digital alternatives to engaging end users, he noted, adding delays to any of those projects are likely to have a much bigger impact on business continuity strategies today than they did just a few short months ago.

The CloudBees SDM service provides DevOps teams and business managers alike a real-time view of all product and feature development occurring across the organization, as well as a policy engine to trigger actions to better optimize the software delivery process. Organizations can also model and visualize the software delivery process while measuring overall DevOps performance.

Rather than requiring organizations to standardize on a single platform to achieve that goal, Plassnig said CloudBees is leveraging application programming interfaces (APIs) to integrate metrics across a broad range of DevOps tools. That approach, he said, makes it possible to meet organizations wherever they are in terms of DevOps maturity.

Support for Tekton pipelines is significant, Plassnig noted, because it’s expected that most continuous integration/continuous delivery (CI/CD) platforms in the future will be built using Tekton pipelines, which provide an open source framework for building platforms that are designed to be deployed on Kubernetes clusters. Jenkins X, originally developed by CloudBees, is one of the first CI/CD platforms to support Tekton pipelines, which were originally developed by Google. Jenkins X and Tekton pipelines are now being advanced under the auspices of the Continuous Delivery Foundation, an arm of the Linux Foundation.

As more CI/CD platforms embrace Tekton, the platforms themselves will become less of a black box from an analytics perspective, noted Plassnig.

In the meantime, CloudBees also expects Google to continue to gain momentum as a cloud service provider, he said. While Google trails Amazon Web Services (AWS) and Microsoft in terms of overall market share by a wide margin, Plassnig noted that with the arrival of Anthos, a cloud operating system capable of being deployed on multiple cloud and on-premises IT environments, it’s only a matter of time before services such as Google Cloud Build are employed more widely.

Whatever the platform used, the one thing for certain is the rate at which software is being generated and deployed on various platforms will be watched much more closely.

May 26, 2020
The Secure Software Development Life Cycle: Syncing Development and Security
Over the last five to 10 years, the nature of software development has shifted dramatically. Whereas large software releases occurred every six to 18 months in the past, current release schedules have become much more frequent. The waterfall model of software development has morphed into what we now know as the DevOps model.

As a consequence, DevOps has instigated changes in the traditional waterfall security touchpoints. In essence, DevOps has changed the very nature of how application security needs to be implemented. To avoid friction in the development process, application security activities must be adapted to the new world of DevOps practices. It has to go beyond the basics of threat modeling, design review and two weeks of pen testing.

Under DevOps, some development organizations now do software releases on a daily, weekly or bi-weekly cadence. But they’re still grappling with older application security models. As a result, development and security testing can be out of sync—you cannot conduct a two-week pen test on software that’s released weekly. These organizations need effective security assurance in their SDLC that’s good, quick, early and—above all else—automated.

The Changing Nature of Software Development

The way software is developed keeps changing. And it keeps accelerating. Application security needs to change to catch up. Automation will play a key role in enabling application security to maintain the pace of DevOps. DevOps needs automation to effectively deal with software release cadences that occur on a daily, weekly and bi-weekly basis as well as to increase agility generally within the SDLC.

For example, DevOps accelerates when the automated pipeline embeds application security scanning into pre-commit checks. In this way, consistent levels of application security testing apply every time developers check in code, resulting in a fully automated check-in process. But automation doesn’t lock developers into the same level of security for every code change. For example, if the change only involves altering the color of a logo, heavy security scanning and manual won’t be necessary. At least not the way it would be if the application is accessing sensitive data.

So, instead of giving developers quarterly SAST results, automation puts the code analysis right there in front of developers as they’re checking in code (via certain IDE plugins). Presenting the code analysis findings to developers, while they are still in the code, has several advantages:
- The code is still fresh in the developers’ minds.
- Coding problems can be caught earlier and more easily while developers are still thinking about the code.
- It mitigates the risk of developers not remembering the code context at a later date.
Overall, the more automation there is in application security the better it is for open source validation, container scanning containers, QA testing, API security and more.

Automated Security Assurance and Out-of-Band Activities

When it comes to implementing testing in DevOps, you must balance automated security assurance with out-of-band activities. That means it’s sometimes appropriate to slow down the automated security process. Even in a completely automated DevOps process you may need to slow down to make necessary changes. It’s true a code change, such as just changing the background color on a web app, may not be too risky. There’s no problem with automating that DevOps step and pushing out the change. But, if your web app interacts with customer data, you’d be prudent to slow down and take the next application security test out of band, and make sure you’ve got the procedure right because it’s much riskier.

There are different levels of risk and severity within each release of an application. Development organizations need to accept this and adapt to each release’s potential risk and severity level. Then, they need to provide the appropriate level of security assurance and security coverage, whether that is automated within the DevOps workflow, performed out of band or some combination of the two.

Life in the Fast Lane

For DevOps organizations, one of two avenues beckons to them: the security express lane or the security slow lane. You could create an automated DevSecOps process across the development organization—the security fast lane. But, there’s no one-size-fits-all DevSecOps process for enterprises. That’s because there could be up to hundreds of development teams within an enterprise. And there’s not always a standardized process that all dev teams can follow. It’s a challenge to adapt automated security to each development team. Those in the security fast lane should use a security champion to work with the development team and be the point person to assist them with understanding application security needs and remediation guidance.

In the security slow lane, individual development teams may still be enabled to go fast. The difference is that they will pick the SDLC tools that make the most sense for that team. Then, they should also pick the application security tools that make the most sense for them. The bottom line for organizations is that application security needs to involve an acceptable level of friction for developers to make DevSecOps work. If there is too much friction, developers will bypass application security in favor of expediting coding activities.
May 13, 2020
A Prescription to End the Myopia of Software Metrics

“People don’t want a quarter-inch drill. They want a quarter-inch hole!,” Theodore Levitt, Harvard Business Review.

As someone who has purchased many drills in my life—and drilled my share of holes—this quote has always struck me as a bit, well, myopic.

Don’t get me wrong, I’m not arguing with the sentiment behind the quote—that organizations need to focus on customer needs versus the products they make—but perhaps the example could be updated to reflect our times.

Part of the issue I have with this quote is that, unless you only want a peep hole, a quarter-inch hole is not a solution in and of itself. No one needs a quarter-inch hole in isolation.

You are most likely working on a bigger project that requires multiple holes. You have an outcome in mind, that outcome requires some holes drilled and a drill is the best way to make holes. The holes are an intermediary step.

For example, the last time I purchased a cordless drill was because I was remodeling my kitchen and my existing drill had reached the end of its useful life. Of course, I needed to drill holes in the process, but that was not my ultimate objective—the kitchen was.

By now you are probably asking yourself, “What does a 60 year old quote about marketing myopia have to do with DevOps and software development?”

I would argue that the same principle applies to the metrics we apply to software development. Using myopic measures of success can prevent us from meeting the needs of customers, or of our own organizations.

In a previous post, I wrote about a Forrester Report that urged CEOs to end the madness of software metrics and called out software organizations for using arcane, indirect measures of success.

Some of the metrics we use to measure DevOps success today are the equivalent of measuring the number of holes we have drilled, the speed at which we drilled them or the quality of the holes. While these are certainly important to gauge, they do not correlate directly to whether we are meeting the needs of our customers, or of our own organization.

As a follow-on to the report referenced above, Forrester conducted a survey of over 300 senior business and software leaders, which uncovered some interesting data points.

Eighty-six percent of respondents said it’s important to align software delivery practices with the overall objectives of the business. And 80% said measuring the overall value of software initiatives is important or critical. Makes sense.

Yet, very few are actually tracking business-oriented metrics that align to those goals. Only 38% are correlating software initiatives to their impact on revenue, and fewer (37%) are attempting to measure ROI for software development. Impact on customer experience was slightly better, but still measured by less than half of respondents (45%). These are metrics most business leaders care about—but few software organizations are tracking them.

The study highlights the metric madness—or myopia—that causes disconnects between software development teams and business leadership. BizOps is a new framework that is gaining traction in the industry because it promises to eliminate this disconnect.

At its heart, BizOps is a framework for optimizing software development and delivery to foster the achievement of business objectives. Essentially, BizOps helps connect the dots between traditional measures of software progress and metrics of business success. It’s what we need to end the myopia of software metrics.

April 27, 2020
Five Attributes of a Great DevOps Platform

As we move toward 2020, the expectations are high, the software industry is moving faster and the demand for rapid and continually improving digital experiences have raised the standard. To match the needs and demands of the market, firms around the world are embracing the DevOps culture to ensure and streamline the development, packaging, testing, deployment and maintenance of software at scale.

Every DevOps organization is defined by its own leadership, culture, practices, policies, leadership style, structure, talents, skills, technical capabilities, processes and tools. However, there are certain common characteristics that are important to consider before deciding a better DevOps platform to use in your organization. Today, we will discuss such important features that can help you while selecting your DevOps platform.

What is DevOps?

DevOps is a mindset in an organization that enforces a set of collective practices to ensure easy collaboration between dev and ops so the business can run smoothly without any hassle. DevOps aims to fasten the time to market through frequent and incremental improvements to deliver quality software updates to customers.

The meaning and definitions of DevOps can vary from company to company. Automation being the focal point, firms want to focus on achieving zero-touch automation, with utmost security and governance as a priority in the delivery pipeline.

Even though the meaning of DevOps varies, several inherent DevOps principles cannot be replaced, and they repeatedly insist on collaborative relationships, developing early, failing early, shared learning and continuous feedback. These DevOps principles enhance quality with improved deployment rates while simultaneously improving predictability, scalability and security of the production environment. Tech leaders in the company need to view DevOps as a holistic approach rather than a small set of guidelines for the teams, and DevOps guidelines should be aligned with the company’s long term technology vision and objectives.

Here are some facts to consider while deciding a better DevOps platform for your organization.

A Mindset of a Unified Culture

Culture plays a significant role in establishing the guidelines while embracing DevOps in any organization. Through DevOps culture, companies seek to bring dev and ops teams into harmony to promote collaboration, automation, process improvements, continuous iterative development and deployment methodologies. But above everything else, a sound DevOps culture fundamentally solves one of IT’s biggest people problems: bridging the gap between dev and ops teams to get them to stop working in silos and have common goals.

According to Gartner estimation, DevOps efforts fail 90% of the time when infrastructure and operations teams try to drive a DevOps initiative without nurturing a cultural shift in the first place. It is not just about the efficient tools or experts working; it is about the behavioral modifications and mentality necessary to effect cultural change.

Hence, it is important for the firms to consider the culture of the company before selecting its tool as a potential DevOps tool for their development.

Automation Inside and Outside

Automation is one of the key principles of a strong DevOps team because it has such a high return on investment.

Automation makes up as a large part of DevOps culture to standardize production platforms, and even firms believe it as true because standardization and automation help make deployments more predictable, easy and less prone to human errors.

Automate everything as part of the workflow process, including infrastructures, compliance and continuous delivery pipeline. For example, tools such as Artifactory can manage and control all your binary repositories to help your developers and ops collaborate and automate build and deploy tasks easily. Similarly, Docker allows development teams to containerize applications and automate application deployments with speed.

By reducing manual, non-important and repetitive tasks, you will increase your development and testing speed while cutting down on human and unnecessary errors. Additionally, by automating tedious and repetitive tasks, firms free up team members to work on higher-level and more important tasks.

Important to note here, JFrog Pipelines is an innovative DevOps automation solution that well integrates and connects all critical processes in the software delivery lifecycle in the company, from development to testing to production. Using minimum code, it allows you to create smart and event-driven workflows across tools and teams easily, to speed up the release of software applications. This helps you achieve continuous integration, continuous delivery, continuous deployment and continuous monitoring in DevOps.

Support Both Hybrid and Multi-Cloud

What is Multi-cloud?

Multi-cloud is the use of cloud computing from two or more public cloud providers in single network architecture to meet their business objectives. A multi-cloud strategy has many advantages. It avoids vendor lock-in, decreases latency, enhances business continuity, overhead cost reduction and maximizes flexibility for development teams. However, multi-cloud management comes with some challenges that require careful orchestration, and needs to pay close attention to security and governance issues.

What is Hybrid-cloud?

A hybrid cloud is a mixture of on-premises and off-premises IT resources. Based on business and compliance requirements, the hybrid cloud allows firms to move data and applications between private and public environments.

Hybrid cloud computing allows instant transfer of information between public and private environments, allowing enterprises to experience the benefits of both environments efficiently.

Flexibility, scalability and cost savings are some of the top benefits of hybrid-cloud.

Considering a platform that supports both multi-cloud and hybrid-cloud is the best solution for the enterprises moving toward the digital transformation ladder.

Continuous Updates

Frequently rolling out updates, in a continuous sequence, to bring service improvements to consumer devices more rapidly and efficiently is what every firm is trying to do these days. The customer wants new features as early as possible and continuously. That is one reason why companies embrace automation and follow practices like continuous integration, continuous deployment and continuous delivery through tools such as GitHub, Artifactory, Circle CI, Docker, Kubernetes, etc.

The DevOps platform should be able to manage your DevOps pipeline from a single pane of glass. A platform that can provide a universal end-to-end solution that integrates with your ecosystem to orchestrate and optimize all critical processes in your CI/CD pipeline. Boosting fearless updates continuously from code to the edge in self-managed, on-prem, hybrid and multi-cloud environments.

A Robust Community

All successful companies have built their own communities through their products and services. DevOps is all about the culture shift. Changing existing culture and moving forward is one of the hardest things to do—despite the benefits that DevOps offers, such as speed and agility. No matter what changes a team implements, embracing DevOps often comes to a halt once the companies realize it requires a change in culture and mentality of all the teams involved. This is where the value of community comes in, by fostering the development of a more open communication, easy and supportive feedback, and collaborative culture within teams, companies can be able to drive this DevOps culture. This mindset should come from within and outside of the organization by tapping into this sense of community-based collaboration. Communities are required because they ensure the well being of many of the technologies we use daily.

Your favorite DevOps platforms—Jenkins, Docker, Kubernetes, Artifactory—and their popularity is because of the communities they have created around the tools.

A well-focused DevOps platform gives power to people who listen carefully to what the market is saying, gets the feedback and utilizes it effectively. Hence, community is a very important feature of a DevOps organization.

Conclusion

Companies around the world are embracing DevOps, and the demand for DevOps skills soars as organizations spend their time and money on digital transformation. DevOps has become a modern approach to IT that helps companies to think and execute broader business strategies. DevOps can drive significant brand value by accelerating speed to market, better collaboration, ensuring better testing and automation. A DevOps platform should have all the qualities mentioned above to succeed in this highly competitive market.

April 21, 2020
Open Source Vulnerabilities Were Up 50% in 2019 — How Will It Impact Software Development in 2020?

Open source vulnerabilities have been on the rise in recent years, but 2019 was truly one for the record books with a spike of nearly 50% over the previous year.

According to the recently released State of Open Source Security Vulnerabilities report by the WhiteSource research team, the number of vulnerabilities jumped from 4,100 in 2018 to 6,100 in 2019.

Figure 1: Number of reported open source vulnerabilities per year.

In hopes of better understanding what is behind this rise in the number of open source vulnerabilities, what it tells us about the state of open source usage in modern software development, and even where we are likely headed in the years ahead, let’s take a look at the report’s findings for insights on the current state of open source security.

More Code, More Vulnerabilities

According to the research report, the primary driver behind the rise in open source vulnerabilities is a function of the growth of open source. There are now more open source projects, code and members of the community than ever before.

All of these good folks are working hard to not only write more code, often with the backing of large tech giants, but also to seek out vulnerabilities in the code that can put the users of their components at risk. The combination of more code being written and the number of eyeballs reviewing the code for those inevitable human mistakes, comes together to produce a larger number of vulnerabilities being reported.

The increase in the number of vulnerabilities in open source components will have a considerable impact on software development. In recent years, we have seen open source components playing a bigger role in how developers build their applications. Most estimates believe that open source components comprise between 60-80% of the codebase in most modern applications. When a vulnerability is reported in a popular project such as Apache Struts or the Linux kernel, then huge swaths of developers can quickly find their software in need of patching.

The Good, the Bad and the Bazaar

WhiteSource’s research revealed the reassuring news that over 85% of reported open source security vulnerabilities have a fix available.

One of the reasons for this improvement is the fact that more enterprises are dependent on open source components for their own software, so they are investing in making it more secure, via bug bounty programs, backing foundations that support open source security or backing the projects themselves.

However, even as the situation in the field appears to be improving, there is still a way to go.

The fact that many published open source vulnerabilities are not indexed in one central location adds complexity to this challenge for development teams attempting to stay on top of published open source security vulnerabilities. If proprietary software is still considered to be the classical Cathedral, well-organized information and support under one roof, then open source is very much the Bazaar.

The WhiteSource report found that only 84% of known open source vulnerabilities appear in the National Vulnerability Database (NVD). This means that information about another 16% of the known vulnerabilities is out there, spread out among a wide range of resources. These might be security advisories, bug trackers and a laundry list of other locations. While 45% of reported open source vulnerabilities that were not initially published on the NVD eventually end up there, that could take months since their publication on other resources.

The challenge for organizations is that they run the risk of using a vulnerable component unaware of the security updates, while hackers are scouring all resources, looking for vulnerabilities that could be their next meal ticket.

Given the evolving security challenges facing organizations, what does the future hold for open source security in the year ahead?

Our Predictions for 2020

The easiest prediction that we can provide is that 2020 will have even more reported open source vulnerabilities than were published in 2019. The only question is: How big it will be? Chances are that the count will be more significant due to recent advances making it easier than ever to report and an open source vulnerability.

This past year saw the launch of GitHub Security Lab which aims to help researchers, maintainers and users easily report an open source vulnerability and publish a verified fix in one centralized location. By simplifying the reporting and documentation process, GitHub has gone a long way in helping their users to protect their software with better quality reporting.

Key Takeaways

For many, the rise in the number of reported open source vulnerabilities might be concerning, making us confront the fact that we probably have plenty of them in our software right now. However, the situation is actually improving, and even heading in the right direction. When vulnerable open source components are reported, we get to track them and move quickly to remediate. Only once you know you have a problem can you begin to fix it.

Hopefully, the increase in security awareness will keep pushing for a stronger, more organized and better supported open source community that will be resilient in the face of even more vulnerabilities that are likely to show up in next year’s research report.

April 20, 2020
Tips For Managing Development Teams Remotely During Coronavirus

Thanks to the global coronavirus pandemic, around a third of the world’s population is on lockdown in their homes, which means a huge number of businesses are currently trying to navigate remote working solutions. Trying to collaborate on software development is difficult at the best of times when your team is all in the same office, but with your team split across various home offices communication and collaboration is made all the more difficult.

Remote development work is an altogether different challenge, one that needs careful thought and new solutions. Luckily, there are ways to get around it, and they don’t all require huge investment or innovation. Just tweaking the way you think and work will help you continue to deliver on your development goals.

Spread Knowledge

Many teams run into problems with their remote workforce when they realize knowledge is not equally distributed amongst team members. I don’t mean the company log-in details (though you might have that problem too), but that the company’s vision and culture have not been effectively communicated. In an office setting this isn’t too much of a problem, as developers can be sent off on projects and the team can come together to implement them with one voice at the end, but when the whole team is divided it’s a lot harder to achieve this final cohesion.

To avoid having to piece your projects together like a jigsaw puzzle, make sure all of your developers are clear on what goals the company wants to achieve as a whole, and what culture and tone the company is wishing to promote. That way any development decisions made in private working sessions are still geared toward the overall company aim, and individual projects will slot in well together.

Communicate

To spread knowledge effectively, you also need a major focus on communication. You won’t realize how much the office dynamic contributes to communication until it’s gone. Working from home eliminates many of the little interactive scenarios in which team members can discuss ideas and clarify details.

To counteract this, you need to communicate far more than you previously did. Send more emails for clarification and have more regular meetings (over video chat) than you otherwise would. This might seem annoying or even counterproductive at first, but having a clear flow of information across the whole team is important for accountability.

Take Note

Related to communication, you may find it really helps to note more things down. You’d be surprised how much information is transmitted from being physically in the same space as someone, so a lot of workers find it a lot harder to pay attention to video of audio meetings and can easily forget details. Whether it’s minutes of a Zoom meeting or a brief one-on-one phone conversation, jot down a note of important tasks or details to remember, and circulate them throughout your team.

Be Humble And Accept Feedback

If you’re managing a development team that’s just gone full remote, accept the fact that you might not have all the answers. This might be as new to you as everyone else, and even if you have experience of remote working before it probably wasn’t during a global pandemic. By all means, show a strong sense of leadership and implement a solid plan of action, but be humble enough to accept that it might not be a perfect plan.

Show your humility by being open to feedback from your team members. They are having to adjust to a new lifestyle that may require new strategies to deal with. You might consider flexible working hours, or reassessing your tools or communications strategy. Figure this out as a team and you’re much more likely to keep morale up and not sacrifice any productivity.

Embrace The New Normal

Most importantly, don’t spend your time waiting for things to go back to normal. Treating this period as a brief interruption to your normal working schedule will stop you from fully committing to new strategies and tools to help you produce good work right now. It will show in your products, and if your remote working period lasts longer than you’d expected it will mess up your production schedule. For now, this is the new normal: embrace that and start with your best foot forward.

April 17, 2020
Provide Continuous Value with Product-Centric Delivery

Software engineering and management has borrowed many practices over the years from traditional industries such as construction, automotive and manufacturing. One such practice is the notion of managing software development and delivery based on projects.

According to the Project Management Institute (PMI), a project is defined as “a temporary endeavor undertaken to create a unique product, service or result. A project is temporary, in that it has a defined beginning and end in time, and, therefore, defined scope and resources.”

Many enterprises today manage software delivery via a project-centric software delivery approach. New software projects are identified based on probable business cases. Business opportunities are identified and prioritized based on potential business benefits and estimated cost. This is done with the assumption that the exact market needs, the estimated cost, start and end dates, and potential benefits are certain and known up front. Once the business case is approved by senior management, projects are initiated. In an environment where the scope, schedule and cost of projects can be defined upfront, this provides a predictable approach for software delivery management and governance.

But, do we live in a world of total certainty? In the volatile and uncertain world in which we live—with the very fact that software is not a physical good—accurate predictions of market needs, cost, timing and end-user benefits are far from reality. In addition, companies are competing in the marketplace by exploring innovative ways to create and deliver new products and services.

Why is the project-centric delivery approach used by so many IT organizations if it is a challenge? Projects can no longer be the vehicle for software development and delivery if enterprises want to stay ahead of the competition. Then, what is the alternative approach?

Introducing the Product-Centric Delivery Model

A product-centric delivery model is a new way of organizing people, and continuously delivering valuable software to customers.

Let’s take a look at the steps an enterprise needs to follow in order to transition from project-centric to product-centric software delivery.

Identify Products Instead of Projects

What are software products? Organizations across the world provide value to their customers in the form of goods and services. These goods and services are called products and are often driven by software and IT systems. For example, to a bank that provides digital banking services to its customers, its online banking solution is a product, not a project. Similarly, for a retail company, its catalog and product search becomes a product. These kinds of products are different from the actual physical goods that these companies sell.

Organize and Fund Stable Teams Around a Product, Not a Project

Once your products are identified, the next step is to organize and fund your software teams around these products. These cross-functional teams include members from business development, IT development, support and operations. This team must be empowered to build and deliver the product on their own and will collaborate, decide what to build, how to develop it and how to manage the product with frequent updates. The team must be outcome-oriented, long-living and cross-functional. They can be organized as a team-of-teams or squads, resulting in better collaboration, focus and ownership from any corner of the world. This will also help in scaling the overall capacity of the product. A common shared services team, supporting multiple products might be an added advantage.

Define Product Vision, Define Objectives, Deliver and Measure Value

After the products and the teams are in place, you need to define the product vision. The product vision defines the reason for its existence and the long-term goal that it is trying to achieve. This also aligns business objectives with IT delivery and provides guidance for all decisions made regarding the product development and delivery.

The business stakeholders define the product vision and derive the near-term objectives that will guide the teams to further decide the set of initiatives they need to work on.

The teams then identify relevant product features, plan and deliver those in short increments or time boxes, thereby delivering continuous value to end users.

At the end of each time-box, stakeholders will measure the product outcome with the stated objectives and changes in the market needs. The findings will help the business decide on whether to continue investing in the product or not.

Conclusion

Product-centric delivery paves a new way of organizing people and continuously delivering software value with more emphasis on outcome rather than the output. It provides a continuous flow of work to the product teams and continuous value to the end users. It aligns the business strategy to software development and execution, while empowering the teams to decide what is best for their product.

— Prabhu Arumugham

March 4, 2020