Bloom & Place devlog #1: why I'm building it

Software engineering is just everyday life

People act like software engineering is some sealed-off wizard thing. Most of it isn’t. As a concept, it runs on the same rules as normal human life.

Here is the whole idea. An app is not one big blob. It is a bunch of smaller systems, and those systems spend all day talking to each other. A scoring system, an input system, a system that decides where a plant is allowed to go. Each one does its own job and then has to tell the others what happened.

So the real question in any app is not “is the code clever.” It is “do these systems communicate well.” And that is a human question. I think a person’s relationships are only as good as the way they communicate. Two people who talk clearly and stay out of each other’s business tend to be fine. Two people who have to know every detail of each other’s lives to get through the day tend to fall apart. Systems are exactly the same.

That is what this final-year project is really about. On top it is Bloom & Place, a casual puzzle where you place plants according to what environment each one likes. That game is the vehicle. The subject underneath is getting the systems to communicate like adults.

How systems actually talk to each other

Say system A needs something from system B. There are two ways it can go about it.

The first way: A grabs B directly, reaches inside it, and pokes at its guts. A has to know how B works to use it at all. This is the coworker who cannot ask you to send a file without first learning your entire filing system, your passwords, and how your day is going. It works right up until B changes anything, and then A breaks too.

The second way: A does not touch B at all. A just announces “hey, this happened” out loud, and whoever cares reacts. A does not even know who is listening. This is a healthy team. You ask a coworker for a finished report. You do not need to know how they made it, what tools they used, or what their morning was like. You know what you can ask for, and that is it. That “what you can ask for” is the whole agreement between you.

Family gives you the warning version of this. Think about the one person in a household everyone calls for absolutely everything. Where are the keys, who is picking up the kids, how does the router work, ask them. For a while it holds. Then that person burns out or leaves for a weekend and the whole house stops functioning, because nobody built any other way to get things done. In software that person has a name too, and I will get to it.

So the goal is simple to say and hard to do: I want the systems in Bloom & Place to talk like the healthy team, not like the coworker who needs your passwords.

The unhealthy pattern has a name: tight coupling

The bad version is called tight coupling. It is when one system depends on the private, inner details of another one. The relationship where you cannot function unless you know everything about the other person.

This is not a new complaint. Larry Constantine named it back in the late 60s, as part of structured design, right next to cohesion, as a way to measure software you can actually live with. Sixty years later, projects keep rediscovering it the hard way. Mine did.

I lived this on a game studio internship last year. The game shipped fine. The codebase shipped a warning. Every system knew about every other system. Touch one and three more break. Add a feature and watch unrelated ones regress. Read an error trace and chase it through five middlemen before you reach the line that actually matters. Release dates slipped, not because the design was hard, but because every small change had gotten quadratically expensive.

That whole mess usually grows out of one shortcut: making a single global object that anyone can reach from anywhere, so systems stop bothering to introduce themselves properly. That object is the family member everyone calls for everything. It is not the disease. It is the painkiller you take so you do not have to think about the disease. The disease is that nobody ever decided how systems are supposed to find each other in the first place.

Good communication is measurable, not a vibe

Here is the part I care about most. I do not want to end this project going “trust me, the new version feels cleaner.” Feelings are not evidence. “Cleaner code” is a vibe. Coupling is a number.

And it really is countable. There are four numbers I lean on, and none of them need a math degree. Robert Martin popularized them in the 90s. Think of each system as a person, and their dependencies as the people they rely on.

Ce, how many people you lean on. Its real name is Efferent Coupling. It counts how many other systems this one depends on to do its job. High Ce is the person who cannot make breakfast without texting four people first. The more you lean on, the more ways your morning can go wrong.

Ca, how many people lean on you. Its real name is Afferent Coupling. It counts how many other systems depend on this one. High Ca is the person the whole office relies on. That is not automatically bad, but it does mean every time they change, a lot of people feel it.

The Instability Index, are you steady or shaky. This one has a tiny formula:

I = Ce / (Ce + Ca)

It gives a score from 0 to 1. Near 0 means rock solid: lots of people lean on you, and you barely lean on anyone. That is the dependable family anchor. Near 1 means shaky: you need everyone, and nobody really needs you. Neither extreme is “wrong” on its own, but the score tells you honestly what kind of citizen each system is.

SDP violations, leaning the wrong way. SDP is the Stable Dependencies Principle, and it is basically common sense: you should only lean on people steadier than you. You build your life around the reliable friend, not the one who vanishes every weekend. A violation is when a steady system depends on a shaky one. Picture the family anchor everyone trusts secretly relying on the flaky cousin who disappears without warning. The day the cousin flakes, the anchor wobbles, and everyone leaning on the anchor wobbles with them. That domino line is the exact thing I most want to drive to zero.

Put together, these four turn a fuzzy feeling into a scoreboard. Which also means I have to play fair and actually build the messy version too, then measure both. No stacking the deck. I would rather get punched in the face by my own data than write a thesis where the conclusion was already decided in chapter one.

Next

So that is devlog #1’s whole job: name the problem (coupling) and pick the ruler (Ce, Ca, Instability, SDP violations). No solutions yet, on purpose.

Devlog #2 is the baseline. I take the messy prototype exactly as it stands today and read those four numbers off it, including the line of code I am most embarrassed by. You cannot prove you cleaned anything up without an honest “before” picture first. The fixes start after that.