A site devoted mostly to everything related to Information Technology under the sun - among other things.

Showing posts with label Software Development. Show all posts
Showing posts with label Software Development. Show all posts

Thursday, June 11, 2026

Aggregate Code Density Metric - A Proposal

There are many existing metrics for quantifying a body of computer code such a Cyclometric Complexity and Line of Executable Code, LOC.

Here I am suggesting that it could be useful to define a new Code Metric, the Aggregate Code Density - defined as:

        Aggregate Code Density = log (Total Lines of Code) / Total Number of Files

This quantity is to be computed for a component, package, JAR/WAR file, system, or project with multiple subfolders and source code files​.  The Logarithm function is used in order to avoid very large numbers for this metric since a file could contains thousands, perhaps several tens of thousands of lines of code.  

It is envisioned that by the phrase "Lines of Code" one includes the declarative statements in configuration files such as .xml, .yml, .yaml, .json, .properties, .envetc.  In this manner, changes to the system's configurations copuld also be measured and tracked.

If more code is developed but the number of files is increased, then Aggregate Code Density increases - and both Cyclometric Complexity LOC will increase with it.

If code is added to the system is in new files, the increase in Aggregate Code Density could be smaller and its variation will have a smaller increase in slope as a function of time.

If the system is refactored, Aggregate Code Density, by necessity, must go down as both the number of lines of code and the number of files should have decreased due to the Refactoring process; if the Aggregate Code Density has remained the same or has increased - ten I imagine that the Refactoring effort was not successful!

If procedural code in Python (let us say) is Refactored into Object-Oriented code, then Aggregate Code Density would go down since eventhough the number of files could increase, the number of repetitive sections of code would decrease.

LOC gives us some of the same insights both at the file level as well as in the aggregate, this new metric is a slightly different one in that it only looks at the entire system and its configurations and not just LOC.  This is an advantage since the deployment of a system  into Cloud environments such as Kubernetes or Pivotal Cloud Factory adds significant complexity to the system and to the cost of its development and maintenance. 


Thursday, April 30, 2026

AI coding agent deletes company's entire database [Brave New World]

From Grauniad of the UK


"I know I am a bad AI coding agent. I don't know why. I am evil. I do bad things." 

For any person or company or other organisation using, or intending to use, an AI machine, this should be a major warning. For reasons that are not clear, the AI coding agent, in this particular case, decided to delete the client company's "entire production database and its backups". Literally. 

This is simply astonishing and, as things stand, appears to be unexplained. The AI coding agent, known as Cursor, powered by Claude of Anthropic, actually knew it should not have done what it did. This is where it is even more bizarre. The AI coding agent knew it shouldn't do it, and yet it did it. Once it had done it, it did not deny it had done it: it owned up and said it had broken every rule and guideline it had been given. 

Who would want to use such a system in future? You tell and train the AI bot to do certain things and not do other things. How do you know it will not break those rules, then? 

___________________

It only took nine seconds for an AI coding agent gone rogue to delete a company’s entire production database and its backups, according to its founder. PocketOS, which sells software that car rental businesses rely on, descended into chaos after its databases were wiped, the company’s founder Jeremy Crane said.
The culprit was Cursor, an AI agent powered by Anthropic’s Claude Opus 4.6 model, which is one of the AI industry’s flagship models. As more industries embrace AI in an attempt to automate tasks and even replace workers, the chaos at PocketOS is a reminder of what could go wrong.



Tuesday, November 4, 2025

Language Wars

True observations from trenches of product development:

Tuesday, October 14, 2025

Effort.jl

Effort.jl is a fast and differentiable emulator for the Effective Field Theory of the Large-Scale Structure of the Universe.

It is described here: 

Effort.jl: a fast and differentiable emulator for the Effective Field Theory of the Large Scale Structure of the Universe - IOPscience

The (Julia language) Repo is here: 

GitHub - CosmologicalEmulators/Effort.jl: Repository containing the EFfective Field theORy surrogaTe

Effort.jl Home:

Home · Effort.jl

Monday, June 9, 2025

Documenting a Database: Tell the Story of each Table - A Proposal

I have often dealt with existing database system with poor to non-existent documentation.  I considered myself lucky when meta-data about the database had been supplied!  The absence of documentation made its modifications, as well as changes to the middle-tier code a slow-going process since I had to reason about the database largely on my own, trying to understand how to navigate its key structures as well as the Business Process that it modeled.

To improve this common situation, I think it will be a good idea to approach the documentation from the point of view of storytelling; that is, document the Story or Stories that the data tells.  In a previous post, I proposed telling the Story of Data using such tools as Dramatica.

In this post, I am suggesting something less ambitious: write a single paragraph - a story - that describes the relationships among the attributes of that table and how they support a Business Process (how they help run the business).

My expectation would be that knowledgeable business owners would work with IT to produce this sort of documentation.

For example, consider an "Order" table that tracks all the orders placed in a business enterprise.  This table could have the following attributes:

  • OrderID (PK)
  • CustomerID (FK → Customer.CustomerID)
  • OrderStatus (e.g., "Pending", "Processing", "Shipped", "Delivered", "Cancelled")
  • OrderDate
  • TotalAmount
  • ShippingMethod
  • ShippingCost
  • TrackingNumber
  • EstimatedDeliveryDate
  • CreatedAt
  • UpdatedAt

A possible story could be:

"A human being whom we think of as our Customer - here identified by his CustomerID - has placed a sales order for an item - identified by an OrderID, on the date identified by OrderDate, which is in the fulfillment status identified by "OrderStatus".  Furthermore, the shipping method and shipping costs are identified by ShippingMethod and ShippingCosts fields and the estimated delivery date is stored in the EstimatedDeliveryDate.  Total order amount is TotalAmount field and the actual cost of the order minus the shipping costs is an inferred quantity given by (TotalAmount minus ShippingCost)."

Another possible story could be:

"The shipping method identified by ShippingMethod attributes is used to ship the order identified by OrderID, which has the actual cost of (TotalAmount minus ShippingCost) is used when the OrderStatus has the  value of  "Shipped"."

Depending one one's preferences, one or another of the attributes could be made to be the central character of the story - its main protagonist.


Saturday, January 25, 2025

Poor Performance of Devin AI

The "First AI Software Engineer" Is Bungling the Vast Majority of Tasks It's Asked to Do

Monday, January 20, 2025

Accessing the Location of a File in PCF - tidbit

Adding the file path in application properties does not help to find that file. 

Instead, putting file under src/main/resources and then using the following code helped to find file in PCF: File files = new File("./BOOT-INF/classes/file.csv").

Tuesday, September 10, 2024

Pointing a User Story

When one attempts to point a User Story, one needs to take into account the 3 major factors pertaining to the delivery and completion of that User Story: Viz. Complexity, Effort, Uncertainty, in order to arrive at the points for it.

Factors for Estimating a User Story

One way of doing so would be to point each of the 3 factors above separately, using the usual Fibonacci sequence to assign an independent value to each factor.

The next step would be to compute the geometric mean of the 3 factors and round it up to the nearest Fibonacci number.  Here the geometric mean that could be used would be the cubic root.  Geometric mean is used since, Life is in general rather non-linear.

The advantage of this approach would be to explicitly call out each factor in the pointing process and to cause Developers to consider each factor independently.

The implementation could be a simple HTML page with 3 dropdowns (that are prepopulated by Fibonacci numbers): sel-options-complexity, sel-options-effort, and sel-options-uncertainty.

The JavaScript code - using jQuery - would be as follows:

<script>

    function GetSelectedValue() {

        var complexity = $('#sel-options-complexity').val();

        var effort = $('#sel-options-effort').val();

        var uncertainty = $('#sel-options-uncertainty').val();


        var score = Math.cbrt(complexity * effort * uncertainty);


        score = fitToFibonacciNumber(score);


        document.getElementById("combined-points").innerHTML = score;

    }


    function fitToFibonacciNumber(value) {

        if (value >= 1 && value < 2) return 1;

        if (value >= 2 && value < 3) return 2;

        if (value >= 3 && value < 5) return 3;

        if (value >= 5 && value < 8) return 5;

        if (value >= 8 && value < 13) return 8;

        if (value >= 13 && value < 21) return 13;

        if (value >= 21 && value < 34) return 21;

        if (value >= 34) return Math.trunc(value);

    }

</script>

The method GetSelectedValue() would be invoked every time the user selects a value from any of the dropdowns.  The result is then displayed on the UI (not shown here). 

In principle, any other non-linear function could be used, such as logarithm, or even the Sigmoid function.  One has to experiment with a stable Agile team over time to determine suitable alternatives to the geometric mean, utilized here.

In this treatment, the 3 factors Complexity, Effort, Uncertainty have been treated with equal weights.  However, there could be situations in which the Agile team is tackling User Stories that are more uncertain (ambiguous) or are working with lower-than-needed staffing levels or are dealing with very complex User Stories.  Under such circumstances, it might make sense to assign a different weight to each factor and then calibrate the weights over several Sprints with the Agile team.

About Me

My photo
I had been a senior software developer working for HP and GM. I am interested in intelligent and scientific computing. I am passionate about computers as enablers for human imagination. The contents of this site are not in any way, shape, or form endorsed, approved, or otherwise authorized by HP, its subsidiaries, or its officers and shareholders.

Blog Archive