Why Developer Certifications are not Accredited

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

There are a number of industry organizations in the developer certification space including the ITCC (IT Certification Council), PCC (Professional Certification Coalition), and ATP (Association of Test Publishers). Interestingly, none of these organizations offer to accredit certification programs, or advocate for standardization in the industry.

I recently discussed the lack of standardization in the developer certification industry with Clyde Seepersad, Senior Vice President & General Manager for Training & Certifications for the Linux Foundation. “We haven’t been going the route of accreditation because frankly the customers haven’t cared.” He explained that a well defined process does exist for ensuring that certifications conform to professionally agreed upon standards through the International Organization for Standardization’s ISO Standard 17204: Conformity assessment — General requirements for bodies operating certification of persons, but Seepersad explains “it just hasn’t taken hold in the IT sector.”

As a former academic, the lack of accreditation in the developer certification space, paired with a general lack of interest in standardization, has been a shock to me. Without a governing body to oversee and guarantee the quality of certification programs, how can certification holders or hiring managers credit these often expensive and time consuming programs with upholding a level of excellence agreed upon by experts?

Let’s take a step back to consider the institution of accreditation in the sphere of postsecondary education in the US. The process of accreditation, which dates back to the 19th century, is a standardized means for demonstrating an academic institution’s legitimacy as determined by unbiased professionals. Accreditation is generally required by governmental programs, such as the Federal Student Financial Aid Program and the GI Bill. For degree-granting 2 and 4-year universities and colleges, the U. S. Department of Education (DOE) empowers accrediting agencies to determine if a higher education institution meets certain standards. Accrediting agencies typically determine a program’s quality based on the following criteria, outlined by Robert Kelchen for the Urban Institute:

Regardless of accreditor, receiving or renewing accreditation is generally the same. A college begins by conducting a self-study, in which the institution evaluates itself based on the accreditor’s criteria and writes a report. Peer reviewers (usually faculty members and administrators from other accredited colleges) then visit the campus to gather additional information before the accreditor issues its judgment. These judgments include unconditional reaccreditation for up to 10 years, shorter periods of reaccreditation, sanctions or warnings that continue accreditation but require the college to fix issues in a short time, and denial or termination of accreditation.

Accreditors typically judge a college based on five broad standards.

  • The college’s mission must be appropriate for the accreditor.
  • The college must have adequate governance structures and an independent governing board.
  • The college must demonstrate financial health—the ability to continue operating throughout the accreditation cycle. This is the most common reason colleges are at risk of losing recognition (GAO 2014).
  • The college must have sufficient academic resources, including faculty members, facilities, and library resources.
  • Finally, the federal government began requiring in the 1980s that accreditors use student learning outcomes as a standard. But because explicit standards were not set, the implications of this change are unclear (Ewell 2010). For example, regional accreditor Middle States requires 3 institutions to define the goals for each educational program and offer appropriate assessments—a fairly broad requirement (MSCHE 2014).

This system isn’t perfect. Some have complained that the accreditation process limits innovation; rewards gatekeeping, cronyism and backscratching; ignores rival educational forms (certifications, MOOCs); and is unduly time and resource consuming. However, for all its issues the merits of engaging a disinterested third party to peer review these programs is still the most scientific means for ensuring a consistent level of quality.

What consequences have resulted from the developer certification industry’s decision to reject systems intended to standardize quality such as accreditation and ISO Standard 17204? The autonomy from oversight enjoyed by certification-distributing bodies engenders a sort of totalizing brand loyalty in its certification holders because, by burdening the certification-distributing vendor or foundation with quality maintenance, consumers endow these organizations with an inordinate amount of trust.

For vendors and foundations that increasingly include certifications among their marketing toolbelt this is a positive consequence. Historically some developers have downplayed their certifications, but today many, like AJ Yawn, Founder & CEO ByteChek, proclaim them proudly:

A second consequence of this standardization-less paradigm is logistical. If the learning objectives that each certification upholds are proprietary to the body that issues it, and therefore differs from distributing institution to distributing institution, then it is nearly impossible to compare the educational excellence of certifications with overlapping subject matter. There is very little parity between the CNCF’s Certified Kubernetes Administrator (CKA), Red Hat Certified Specialist in OpenShift Administration Certification, VMware Certified Professional – App Modernization Certification (VCP-AM), and Google’s Professional Cloud DevOps Engineer. All things being equal (vendor/ vendor-neutral; no employer mandate; money is no object), how do developers choose a certification path?

In the absence of universally agreed upon metrics to gauge certification distributors, developers often depend upon word-of-mouth to determine which certifications will successfully upskill their team, and which will not. This reliance on peers, “success stories,” and brand loyalty very easily bleeds into an emotional response, as developers have only squishy ideas of confidence and suspicion upon which to base their decisions.

While the lack of external accrediting bodies has not deterred certification distributors, the need for standardization has arisen in an obliquely related field: that of digital badges. The Mozilla and MacArthur Foundation’s Open Badges program, a sort of visual diploma smooshed with an NFT, uses blockchain technology to provide assurance that those claiming to have earned a certification have actually done so. Although Open Badges takes no hand in determining the value of the certification badges it issues, one can be assured they are durable, interoperable, and genuine.

A black box currently obscures the pedagogical aims and metrics of developer certifications. At worst, this can result in the fox guarding the hen house. Currently vendors and foundations are free to lower standards and leave those who depend upon these certifications in the lurch if they can’t perform at the level promised. Yet a legitimate fear of brand dilution motivates certifying institutions to maintain excellent certification in this constantly evolving space. If quality slips, developers will notice and act on this distrust by refusing to hire certification holders and urging their colleagues to follow suit.

Certifications—and training more generally—is a core aspect of many modern technology companies, and it behooves them to ensure these credentials are worthy brand ambassadors.

Disclosure: AWS, Google Cloud, Red Hat, and VMware are RedMonk clients.

This is the 3rd post in my series on developer certifications. If this topic interests you I recommend reading my previous posts:

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *