We use the word “maturity” often in the software business, however is there any clear meaning shared by the whole industry? It is typically made use of to describe software or a software organization, but a project’s maturity level is ultimately a subjective judgement. Nevertheless, once you understand the context of the software and your organization, there are some proven metrics such as project activity and age that can be made use of to provide you an idea of whether a piece of technology is mature enough for your needs. So what are some generally relevant maturity metrics? Offered the value of building applications on trustworthy, mature technology, this is a vital question that we need to explore.
Why We Want Maturity
In open source tasks, the main benefit is having a big amount of developers using, testing, improving, and solidifying the code so that it can carry out reliably in the majority of situations. There’s also a higher quantity of information, documentation, and support surrounding the project when more people are interacting on it and using it heavily. When a project is considered mature, another benefit that users anticipate is stability.
When we make significant technology decisions, we do not want our version of that technology to become outdated or require significant updates in a year or more. We also don’t want to have to re-learn ways to use the technology due to the fact that of significant modifications to the API. Developers constantly need to keep learning, but if they are compelled to upgrade or re-learn a framework every couple of months, it’s difficult to focus on building new functions or doing anything else.
Stability also refers back to the huge developer community that a popular project may have. If a significant part of the community decides to quit working on a project, the quality of the project can begin to wear away. We want the community support behind a project to be steady. If a huge swath of developers are drawn away from the project you’re using by another, newer, more amazing project, or they have a conflict with the project management that triggers a mass exodus, then you lose a great deal of the community support that makes the project beneficial.
How We Prove Maturity
So how do you ensure that any new technologies you might want to execute in your software are mature? Typically, developers have the tendency to think they have a quite clear concept which jobs are mature based on the blog sites and tech news they read, which is a good idea to do, however it still relies on intuition and anecdotal proof.
What tough data can you use to support your hypothesis of whether or not a project is mature? And how do you frame that data in context? Maturity is defined really in a different way for Java enterprise developers versus universal JavaScript developers. This is just one example that reveals why you require to develop your context first.
Context For Maturity
The standard for evaluating a project’s maturity depends upon the technology environment you’re coding in and the level of risk-aversion in your industry and organization. An agile startup or an application with microservices can switch technology stacks without excessive influence on the user. A health or financial software department, however, has policies to follow. They might also have some extremely old applications that cannot be migrated to a new technology without a substantial user impact.
Maturity judgements can be very different between different technology environments too. While the fast-evolving universal JavaScript development community would think about Node.js and AngularJS 1.x extremely mature, a Java or C# organization might think about the entire Node.js ecosystem immature when compared to Java, C#, PHP, Ruby, or Python environments. Who’s right? Both sides are, since maturity is relative.
In the Java environment, the most mature frameworks and libraries will have been around for six to 10 years (Apache Maven is 11 years of ages and JSF is around 15 years of ages, for instance). For the Node.js ecosystem, a framework created in 2009, like AngularJS, is considered extremely mature if it still has a strong userbase (Ember.js, a comparable framework, is four years old and Backbone.js is five years old). The most mature databases will be over 10 years old (MySQL is 20 years old), while the less-mature (however still mature enough for many organizations) databases will have been around for 5 to 6 years (MongoDB is 6 years of ages).
If you’re evaluating the maturity of the language environments themselves, the things to measure would include the variety of tools that have actually had long life-spans and pervasiveness of the language in applications throughout the software market. Anecdotally, the experts I’ve spoken with throughout the years would put Java and C# in the most mature tier. PHP would be in the next greatest tier with Ruby catching up, and Python after that (even though it’s been around longer than all of them). The Node.js/ universal JavaScript community has an incredible amount of community contributions and is most likely the most dynamic environment right now. But that also indicates there’s a high rate of churn among the preferred frameworks and libraries in the community. In 1-2 years, the leaders in the Node.js and frontend JavaScript space might be using a completely various stack from the ones being utilized now.
Maturity Metrics
The context is vital, however you probably noticed that it’s still greatly based on impressions and the anecdotes of community leaders. There’s not a great deal of research study particularly focused on answering questions about project and environment maturity. However, there are several initial common-sense metrics that blog writers in the developer space have developed to help advice technology choices based on maturity. Some concrete meanings of maturity concentrate on the rate at which bug fixes, spots, and functions are released. If these updates are dedicated to a project on a steady schedule, and the those changes/fixes in each release rarely impact backward compatibility or usability, then a project is generally considered mature. However once more, this is a flexible definition that must depend upon your organization’s specific requirements. That’s why you ought to consider innovative ways to measure and cross-tabulate the following maturity metrics:
- Number of users
- Variety of contributors
- Frequency of bug fixes/patches
- Number of outstanding concerns
- Repository statistics: GitHub stars, watching, forks, and variety of other repositories using the project; or comparable statistics.
- Number of Stack Overflow questions: Tag appeal, questions answered.
- Frequency of new features
- Release label: Is it still in beta? At version 1.0? “production all set”?
- Frequency of API modifications: Is the API steady and not getting usability changes commonly?
- Existence of a “core” team of developers: Focused team that reacts to bug files faster, tests more rigorously, and is more strict about preserving project standards.
- Amount of documentation: API, books, tutorials, and blog sites. Does not merely concentrate on the syntax but has examples for approaches and buildings.
- Frequency of community reactions: Experienced users ready and able to assist other users. Are they constructing extensions or working on the core framework?
- Presence of a business backer/steward company or non-profit: If the steward or owner company is too controlling with the project, it can trigger the community to suddenly desert support for the project.
- Variety of high profile site/app examples: If the technology is used by several companies with difficult use cases, then the project is more likely to be reputable.
- Variety of “horror stories”: The more of them that the community understands about, the better. Every project has them, and if they don’t, it means that the project probably hasn’t been checked as heavily in as many difficult situations.
Keep in mind, it’s vital to isolate these statistics within the context of your technology ecosystem. A project might not look like it has a lot of users till it’s compared to other similar tools within the environment. Qualitative analysis will also be very important in judging a project’s maturity too. If the bigger part of an ecosystem’s developer community thinks a project is mature, it should be considered.
Other sources for maturity metrics besides GitHub and Stack Overflow include the following sites, which provide genuine web technology usage stats:
- BuiltWith
- W3techs
- Wappalyzer (Includes certain prominent users of each project).
- Stackshare.io (Has technology stacks listed for numerous prominent companies).
As for what you can do with these stats, an old, however still pertinent article by Rob Ashton has several fascinating data comparisons that he did on JavaScript frameworks which you could copy or customize.
The Dangers of Clinging to Maturity.
Maturity at all expenses isn’t really constantly the ideal thing to do. All of us understand that technology moves fast for a reason. Much better tools and frameworks emerge over time, and if you do not want to get left behind by competitors, you frequently need to think about whether the cost of moving to a more recent technology is less than the cost of possibly loosing business. Depending on the technology environment and industry you’re operating in, you’ll need to determine an estimated number of years you expect to remain on the very same technology stack prior to you need to rewrite components and alter large sections of that stack.
It’s specifically challenging to maintain when patterns and modes of software design are regularly changing. There may be a suite of tools that is really mature, however maybe the tools were developed in a time when applications were built in a different way than modern applications. It’s crucial to know when the technologies you are using have reached or are approaching obsolescence.
But remember that as new developers go into the workforce, the market as a whole tends to forget a few of the important ideas and problems we’ve attended to in the past, and sometimes, we reinvent the wheel or do things in a less optimum method with the new frameworks we develop. Developers, like technology, also have to develop in such a method that their knowledge grows however does not get left.
