But wait, how many Kubernetes experts do we have? We’ve got an industry-wide shortage of skilled software development and operations talent—and the complexity of cloud native development is exacerbating the problem. We’re not going to hire our way out of this mess!

Skill shortages stymie cloud native innovation

Even non-technical executives now understand the basic benefits of cloud native software. They know it has something to do with Kubernetes pushing out containers, so the resulting applications are more modular and take advantage of elastic cloud infrastructures.

There’s way more to it than that. The cloud native landscape is a beehive of open-source projects for configuration, networking, security, data handling, service mesh – at various maturity stages. There are also hundreds of vendors offering their development, management and support tools atop this ever-moving CN raft.

A developer’s learning curve is steep and continuous, since this year’s stack might no longer be relevant next year. Outsourcing is tough too, when the few consultants with a real knack for cloud native development are busy and expensive.

The only way to sustainably grow is through building cloud native development talent and capabilities from within, following the introduction and maturation of the space, as well as keeping tabs on the vendor and end user community at large.

While the market demand for digital offerings keeps doubling every couple years, IT budgets often get a budget belt-tightening as a reward for managing and scaling so much technology.

Smaller and leaner teams are expected to deliver twice the output with half the people. The need for specialized skill positions only increases as concepts like event-driven architecture, data lakehouses, real-time analytics, and zero-trust security policies turn into production-grade requirements. 

Why platform engineering matters

No matter what target environment they are contributing to, developers still spend most of their time coding within an IDE. Over the years, vendors have tried everything from low-code tools to process toolkits to lower the skills bar, but the pipelines don’t translate into easy wizards. 

Complex open-source tooling, third party service APIs, and code that is being mixed and matched from GitOps-style repos are driving cloud native development teams toward a new platform engineering approach.

Platform engineering practices seek to create shared resources for development environments–encouraging code, component, and configuration reuse. 

Common platform engineering environments can be represented within a self-service internal development portal or an external partner marketplace, often accompanied by concierge-style support or advisory services from an expert team that curates and reviews all elements in the platform.

It’s critical to govern the platform’s self-service policies for access permissions, code, logic, data, and automation at just the right level of control for the business it supports. 

Too much flexibility ends up creating overhead, as diverse stakeholders fail to distinguish between the relative value or usefulness of so many unvalidated and poorly categorized components of the platform.

Too much rigidity in policy design can create the opposite problem, where centralized governance and approval cycles for every element slow down solution delivery and take away the innovative freedom developers crave.

A modern approach to cloud native platform engineering can finally bring the principles of governance, consistency and reuse to the table.

Speedy innovation through infrastructure abstraction

Refreshingly—or maddeningly—there’s no single right way to ‘do’ cloud native. Even Kubernetes is by itself just an abstraction of container orchestration and only one option for going cloud native.

As an open-source movement, the CNCF purposely leaves the future approach open to interpretation by the community. It doesn’t dictate a particular language, or even a specific piece of infrastructure. 

That’s excellent, but it also leaves short-handed dev teams managing complex plumbing and experimenting with integration options, rather than building better functionality. That’s where platform engineering practices can save the day.

The decision to create a platform is a commitment to help developers of varying skill levels abstract away the complexity of underlying cloud native architectures with interfaces and tools atop readily configured environments.

A platform engineering approach must offer ease of use, elimination of toil, and reduced cognitive load for development teams—helping orgs attract and retain the best talent.

The Intellyx Take

Truly innovative ideas that impact customers represent a core competitive differentiator, and should grow from within the enterprise. That’s difficult when the supply of skilled cloud native development resources is constrained.

Fortunately, platform engineering organizations and technology stacks can automate some of the most difficult work of delivering on the needs of API-driven microservices environments.

The post Patch the cloud native development talent gap with platform engineering appeared first on SD Times.

What was so intriguing to so many about Web3 anyway? Since nobody could really agree on exactly what it was, it could literally be whatever aspiring entrepreneurs imagined it to be.

Common threads appeared. Blockchain. Bitcoin and Ethereum. DeFi. Decentralization of organizations, infrastructure and data. Freedom from tech giants. Self-sovereignty. Privacy. Opportunity.

All the kinds of ideals that generate charismatic personalities. 

Who cares about maturing cloud adoption or better integration standards, when you can explore a whole new economy based on blockchain, cryptocurrency and NFTs? Why wouldn’t tech talent leave standard Silicon Valley-funded confines to live this Web3 dream?

When a space is overhyped and undefined, it encourages the rise of the worst kinds of actors. Web3 never had a chance, with its uncertain crypto-economic roots and the use of blockchain technology, which hasn’t proved adequate for enterprise-class business.

Crypto-Schadenfreude: Sham, bank run & fraud

Nobody enjoyed more of a media darling status in the Web3 world than FTX founder Sam Bankman-Fried, who famously played video games on investor calls and shuffled around the tradeshow circuit in shorts, as he donated millions to “effective altruism” charities and crypto-friendly politicians.

Now Sam’s been arrested and set for extradition from the Bahamas to face charges in the United States, with FTX the most famous failure among several other falling dominoes (Lumen, Celsius, Gemini, on and on) in the crypto rug pull. 

It was fun to mock celebrity shill ads, but it’s not funny to see $2 billion in investor deposits disappear into the ether. A lot of VC whales, other DeFi companies and hapless individuals were also duped and parked their funds there too.

There’s no cash reserve regulation or FDIC account insurance in place for crypto, so when buyer confidence eroded, market makers sold, accelerating the ‘rug pull’ effect. Ripples collapsed as much as $183B or more from the total market cap of cryptocurrencies.

Turned out, there’s nothing new about this Ponzi scheme, a Madoff-like phenomenon my analyst colleague Jason Bloomberg has commented on ad infinitum, even appearing as a gadfly at crypto conferences to say it has little use except for criminal enterprises like money laundering and ransomware, to audience hecklers.

Blockchains looking for solutions

Besides cryptocurrency, the most common term we hear in Web3 discussions is blockchain, which is a distributed ledger technology (or DLT) underpinning Bitcoin, Ether, Dogecoin, and thousands more dogshitcoins.

If cloud was just ‘a computer somewhere else’ then blockchain is more like ‘an append-only database everywhere else’ due to its decentralized consensus mechanism and cryptography. Even the first Bitcoin blockchain proved resilient to hacking unless someone finds a way to steal user account keys through other means.

Though I’m a skeptical analyst, I admit thinking there was some sleeper value in blockchain, if a few properly governed projects came along that could create safer, smoother rails to adoption.

We’ve seen vendors with very nice use cases for distributed ledgers, particularly in multi-party transactions, IP and media rights, legal agreements and audits, and proof of identity, where a blockchain can use a combination of transparency and immutability to provide a decentralized, shared system of record – whether nodes are exposed publicly or among permissioned parties.

That still doesn’t make blockchain a valid replacement for modern databases and data warehouses, which already offer enterprises more scalable back-ends for applications, with better security and governance controls.

The slow, energy-sucking processes of mining, recording and storing parallel blockchains haven’t proven sustainable for business use cases besides tracking a few heads of lettuce with e.coli on them.

The Intellyx Take

The main roots of Web3’s failure weren’t about technology, they were about misaligned incentives and the inevitable association of Web3 with crypto and NFT market madness. 

Unethical players could rise to the top, confidently claiming top-line growth, and attracting continued fundraising investments without mentioning the inevitable crash.

I’ve met early participants in the blockchain space with intentions for a better world with unique computing models and applications particularly well-enabled by decentralization. They weren’t building mansions on islands and taking crypto-bros out on yachts.

Who knows? Once the incentives and risks of easy money are washed out of the market for good, maybe the dream of global access to a new, decentralized internet of applications and value could someday be realized.

The post Web 3: New scams for new kids on the blockchain appeared first on SD Times.

Programming is not a belief system – it’s part of computer science for a reason. There is a systematic approach for improving development expertise, gathering and analyzing data, and proving or disproving that the software works. Logic and data are codified in software and in our processes around creating software.

The human influences of societal norms or religion should have little to do with the quality or performance of the software a group of developers can churn out.

Ideology precedes architecture

A particular ideology for codifying technology sets an organization apart from its peers. When team members share beliefs and behaviors, the resulting products can gain consistency in design and utility that ‘just makes sense’ to customers who resonate with the approach.

The company’s founder, or an executive can set the tone for an organization of course – think Steve Jobs or Andy Grove. But for software development, an ideology is usually more than a cult of personality. 

Development teams with shared ideology can perceive and respond to opportunities and challenges as a group, like flocks of birds that seem to magically change direction.

The codification of the group’s encouraged and discouraged behaviors can take many forms, including a predilection for certain technologies or methodologies. In this sense, an ideology establishes an organizational intent that influences the architecture of delivered software.

A services methodology is not an ideology

A lot of services companies tout an overarching Agile or DevOps methodology, a ‘customer first’ mentality, or ‘proven processes’ for delivering great work. A skeptic sees these as branding exercises to give clients confidence and recruit better developers.

As analysts, we have a hard time evaluating and comparing services offerings as they relate to product value, except when they relate directly to product delivery and training, or operationalization of a SaaS solution for customers.

Open source collaboration magic

Open source projects start out as a kernel of code in a repository, and a code of conduct for founding the community of current and future contributors. 

Open source believes in a shared collaborative ideology and democratizing access to non-proprietary platforms, thereby leveling the playing field for individuals to build solutions atop them. Societies to benefit from the resulting innovation.

Attending an open source conference, the ideology of an agreed-upon code of conduct for treating each other with respect supersedes any actual discussion of code and components. Projects that lose their collaborative energy become toxic and get abandoned, as contributors take their talents elsewhere.

Design-first versus product-first

I covered the quandary of design versus product-led development modalities in my previous column on design-led versus product-led delivery teams. 

Design-led ideologies lean on developer intuition, the healthy competition of ideas, and fast iteration to constantly improve the software customer experience, whereas product-led development focuses on constantly delivering and improving features that meet customer demand. 

These modes of thinking coexist productively within many orgs. Engineering and operations groups may be able to bridge the gap between design and product orientations by crafting shared models that represent their commonalities, giving them a common language to mix the best of both worlds.

Inclusive versus exclusive

An ideology of making ‘software for all’ – users and employees of all skill levels, cultures, and abilities – sets a high premium on user experience and accessibility. The world’s most widely accepted products are practically self-explanatory and built upon this mindset.

Conversely, many software vendors cater unapologetically to expert practitioners only, or for industry specialists who bring deep domain knowledge. There’s value in delivering the right tool for the job after all.

No-code, low-code and pro-code development tools offer a spectrum of these ideologies in action.

Coding for global good

Ever since Google quietly dropped its own ‘don’t be evil’ mantra more than a decade ago, I’ve been skeptical of companies that say they exist to improve the greater good. The recent trend of ESG (environmental, social & governance) has been co-opted as the latest form of ‘greenwashing’ by corporate entities seeking to publicize their environmental concerns. 

Still, if such goals make data centers increase efficiency and run on renewable energy, and cause logistics vendors to reduce overall emissions by optimizing truck routes, that’s inherently good.

An AI company developing healthcare or self-driving cars can set out to save human lives, and the resulting software will be more likely to do so if it matters.

The Intellyx Take

A useful development ideology is not just defined, it is cultivated by a group over time. It is not something that corporate leadership can dictate.

In today’s fast-paced world, merged companies never retain their ideological foundations for long, as principal collaborators move on, engaging their efforts and beliefs in the next startup.

Strong ideologies, like proven methodologies, are built and reinforced from within. If ideologies resonate with customers when codified as code, later teams can inherit them for useful purposes.

The post Codifying software: An ideological perspective appeared first on SD Times.

Until recently, analysts would lump low-code in with no-code and a host of tools offering some form of drag-and-drop ease that enables ‘citizen developers’ (meaning: non-developers) the means to deliver apps. But where should you start in thinking about your own enterprise’s journey to low-code?

Looking at the rate of investment and vendor acquisition in the low-code solution space, it seems like this arena has never been hotter. But in another sense, it’s always been with us.

Ever since the first desktop applications appeared, software companies have sought a way to endow professionals who didn’t have the time or inclination to learn C with the ability to build and design functionality.

Before RAD and 4GLs appeared on the scene, there was Visio and some VB tools on Windows, and Hypercard on the Mac. Even Excel started a revolution among skilled spreadsheet wizards armed with a few macros. These early forms of low-code were pretty localized in orientation, predating the explosion of content yet to come via internet services.

Low code is on a continuum 

According to my colleague Jason Bloomberg, low code is on a continuum between no code (tools requiring no coding at all) and pro code (tools that ease developers in reusing code or leveraging development skills).

There are parallels between the low-code spectrum of ‘assisted development’ solutions and the closely related business process automation and testing spaces, which share several commonalities, including a business user-centric or ‘no-code’ point-and-click simplicity on one end, and an engineering-centric ‘pro-code’ side.

In fact, we have seen several assisted development players arise from testing or automation tools that found their stride in low-code.

What will drive further low-code adoption?

Low-code solutions arose from the natural desire of every business to get ‘all hands on deck’ and become productive in delivering on the needs of customers, given constrained IT resources and budgets.

Beyond that desire, there are several major challenges that call for a low-code approach:

Maintainability. By far, technical debt is the granddaddy of low-code challenges. The need to maintain existing systems and retire or refactor obsolete or malfunctioning application code takes up the bulk of most established companies’ IT resources.

Low-code tools must add features that are modular, interoperable and especially maintainable, so developers aren’t left trying to pick up the pieces within a muddled, object-disoriented code dump.

Integration. Many low-code tools started out from an integration perspective: allowing teams to stitch together and move data between multiple tools or services to provide new functionality that wasn’t readily available before. 

Low-code solutions should include both internal core systems and external services into workflows, without requiring users to understand how to construct their own APIs. Always try digging past the ‘wall of logos’ and make sure the CRM or OMS you already own can be effectively supported for end customers.

Security. SecOps teams are extremely resource constrained, and have difficulties figuring out exactly how to authorize conventional development teams for environment access, much less giving low-code citizen developers appropriate access.

Ideally, modern low-code solutions can ease this security management burden, with role-based access controls assigned for team and functional responsibility levels. Fail to do security right, and you will either get hacked, or get Rogue IT as teams run off to do-it-anyway without draconian oversight.

Functional integrity. Manually coded processes and rote processes hidden within monolithic silos need to be rebuilt by business domain experts inside the prospective low-code platform.

Whether the new functionality is vertical or horizontal the low-code platform should provide adequate ‘safety bumpers’ in the form of pre-flight testing and early monitoring and feedback, so owners can be alerted if any application is going off track.

The Intellyx Take

If low code was just about reducing labor costs or IT resource constraints, the space would gradually be consumed by adjacent development tools becoming easier to use, or automation tools becoming robust enough to define applications. 

Bringing the intellectual capital of business expertise to bear within our application estates might just be the biggest game-changer for the future of low code. Wherever the code road ends, a new opportunity arises.

Hey, thanks for reading! Why not watch my archive of the latest 2022 LC/NC Developer Day session now?

The post Hopping on the low-code locomotive appeared first on SD Times.

I once pondered an alternative product-driven strategy for software organizations to behave more like high-growth software vendors, recasting their project managers as product managers. They would spend less time measuring time, and more time measuring the features they deliver.

Ostensibly, this product-oriented approach would cut down on endless initiatives and sprawling scope creep, by getting executives to reconsider the contributions of developers toward finite high-value products.

A finished product implies reusability, and higher potential value for more use cases than the work output of a project. 

But lately we are seeing a second shift – from product-led to design-led strategy. Some of the founders of today’s fastest growing unicorn vendors emerged from design schools and creative industry backgrounds.

Costume, or customer experience?

There’s a lot of technical and business acumen that a design-led team must develop beyond graphic design that goes into a successful customer experience.

Designers get asked to put ‘lipstick on a pig’ – pushing pixels to dress up an application visually without changing the underlying functionality. The cosmetics of tweaking icons, fonts and colors can make the software look nicer, but it seldom improves user experience (or UX) by itself.

Users expect clear controls and instructions within an interface, and on their phones or devices, they also expect sensory data – using cameras, haptics and audio inputs and outputs to maximize productivity.

Performance is also a huge factor in customer experience – an identical competitor that displays results two seconds slower will experience high abandonment rates. Design engineering is about tradeoffs between display aesthetics, and the concise representation of data returned rapidly from low-latency sources.

When it’s incomplete, it’s ready to show

INABIAF. It’s not a bug, it’s a feature, goes the old developer maxim when software users don’t understand what they are seeing on the screen. 

Successful creative agencies never assume that a concept needs to be fully fleshed out before clients can accept it. They iterate rapidly on design and copy comps or sketches, in order to zero in on the client’s preferences, as well as measuring the preferences of end consumers.

Revolutionary SaaS tools and smartphones apps accelerated design-first principles, as the current version of the application gets dynamically updated for the customer in near real-time. This continuous process merges redesigns into the CI/CD product lifecycle by introducing new user functionality and displays – even if they aren’t fully baked yet. 

‘Shift-Right’ practices such as real user monitoring (RUM) and feature flagging are great ways to gauge performance improvements and test functional integrity, but the biggest benefit is getting live customer feedback into the product design loop.

Laziness is the mother of innovation 

If great design takes 50% of the time required to perform a task away from the customer, that’s a winning product that frees up a drastic improvement in productivity.

The low-code space and RPA movements provided hundreds of ways to leapfrog between UI and process-driven design and drag-and-drop easy application development without the technical skill hurdles. 

The COVID crisis showed off the robustness of low-code for design-driven responsiveness to crisis conditions – take for instance the few banks that could step up with PPP relief loan applications using low-code within 3 months. 

Development teams themselves also enjoy design-centric tooling. I’m constantly surprised by new vendors that enter seemingly matured spaces such as CI/CD tools, IT operations, security and software testing with better UX as the lead value proposition.

Designing a diverse team

We are all complex, autonomous beings, operating in different modes as end users of technology. When designing technology for others to use, we must wear a functional engineering hat. A customer service hat. A security hat. A human-centric hat.

Leading creative organizations favor higher levels of diversity within their teams, not just in terms of ethnicity and identity, but in the different intellectual perspectives that variety produces. 

There are many unique ways of solving problems, and therefore there should be different types of thinking within your team’s makeup by design. Embrace these differences and cultivate them for design-driven success.

The Intellyx Take

Companies and industries that are internally project-focused rather than customer-focused are woefully unprepared for digital transformation.

Never settle for dogmatic standards when rapid innovation is called for. 

Don’t let anyone tell you there is one best way to build software when there are always multiple valid design-led approaches. Distinguishing between conceptual possibilities is the very stuff of design-led development.

The post Software development: Product-driven or design-led? appeared first on SD Times.

I have here the seeds of Intellyx’s 2021 retrospectives and 2022 predictions. Unlike most other pundits, we try not to state obvious observations as predictions, and we score ourselves on last year’s crop of conjectures.

Predictions from 2021

Appreciating Sir Issac Newton’s theory of gravity, I collected three apples that fell on Jason Bloomberg’s head for his 2021 Intellyx prediction set. Let’s see if they had gravitas.

First off, a dramatic counter-cyberattack against Russia in response to attacks like the SolarWinds hack. 

This one didn’t bear fruit–If anything, the rate of exploits and breaches in IT continued apace, crowned in December with the revelation of the widespread log4j vulnerability. 

We did see preventative effort and innovation from vendors attempting to ‘shift security left’ in the DevOps lifecycle to make it a developer concern, and open source collaboration toward wiring zero-trust, least privilege fundamentals into the underpinning componentry of microservices-based applications.

Second, the massive Bitcoin-Tether Ponzi collapse didn’t happen yet–but all the conditions needed have intensified tenfold. Times of economic uncertainty and a mistrust of institutions drove celebrity shills and unsuspecting marks to throw down real money for magic blockchain beans.

With over half of crypto exchange activity now circulating through stablecoin shell games, this failure is not a question of if–but when–the rug gets pulled.

Last, the pandemic and recession ending with a bang instead finished with a series of sputters and pops, as an inability to truly shake COVID-19 put a damper on economic relief and constrained global business operations. 

But in terms of IT, the wait-and-see period of 2021 gave way to an explosion of innovation and consolidation, especially in cloud-native, edge, and AI technologies, showing no signs of slowing down. 

Better still, workers in the digital economy made the greatest gains in 2021, as collaborative lessons, work-from-anywhere capabilities and a serious talent shortage meant many IT employees could afford to job-hop and demand better salaries and flexible working conditions from employers.

Predictions for 2022

First, a great weeding out of vendors. Overvaluations in the space will gradually give way to more responsible ways of evaluating the potential success of any vendor. Enterprises will become wiser about ROI metrics and refine their selection criteria to fit their desired architectural goals.

Vendors that can demonstrate value for paying customers will be poised to accelerate, while the fortunes of runners-up in each category will decline, resulting in layoffs and surprise fire sales.

This does not mean startup activity will decrease in 2022. Volatile conditions offer the most fertile ground for sprouting innovation to improve agility at scale and meet customer needs.

Observability will branch out into many forms. This solution category has consumed aspects of software performance, security, testing, development, issue resolution, planning – and all of the data and infrastructure supporting it.

Observability is no longer just for SREs obsessed with production. It must process data feeding ITOps, network analytics and AI learning tools, as well as assisting developers with many aspects of legacy modernization and migration. What specific kind of observability is needed for the work at hand?

Supply chain management will start to enter the IT mainstream discussion. Coordinating the many moving parts of SCM has always been a dark art beyond IT, even for the people running the cogs of supply chains — manufacturers, logistics providers, warehouses and retailers.

Even though software is just a bunch of bytes, responsible orgs will consider software and hardware supply chain dependencies in every architectural aspect of planning and provisioning digital capabilities.

Real global supply chains will also become the #1 growth market for edge computing and IoT. New combinations of device and sensor data will flow into tracking, analytics, AI-based forecasting, production planning and multi-party networks to modernize legacy SCM networks and ERP systems (many haven’t changed much since the nineties).

The Intellyx Take

I could have easily predicted that cloud adoption would grow, or another massive breach – but that would be like opening a fruit stand that sells store-bought fruit.

What will remain constant this year is change, and the determining factor of an organization’s survival will be its reaction speed for applying new technology to meet the chaos that change creates.

To make it in 2022, organizations must value people more than ever to negotiate change, and listen to the experiences of employees, partners and customers – above the preferences of their own executives and shareholders. Success is there for the picking.

The post 3 apples in 2021 vs. 3 oranges in 2022: Predictions appeared first on SD Times.

I’ve spent most of my life working with technology firms where testing was an unassailable virtue, and therefore, the concept of testing was constantly encouraged. Now, it seems like many companies are pushing QA upstream to customers.

The stakes for quality are still high. So why has software testing gotten such short shrift lately?

Test teams have changed

Remember when there used to be a QA team, separate from the development team in any decent-sized IT shop with a software delivery function?

This QA team staffed as many as one tester for every 3 to 10 Dev and Ops people. Test-driven development encouraged earlier unit and regression testing burdens to be shared between teams.

Unfortunately, first-to-market pressures truncated QA teams that faced ever-shortening test windows, and retained little authority to ‘stop the presses’ for quality issues. Many companies abandoned QA teams in favor of mingling testing and development. Who wants to be the buzz-kill that stopped the killer software release customers expected?

Test roles have changed

The sunset of the QA team also means we don’t have a ‘Head of QA’ any more. Titles containing “QA Specialist” or “Tester” became scarce about a decade ago. In a DevOps world, the testing function is increasingly integrated into pair programming or small Agile team exercises.

Some companies encouraged more coding on the part of testers, and more testing on the part of engineers, eventually leading to the rise of the ‘SDET’ (or software development engineer in
test) cross-functional role.

If developers must test their own code, and testers must become developers, who will independently validate that the software meets business requirements? Perhaps a magic testing box?

Test tools have changed

The grand age of automated testing tools has subsided. Richer freemium tools, and then, open-source software took over for the huge enterprise licenses sold by the likes of Mercury and Rational
and Segue from the Y2K testing days.

At this point, software observability became a hot new space, and testing lost its shine. Gartner even discontinued Continuous Testing as a product
category altogether.

Punting responsibility for testing

“There’s a tricky balancing act between QA and development,” Chris Cardinal, principal at CarbonQA, told me. “If you say ‘we’ll just let our customers test the software,’ I hope that it doesn’t come back to bite you royally. An entire brand can turn on bad app store reviews.”

Today, testing must still find a home within your process, or total failure will certainly catch up with your organization. That leaves several options:
Offload it to a new QA team. Why not restart with a tiger team of expert testers?

Offload it back to development. Better make sure they are incentivized for quality, not just speed.

Offload it to a tool. Test automation tools keep getting better, but don’t believe 100% unattended claims.

Offload it to a services firm. Benefit from specialized test vendors with their own expert methodologies and tool stacks that work closely with your team.

Offload it to customer support. Everything’s gonna be alright.

Offload SOME testing to your customers. Establish a beta tester program or try A/B, feature flagging and canary testing to shift-right. It’s not best for all workflows, but it may be the best real-
world test feedback you’ve ever had.

The Intellyx Take

This trend of hidden testing — and thinking we can hide testing — will pass. In the meantime, it’s kind of fascinating to watch how organizations can adapt and survive the change.

The post Why hide testing from development? appeared first on SD Times.

The post Analyst View: Shift testing left, but bank right appeared first on SD Times.

Looking back, you could see signs of a great digital scattering coming for many software development-related businesses — not only the ones catering to restaurants and service sector jobs.

Speaking of travel and hospitality, the move of all our favorite perennial IT tradeshows online was the first canary in the coal mine. Engineers are stereotypically aloof, so you might think virtual events would be a fine replacement for in-person interaction. Yet, the knowledge sharing and relationship building that happened at shows — as well as the business that advanced there — will be hard to replicate.

Companies without the digital backbone to shift to remote development and operations quickly found themselves in hot water. If constant planning meetings and fire-fighting war rooms are the norm, what happens when all of that is replaced by a miniature Hollywood Squares matrix of heads and screen cams?

Companies accounted for this change, for a few weeks, with grace and understanding that not everyone’s home makes a good office. Bad connections, barking dogs, interrupting kids. Employees with WFH policies had a head start here, by making such arrangements ahead of time. Some companies even vacated office space in stride, never looking back.

But the remote scattering of workers takes a toll. Does innovation and quality start to suffer — even as many IT staff commonly report working more hours to meet increased demand, unburdened with commuting? Knowledge workers become more distracted, or frustrated, or unproductive working at home, leading to a reconsideration of how to either instill some sense of culture online, or safely return some work to the office.

Engineers in a product-oriented organization appreciate self-determination, so long as they are contributing valued work. Shared platforms for remotely governing agile software delivery from requirements, to repositories, to release trains and issue resolution are improving in quality and interoperability every day.

The very environments from which we deliver software keep scattering as well, as the old three-tiered application stack in the datacenter gives way to SaaS-based platforms, cloud infrastructure and microservices, calling APIs and running workloads in ephemeral containers and serverless architectures.

Were we meant to move the application estate off-premises for good, along with the teams?

The outlook for permanent departure of IT resources from shared offices and datacenters isn’t 100% rosy, even for the software-driven company.

First, you have the need for (groan) IT Governance, and (groan) Compliance to standards, and (groan) Legacy Applications to maintain — you know, everything we’ve already built, the stuff that keeps the business running. This forces creativity about orchestrating both cloud and on-premises application infrastructure as a Hybrid IT application estate.

Zeroing in on the development shop itself, we start to see how the in-person Agile Scrum or daily standup meeting packs a lot of collaborative value, as creative solutions often arise from live interaction, and intangibles like camaraderie and morale naturally pull DevOps teams together. 

A few months in, the scattering hurts. Many companies are laying off IT staff due to business losses, or competitive takeovers. Other companies are seeing spikes in demand, and cannot recruit fast enough, let alone properly mentor the new staff coming into this decentralized workplace.

A full-stack developer friend recently joined a mid-sized company with several loosely interconnected teams. They were stunned to find that while DevOps practices and distributed cloud architecture were in the job description, very little ‘tribal knowledge’ could be conveyed.

Teams that worked together in the pre-COVID era take it for granted that newer employees come in with none of that situational awareness. What do I need access to? What review gets my code on the release train? Who supports my code on Day 2 once it is in production?

There’s no replacing ideas that come up amidst the scuttlebutt at lunch, or a tap on the shoulder — “can you look at my screen and tell me what’s going on here?” It’s OK to ask clueless questions and pose crazy hypotheses in person, with other humans. In text and email format, those interchanges are impersonal, and documented.

We don’t know when a new normal will be realized for software development. Until then, let’s embrace the need to solve this digital scattering with human empathy, and an understanding that we all want to deliver better software.

The post Analyst View: The great digital scattering appeared first on SD Times.

There’s no simple fix available here. Supplier relationships must be renegotiated or replaced, and existing facilities repurposed or built over from scratch, at great cost. Money and expertise may not be readily available to coordinate the changes needed.

In the software industry, we tend to think of constraints in project management terms: with productivity or features delivered, as governed by a budget function of time and resources, minus failures. Feed plans and component ‘designs and materials’ in one end of the software factory, and depending on how many skilled developers and testers are working together over time, excellent software ‘products’ roll out the other end.

Valuable innovation has never been achieved by treating the development shop like such a factory. This is why Agile methodologies were born, and the DevOps movement later took hold, to enable greater collaboration and buy-in, higher levels of customer-centricity and quality, and an automation mindset that accelerates delivery.

The software supply chain — coordinating a complex web of the right people, systems and data, all contributing at the right time to deliver software for customers — is now experiencing its own Black Swan moment in these unprecedented times.

Freeing teams for remote work, and forever abandoning live scrums and late-night Ops war-rooms won’t get us there by itself either. This useful trend was already in the works anyway, as many of the most successful startups of the last decade have relied on virtual teams of global talent to outpace geo-centric competitors.

It also doesn’t matter that instead of real boxes and containers, we’re moving ones and zeroes around in virtualized containers, with applications and services running on ever-more ephemeral cloud infrastructures. 

The software supply chain may still have ineffable constraints in common with supply chains of other industries, besides time and resources.

1. Liquidity. This is the #1 issue for any other supply chain — how efficiently does money flow through the system? Whole suites of financing, factoring and settlement solutions try to solve this in the conventional supply chain world, where margins are thin and the time value of money is critical.

In today’s SaaS and cloud-based IT world, customers buying on a monthly (MRR) basis may ask for leniency during a crisis, when funding for innovative new ventures is scarce. Partners will also be asked to step up and ease the burden. Budgets aren’t idealistic exercises for accountants to deal with anymore, as IT executives will become more conscious of cash flow than ever.

2. Collaborative forecasting. Supply-and-demand forecasting is never an internal exercise — it requires analysis, requests and promises among all parties before orders are issued and goods assembled and delivered. 

Any IT business unit would do well to evaluate its own ability to not only forecast customer demand, but understand the readiness of all of its services partners, component software vendors and infrastructure providers to successfully deliver on customer promises.

3. Inventory and WIP. Most ‘real’ companies maintain inventory buffers of both parts and finished goods, as well as a certain amount of work-in-process (WIP) in order to deal with volatile supply and demand, which represents an ongoing cost of business.

While the DevOps movement has it right that technical debt is a primary bottleneck to progress, there’s still a lot of code and software that has productive value and can’t possibly be replaced, especially if it is maintained by other parties. To top it off, the modernization work itself is inventory in the pipeline.

4. Quality and compliance. Meeting standards and delivering products that work as promised to meet SLAs and internal SLOs that avoid customer churn, penalties and risk is universal to all industries.

5. Life cycle service. In the automotive industry, it’s assumed that 60% or more of the total cost paid by customers for a vehicle will be spent on fuel, maintenance and parts, and not the initial purchase – so the necessity of capturing customer support and service revenue is more important than ever for software, even if some of that work is conducted by valued partners.

The Intellyx Take
These constraints seem like old hat to an old supply chain hack. Not that supply chain software vendors avoid hoarding inventory better than the rest of the software world — most wouldn’t retire a product even if it has one remaining install in a china factory in Timbuktu.

In all industries, the profitability of upgrading an existing customer is three to five times higher than that of capturing a new one. This is why some vendors take a pause on new deals or projects in favor of eliminating constraints in their software supply chains to deliver for existing customers.

The post Analyst View: What constraints disrupt the software supply chain? appeared first on SD Times.