<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Articles on Kospex - Git Analytics</title><link>https://kospex.io/articles/</link><description>Recent content in Articles on Kospex - Git Analytics</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 12 Jul 2026 10:00:00 +1000</lastBuildDate><atom:link href="https://kospex.io/articles/index.xml" rel="self" type="application/rss+xml"/><item><title>Are security vulnerabilities an indicator of development testing practices?</title><link>https://kospex.io/articles/vulnerabilities-testing-indicator/</link><pubDate>Mon, 10 Mar 2025 18:34:57 +1100</pubDate><guid>https://kospex.io/articles/vulnerabilities-testing-indicator/</guid><description>&lt;p&gt;&lt;em&gt;TLDR&lt;/em&gt;: Security vulnerabilities might be an indicator of low automated unit, integration and regression testing capabilities. Finding vulnerabilities is easier than fixing them as bug fixes need to be tested. Identifying libraries that are getting behind in versions is one indicator of code repository health.&lt;/p&gt;
&lt;p&gt;When I first meet a development team, I like to ask three questions to gain an understanding of where they are at:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;How often do you release? (e.g. daily, weekly, monthly, quarterly, on demand or adhoc)&lt;/li&gt;
&lt;li&gt;How often can you release? (e.g. they can release quickly but don&amp;rsquo;t)&lt;/li&gt;
&lt;li&gt;How much manual testing is required per release?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;While answers can be subjective, when there is a higher manual testing and a longer release cycle it more likely it&amp;rsquo;s going to be harder (or more intensive) to test security fixes and their impacts.&lt;/p&gt;</description></item><item><title>What are orphaned repos and why should you care</title><link>https://kospex.io/articles/orphaned-repos/</link><pubDate>Mon, 10 Mar 2025 17:50:26 +1100</pubDate><guid>https://kospex.io/articles/orphaned-repos/</guid><description>&lt;p&gt;&lt;em&gt;TLDR:&lt;/em&gt; If no one knows the code, how will you fix or redeploy it? Knowledge of code is important to maintain, operate and make bug or security fixes. However, removing unused repos might improve focus by removing clutter.&lt;/p&gt;
&lt;p&gt;In the book, The Mythical Man-Month by Fred Brooks, it talks about disproportionate amount of time developers spend thinking compared to coding. Some say that that source code is only 30% of the development process, with thinking, discussions and discovery being the other 70%. So even if we&amp;rsquo;ve got the code, we&amp;rsquo;re missing the thinking which is still in the developers head. Even documentation might not do justice to that days or weeks of thinking and discussions which occurred.&lt;/p&gt;</description></item></channel></rss>