Ipeleng Molete
The Home of Ipelatech's Blog

The Home of Ipelatech's Blog

Evolving Code

Evolving Code

Write code that keeps moving you forward

Ipeleng Molete's photo
Ipeleng Molete
·Mar 1, 2022·

4 min read

Table of contents

  • Introduction
  • Once Upon A Line - Setting up our World
  • The Goal/s of Writing Evolvable Code
  • And how does this tie in with the vision of Shepherd?
  • The Road Ahead


Evolvable Code is code that I don't have to look at again. Or if I have to, I know it's got escape hatches. What I mean by escape hatches is code I can safely change. A safe change is one that produces Evolvable Code - well whaddaya know? Kind of convenient, isn't it? But it should be! Let me explain, first by setting the context around the goal of writing Evolvable Code, then looking at the goal itself and how it ties in with the greater vision of Shepherd.

Once Upon A Line - Setting up our World

What we're doing here

The Shepherd System is a system (one rule, actually) - split data and behaviour - but doesn't really answer what to put in those classes. In the next series of articles, I'll try give my take on the answer with a bunch of conventions I've found useful to help me write code. It essentially means avoiding writing code like this:


class SomeClass {

    //class variables
    public/private/protected $xxx;

    //class functions
    public/private/protected function do_this() {}
    public/private/protected function do_that() {}

and do something like this instead:

class DoThisHandler {
    public function handle($args) {}

class DoThatHandler {
   public function handle($args) {}

class SomeClass {
   //takes in a DoThis or DoThat handler
   //you can use interfaces as well for dependency injection, like here
   public function some_method($args, $handler) { 

Note, each of these classes will have their own unit tests as well.

What does that achieve?

The idea is loose coupling. I just kind of don't like that idea a whole lot for this purpose. These days, I've been doing a lot of introspection and I'm challenging a lot of beliefs I've held and in the process thinking about this article, I confronted this term. It's a good idea, great concept, however, like a lot of great concepts, I feel somehow the original meaning has been lost in translation as a result of heavy usage. Like a giant game of Broken Telephone. There's nothing wrong with that, but I feel like it's too murky to capture the essence of what I'm proposing. I resist giving my definition, and adding to the confusion, so instead, I'll look at it from another perspective. For me, it feels like the other side of the coin to loosely coupled code is self-contained code. It also sounds a little more self-explanatory, and it feels closer to the original idea of objects in object-oriented programming. With that taken care of...

The Goal/s of Writing Evolvable Code

In addition to writing code that is testable and refactorable, writing Evolvable Code helps us write code that's self-contained. Loose coupling comes as a free feature.

And how does this tie in with the vision of Shepherd?

The process of creating Shepherd led me to do a lot of thinking, almost philosophically, leading me to asking questions like, "What is a system? Why do we have them? What's the most efficient way to use a system?". It's a topic I can go on about for hours (yes, I'm that boring!) however, for all our sanity, I'll just present the cliff-notes.

On why, well, the point of a system is to use it to establish an environment that's conducive to producing predictable results. The what is, a system is a set of constraints placed on a larger environment - like how you can't wear your bunny onesie to work, or whether to use 4 tabs or 1 space. Conventions become habits, habits become beliefs, beliefs become mindsets. The best systems are those people resonate with and turn into full-blown cultures.

The secondary goal of Shepherd is to provide a system for producing predictable code - predictable in the sense that, you know (you can predict) that you can change it safely. And remember how I said Safe Change = Evolvable Code? We're trying to establish constraints on code that remove obstacles and pave the way to writing Evolvable Code. These are the conventions I've come up with and use, and I provide them as a starting block for you to challenge your own beliefs and come up with your own conventions suited to your situation. And that, I think, is the primary goal of Shepherd. I like to think my ideas will be relatable enough for you to find use in them. I'm not preaching canon, I'm just trying to bring clarity to a situation that's confused me for years.

The Road Ahead

Looking ahead, this series will attempt to take a document the conventions I use throughout the development process. I try to keep things as simple as possible because it frees me to think about the solution to the problem I'm trying to solve, and not letting the code become a part of the problem! I plan to release the following articles:

  • Lean on your Tools
  • Evolving Language Constructs
  • Pre-Design Patterns
  • YAGNI as an Architecture Design Strategy
  • Tame your Tests

These will represent everything I know and use to write my code these days.

Salang hanthle!

*Cover Image

Share this