Maturity Dynamics in Modern Software Engineering

Fun with expressing software systems, generally, as periodic functions oscillating between limits defined in terms of Exploration and Maturity.

---

Software System Exploration is:

• Ideally combined with work to axiomatically and continuously prove the result of a fruitful exploration, especially as iteration proceeds.
• Often very similar to “Feature Development” in common parlance/framing.
• Sometimes emancipated by the question, “What fruit can I shake out of the tree that hasn’t been described yet?”
• Characterized by introduction of new nodes or increased number of edges across system’s nodes.

---

Software System Maturity is:

• A controlled, temporally-bound cessation of feature development. Compare to Software Death, the uncontrolled cessation of feature development.
• Marked by axiomatic proof of the system’s feasibility in at least two ways, but ideally not so many ways that the system becomes inflexible to change.¹
• Also worth nothing that too few methods of proof will result in inflexibility to change.²

---

Why Two Ways?

Most software systems are products. One way to prove these systems is to ensure that people are paying money for them. People do not normally pay money for axiomatically unprovable software systems.

But if your only mechanism of provability is that people are giving you money, you could easily lose sight of whether or not you have a provable system, which would render the system immediately unprovable and unprofitable.

---

Axiomatic Provability and Overcoming Incompleteness

There are limits to the provability of all systems — so it goes for things in the universe.³ But you should still arrive at a certain level of comfort in the provability of your systems, because the unprovable things are actually just really ridiculously uncommon.

Practically speaking, no system contains features that are truly unprovable. Clasically unprovable systems are so far outside of (or deeply inside of, straddling the atom level) the boundaries of our day-to-day reality that they are generally not worth speaking about, except in the presence of integration with another system that, itself, is on the edges of provability.⁴

It’s way more likely that you come up against provability-versus-time-investment. “Do we invest in proving this piece of the system or not? And when should we?”

---

1. Inflexibility can creep in if the developer is overzealous about proof about what the system is. Teams of contributors, within and across disciplines, should share agreement about what the system actually is.↩︎

2. This inflexibility, co-orbital with Software Death, is Software Paralysis.↩︎

3. Gödel’s incompleteness theorems, Wikipedia↩︎

4. Joke example: the browser’s contentEditable/execCommand editing API complex, which, lately, is improving.↩︎