A useful metaphor

Think about the media (newspaper) industry. In particular, the dynamic between editors and journalists.

Editors instruct journalists. Journalists write the content or articles. Editors validate and edit their writings. The result: a publishable work.

Once the content has been created, editors publish it. Thereafter, they monitor the public's reaction. If need be, they clarify, correct, or follow up with another publication.

AI's capabilities promoted us to editors. We're not so bogged down by the grunt work of content creation anymore. We delegate most of that to our journalists. Our AI agents.

As editors, we instruct our journalists in natural language. We validate and edit their writings. Once we’re satisfied with the quality, we publish it (release it to prod).

After our release, we monitor the public's reaction. We clarify the behaviour of our solution to the business and stakeholders. We correct by fixing problems. We follow up with more deployments.

We do this continuously.

What's needed to be a great editor?

We need to be well-versed in the art of prompting. It’s how we instruct our journalists.

We must be skilled in grammar. Think programming languages, libraries, and frameworks.

Prose and writing style! It’s how the work feels when someone reads it. Think architecture, principles, patterns, and coding standards.

We need a process to optimise content creation from ideation to publication. Think Agile, Kanban, and DevOps.

Letting go. Letting go of the plan to be a journalist for one's whole life. Of wowing people with your brilliant writing (coding) skills. Clinging to that fantasy will prevent you from unlocking your inner editor.

AI helped me to let go of even more. But that's a topic for another day.

Editors also decide what topics will not be explored. Which articles will not get published. As Steve Jobs said, deciding what not to do is just as important as deciding what to do. Think YAGNI and the Tesla principle (the best part is no part).

Conclusion

Many engineers may have seen AI as an obstacle to their plan of being career-long journalists. Marcus Aurelius, the philosopher king, reminds us that the obstacle is the way. The obstacle is the way to a promotion. AI is the way of the editor!

School of Thought

There may be many clean architectures (in lowercase) out there. The one I'm referring to is Uncle Bob's Clean Architecture. Hence the capitals.

Ivar Jacobsen's ideas (Object-Oriented Software Engineering: A Use Case Driven Approach) influenced it. And it resembles Alistair Cockburn's Ports & Adapters (Hexagonal) Architecture.

Fun fact: Uncle Bob and Alistair Cockburn are two of the Agile Manifesto's seventeen authors. Legends. Let's explore their architectures.

The gist of it

Clean Architecture is about the separation of concerns. In particular, the separation of business rules from I/O concerns.

Business rules may not know about (depend on) I/O concerns. I/O concerns may know about the business rules.

I/O concerns

Input/Output (I/O) concerns are how your application gets and outputs data. It's the delivery mechanism of the data.

API endpoints, database integrations, integration to downstream systems or services (APIs), and user interfaces are all I/O concerns. Ways data flows into and out of your application.

Business Rules

Think of business rules as what the system must do, independent of I/O (data delivery) details.

Business rules include the code for use cases.

For example, consider a use case that says: 'A user must enter their email and password to register'. Notice it doesn't include I/O details — like capturing it in a React frontend, sending it to a .NET API, or saving it in a SQL database.

Very demure.

Whiteboard

Let's look at some lines.

A prominent architectural boundary separates the business rules and I/O concerns. Notice how the source-code dependencies only cross the boundary in one direction: from the I/O side to the business rules.

How can a business-rule service call a class in an I/O layer if it's not allowed to depend on it? By inverting source code dependencies such that it points against the flow of control.

Instead of making a business rule service call an I/O class, we make it call a business rule interface. An I/O class implements that interface. Notice how the 'DbService' class implements the 'Repository' interface.

At runtime, an Inversion of Control (IoC) framework will 'plug' an instance of the I/O class into the interface, which acts as a port.

Ports & Adapters

Ports & Adapters (Hexagonal) Architecture works the same. It also has an interface at the point where an I/O concern calls a business-rule service.

Ports

There are two types of ports:

• Primary: the interfaces that are called from the I/O side (and implemented within the business rules).
• Secondary: the interfaces that are called within the business rules (and implemented in the I/O side).

Adapters

Adapters are the classes in the I/O layers that implement the ports.

Independence

Suppose the database needs to be replaced by a downstream API. In this architecture, we let a class in the integration (to downstream APIs) layer implement the secondary port instead. No other code changes needed!

Rules first

The business rules are the central organising principle. It drives the design.

Suppose you add a feature that'll include multiple layers. I recommend you start at the business rules layer. Develop and unit test it completely, first. Thereafter, add the other layers.

Try not to start at the I/O layers. Especially the database one! Its internal structure (such as a SQL database's relational model) may 'peer pressure' the business rules into looking and acting like it.

The Why

Clean Architecture reduces the long-term cost of software by making code easier to understand and change.

Here's the logic:

• The easier it is—for us and our AI tools—to understand code, the faster we can change and test it, with precision.
• If we can change one concern without affecting another, it's even faster.
• The faster and safer the changes, the cheaper the software.

Clean Architecture does this with how it separates concerns.

The next generation

My Millennial and Gen Z peers and I built MonoLISA on the principles of Clean Code and Clean Architecture. MonoLISA guides how we do Clean Architecture in our backend monorepos.

Not only did we solve our problems. But we contributed to this school of thought, too. We understood the assignment!

Conclusion

Clean Architecture. Ports & Adapters. MonoLISA. It's how we enable ourselves and our AI tooling to quickly understand and change code, with precision.

What's leadership? What exactly should a Tech Lead do? I wrestled with these questions when I became a Tech Lead. This year, I wrestled with a new one: Should I consider a managerial position? Join me as I reflect on my leadership journey, tackle the last question, and articulate my leadership signature.

Genesis

In January 2009, at 20, I started working as a full-time engineer. I had an international diploma in software development and decided to continue my studies for another two years (part-time) towards a BSc (Hons) Business Information Technology degree, which I funded with my salary.

Our part-time class consisted of many fellow full-time developers. I recall one of them's desire to pivot into management. I didn't get it. At the time, I loved being a developer so much that leadership wasn’t something I considered.

Becoming a Tech Lead

Fast-forward to 2020. I remember the day my colleague congratulated me on becoming a tech lead. I was surprised. 'Where did you hear that?' I then learned the head of our space made two of my fellow engineers and me tech leads.

I was honoured and happy. I got a tech leadership role and could stay close to the engineering. Perfect!

It wasn't my first leadership role, though. I formally taught wushu (kung fu) group classes (on Tuesday and Thursday evenings) from 2011 to 2018. My students were fit, strong, and skilled. They also performed well at competitions!

Even so, I struggled to articulate to myself what leadership is. That freaked me out! I also asked our leader what my tech-lead responsibilities are. 'You tell me!' he replied. No pressure, Chris.

Defining leadership

I went down a rabbit hole to find out what leadership truly is. I read many articles, watched many YouTube videos, and did a leadership crash course. But I wasn't satisfied. Something was missing.

My aha! moment came when I stumbled upon a video in which Steve Jobs defined leadership.

What leadership is is having a vision; being able to articulate that so the people around you can understand it; and getting a consensus on a common vision.

It resonated with me. I found the essence I was looking for. As a result, I made vision the central organising principle of my leadership style.

Defining a Tech Lead

I found the writings of Patrick Kua while searching for the definition of a Tech Lead.

A perspective of his that I like is that the Tech Lead role is an intersection of three others: Developer, Architect, and Leader. Another is that while a team leader or manager leads the general 'What', a tech lead leads the technical 'How'.

Right! We lead the technical ‘how’ with developer-architect prowess and contribution, while partnering closely with business and management on the ‘what’.

Visioning

We get vision from business and the powers that be at the levels above us. Think of it as macro vision.

But here in the trenches, close to the details, there are problems only we have the context of and understand. Problems such as unnecessary requirements, bad practices, complex design, messy code, technical debt, inefficient process, etc.

As a Tech Lead, I've provided our engineers with the vision to solve many of these problems and to prevent them from happening again. Think of it as micro vision.

Each micro vision sparks a process of change. I'd suggest a micro vision to my peers, we'd build it into our shared vision, and then we'd implement that.

It turns out I'm a natural at micro visioning. Over the last few years, I've provided a steady stream of micro visions for 'how' we'll promote the macro vision 'what'.

The 4-CAPS+ Leadership Framework

To up my leadership game, I successfully completed the executive program Leadership in an Exponentially Changing World at MIT's Sloan School of Management. It taught me their 4-CAPS+ Leadership Framework.

It advised that we articulate our leadership signature — our unique way of leading. Let me conclude this article by doing so.

Conclusion

I lead with vision and from the front. I lead by providing a steady stream of ideas or micro visions, building them into shared visions with my peers, and empowering the team with what they need to implement them. I do so 'from the front' by being strategically hands-on and involved with the engineering.

What is MonoLISA?

MonoLISA is a mnemonic for monorepo practice with:

• Layered Libraries

• Interface Segregation

• Single Responsibilities

• Agile Architecture

MonoLISA is a pattern for crafting code repositories that are easy to understand, change, and deploy to infrastructure in various ways.

Value

The more difficult it is to change software, the longer it takes. The longer it takes, the more expensive it'll be.

Our experience is that we spend more time changing the code of existing features than writing code for brand-new ones. No wonder Constantine's Equivalence states the cost of software is approximately equal to the cost of changing it.

MonoLISA lowers the cost of code changes.

Monorepo practice

The 'Mono' of MonoLISA.

A monorepo is a single git repository that holds the source code for multiple applications and libraries, along with the tooling for them.

Let's consider the elements of this definition.

Libraries

Libraries (also known as modules or components) in MonoLISA represent features. It's where the logic or 'functionality' of features are written.

Place libraries in a dedicated folder, such as 'libs'.

Applications

Applications in MonoLISA are the launch or deployment vehicles of libraries. They are shells (with little to no logic) that string (or bundle) libraries together for use. An executable is an example of an app.

Place apps in a dedicated folder, such as 'apps'.

In MonoLISA, libraries must be ignorant of apps. As a result, the libs folder may not be a subfolder of the apps folder, and vice versa. Also, libraries' source code may not depend on apps.

Tooling

In MonoLISA, a specialized tool should be used to manage the monorepo. It should be clever enough only to validate (lint, unit test) and build (compile) the code that your changes affected.

Monorepo in style

Many may picture a monorepo as a 'monolithic' repository with a ton of code. In MonoLISA, it doesn't have to be. It can be a monorepo in style rather than scope.

For example, you could use MonoLISA for a single application. The repo's apps folder would then contain one app.

Layered Libraries

The 'L' of MonoLISA.

MonoLISA achieves separation of concerns (SoC) with:

• Layers to separate technical concerns.

• Libraries to separate the concerns of actors.

Layers

Define a layer for each high-level technical concern.

Domain (business rules), API (endpoints), database (repositories), and integration (to downstream services) are examples of backend layers.

Create a folder for each layer in the libs folder. For example:

libs
- domain
- api
- db
- integration

Libraries

Create libraries for actors within the layers.

Actors

An actor is a role a user plays the moment they act on the system.

For example, if you are developing an email app, the user could be seen as an ‘inbox viewer’ actor when they view the inbox and a ‘draft editor’ when they write an email.

libs
- domain (layer)
  - inbox (lib)
  - draft-editor (lib)
- api (layer)
  - inbox (lib)
  - draft-editor (lib)
etc.

Interface Segregation

The 'I' of MonoLISA.

The idea of the Interface Segregation Principle (ISP) is for your code to know as little as possible. In particular, it says a source-code construct should not depend on (use) interfaces with more members than it needs.

Imagine a class that only needs a client's first and last names as a source-code construct that must follow the ISP.

The following violates the principle, because Client has unneeded members:

interface Client {
  firstName: string;
  lastName: string;
  age: number;
  email: string;
}

class ClientDetailsService {
  generateFullName(client: Client) {
    return `${client.firstName} ${client.lastName}`;
  }
}

The following honours it:

interface Client {
  firstName: string;
  lastName: string;
}

class ClientDetailsService {
  generateFullName(client: Client) {
    return `${client.firstName} ${client.lastName}`;
  }
}

In MonoLISA, a library is the source-code construct that may not depend on interfaces with unneeded members. The interfaces used by that library must be defined within it. That means whatever depends on (uses) that library will need to map to its interfaces.

The libraries of at least one layer in MonoLISA must adhere to the ISP.

Single Responsibilities

The 'S' of MonoLISA.

In MonoLISA, each library must adhere to the Single Responsibility Principle (SRP).

The SRP says a library must have a single responsibility and defines responsibility as the needs of an actor. In other words, each library may only serve a single actor.

The email-app example under the 'Actors' section earlier adheres to the SRP because it has libraries for the 'inbox' and 'draft editor' actors. Without the SRP, an engineer may have created an 'email' library with both responsibilities.

Agile Architecture

The 'A' of MonoLISA.

A Waterfall process has Big Design Up Front (BDUF). Teams that practice BDUF make many significant design decisions upfront. For example, they may decide to have 𝓧 microservices before they start development and fashion their repos around that decision.

Agile has 'small design up front'. Just enough design decisions are made to kick off development, and the others are deferred to the iterations (sprints) in which they're needed. The design evolves or emerges over the course of iterations.

MonoLISA has Agile architecture because of its synergy with Agile. The ignorace features (libraries) have of how they're deployed (apps) allows us to change our deployment model with minimal effort at any time. This allows us to start with a simple deployment model, to defer deployment decisions, and to pivot when needed.

For example, we could deploy our libraries as a monolith first. After that, suppose we find it does not suffice. In that case, we can quickly pivot to microservices by adding an app for each microservice, plugging the relevant libraries into them, and launching them into infrastructure.

Acknowledgements

MonoLISA was developed under the technical direction of Burgert Vermeulen and me. We and our peers have battle-tested and refined it since 2021 with excellent results! For example, one monorepo that follows MonoLISA has over 100 libraries and 5000 unit tests. On a smaller scale, we also used MonoLISA on a monorepo (in style) with one app.

Uncle Bob's teachings on Clean Code had a huge influence on MonoLISA!

Conclusion

Monorepo practice. Layered Libraries. Interface Segregation. Single Responsibilities. Agile Architecture. MonoLISA! It's been guiding us to high-quality, lower-cost software since 2021. And it can guide you to it, too!

Think of 'her' as a personification of Clean Code.

Cycles

Software development has a cycle of requirements gathering, analysis, design, coding, testing, and operations/maintenance.

Waterfall executes this in a macrocycle where all analysis is done before design, all design before coding, and so on. Alternatively, this macrocycle's steps can be repeated across the length of a project in microcycles, known as iterations or sprints.

You need more than sprints to make you Agile. The teams of some questionable processes I worked in believed we were doing Agile because we worked in sprints. In retrospect, we were doing 'Waterfall in sprints' because of how we used them.

Sprints

The purpose of a sprint is to produce feedback.

The following is true when we plan: We don't know what we don't know. As a result, we base our plan on many assumptions or hypotheses.

In Agile, we figure out what we (including our customer) don't know with the feedback from sprints. We use it to test our assumptions early and continuously.

The feedback includes:

• Customer feedback
  • From seeing working software.
• Data
  • Velocity (the average amount of stories or story points completed per sprint).
• Misc. learnings
  • If the design is right.
  • How time-consuming it is to code.
  • Missed requirements.
  • Etc.

Waterfall in sprints

I define 'Waterfall in sprints' as a process with Waterfall thinking and sprints.

Waterfall thinking, in my definition, is the disregard of feedback, the tendency to delay the release of value, and the belief the initial plan can work.

Disregard of feedback

Waterfall lacks continuous feedback. If a team ignores the feedback from sprints, it's as if that feedback doesn't exist. Such a process is virtually 'Waterfall in sprints'.

Delayed Releases

In Waterfall, there's a big bang release. If an 'Agile' team produces features in sprints but delays their release until the project's end, their release pattern is identical to Waterfall.

Initial-plan confidence

Waterfall invests a lot of time in up-front analysis and design to produce a 'perfect' plan for development. With such an investment, a team may believe the plan will work.

They may think tuning their plan is unnecessary when they see themselves deviating from it during development. To adjust it would be to admit it's flawed.

This Waterfall thinking may motivate a team to catch up to their plan by drastic means, such as:

• Quality shortcuts

• Excessive overtime

The Agile Way

How can one convert 'Waterfall in sprints' into Agile? By fixing Waterfall thinking.

Ron Jeffries (an author of the Agile Manifesto) defined Agile as being consistent with the Agile Manifesto:

Let's use "Agile" to mean "consistent with the Manifesto".

. . . People are devising new values, principles, ideas and tools all the time. These may well be consistent with the Manifesto. When they are, we call them "Agile".

Let's work with this definition. The following is an alternative to Waterfall thinking, consistent with the Agile Manifesto.

Feedback

Pay attention to the feedback from your sprints. Learn from it and respond.

Responding to change

The Agile Manifesto says responding to change is more valuable than following a plan. If feedback informs an Agile team their plan won't work, they respond quickly to this change in project knowledge.

How? By tuning the plan. By turning the knobs of the iron triangle:

• Scope (Requirements)

• Skills (Resources)

• Schedule (Time)

Sprints give managers the feedback they need to turn these knobs early and continuously. They tune it by changing the scope, getting more resources (early enough to mitigate Brook's Law), or asking for a deadline extension.

Releases

Don't do big-bang releases at the end. Release value (usable software) to your customer early and continuously.

Principle #1 of the Agile Manifesto says:

Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.

Principle #3 says:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Initial-plan confidence

The initial plan is not perfect. Expect it to be flawed. Please resist the temptation to force it with excessive overtime or a compromise on quality.

Excessive overtime leads to burnout, which reduces the pace of the team. Sustainable Pace is an Extreme Programming practice to prevent this.

Principle #8 of the Agile Manifesto says:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Quality compromises can ruin a team's ability to sustain a good pace. The resulting technical debt will require interest payments in time. We should never compromise on quality.

Uncle Bob (another author of the Agile Manifesto) says:

. . . Low quality means low speed. Always.

The only way to go fast is to go well.

Not only is this consistent with Principle #8 of the Agile Manifesto, but also with #9:

Continuous attention to technical excellence and good design enhances agility.

Conclusion

We considered 'Waterfall in sprints' as the application of Waterfall thinking to sprints. Here's what's needed for such a process to go Agile: An early and continuous response to sprint feedback consistent with the Agile Manifesto. To more agility and less 'falling'!

Here, I'll explain why I believe YAGNI is an essential Agile ingredient and show how Elon Musk uses the underlying principle at SpaceX.

An Agile Principle

YAGNI is a principle from Extreme Programming (XP) that says a capability we think (assume) is needed in the future shouldn't be developed now. It's also known as Simple Design.

Five of the seventeen authors of the Agile Manifesto were Extreme Programmers. Its apparent inclusion in the 12 Principles of the Agile Manifesto is, therefore, no surprise.

Principle #10:

'Simplicity—the art of maximizing the amount of work not done—is essential'.

YAGNI maximises the amount of work not done by minimising the work on hypotheticals.

YAGNI prevents waste

Why would we want to maximise the amount of work not done? Because we don't want to produce waste.

Lean manufacturing defines waste as anything that doesn't add value and overproduction as a type of waste. Value is whatever the customer desires. We'd overproduce if we develop more than needed to meet our customer’s known desires.

There are many parallels between Agile and Lean. Kent Beck mentioned how reading Toyota Production System by Taiichi Ohno influenced his thinking and how he explained XP (before he co-authored the Agile Manifesto). He shared the following:

Just thinking of overproduction as a problem rocked my world!

If we add unnecessary functionality for our current requirements just 'in case' it's needed in the future, we're not adding any value now. If the hypothetical never happens (likely), the time & effort spent on it would've been wasted on overproduction.

Looking elsewhere

Doctors follow a YAGNI-ish practice. They only prescribe medicine for problems they know their patients have. Imagine the problems if doctors prescribed unnecessary medication 'in case' their patients have hypothetical complications in the future. Let's be more like doctors and only write specifications & code (prescriptions) for our customers' known needs, shall we?

It's not rocket science. Producing more than needed will cost the customer more. Speaking of rocket science, let's consider how Elon Musk uses the underlying principle at SpaceX.

Elon Musk's 5-step process

Elon Musk described his 5-step engineering process in an interview Everyday Astronaut had with him at SpaceX's Starbase. His second step is a principle that says you should try to delete a part or process step.

The following are quotes from the interview.

He recognises the in-case inclination of engineers:

'The bias tends to be very strongly towards let's add this part or process step in case we need it. But you can basically make in-case arguments for so many things...'

He gave an example of how they applied it to their rockets:

'So that's why the grid fins, for example, don't fold down because that's a whole extra mechanism that we don't need . . .

. . . But in any case it's a thing we could add later . . .

. . . But it followed the principle of, like, delete the part delete the process.'

I felt like I was in good company when I watched the interview. Elon Musk's principle is the same as YAGNI! With YAGNI, we prevent (delete) parts we don't need for our current requirements. If the part we prevented becomes a need in the future, we could simply add it then.

I love how he put the following:

'Possibly, the most common error of a smart engineer is to optimize a thing that should not exist.'

Genius!

Conclusion

YAGNI. Simple Design. Elon Musk's engineering principle. Think of it as the art of minimising overproduction. Let's strive to launch more by doing less!

Story points are ubiquitous in the Agile world. If you ask two different Agile teams what they are, however, you’ll likely get different answers. Some say it represents complexity or effort. Others say it represents a combination of qualities. And so on.

Here I’ll share why I define story points as ideal days and how this helps me with Agile estimation.

The confusion around story points

Story points estimate the effort or complexity required to complete a user story. It’s an alternative to traditional time estimates.

It’s popular in Agile because many software teams find it easier to estimate in effort than time. The idea is simple: You give a story a point (typically a number) representing its effort. The bigger the effort, the bigger the point.

I’ve worked with multiple teams that used various kinds of story points. Initially, I was not too fond of it because we didn’t have a consensus on how to convert those points to time. Some developers even felt that we didn’t need to do this. Having fuzzy estimates that couldn’t answer how long stories would take to implement felt silly to me.

For example, in one team, we used a Fibonacci sequence to standardise our points: 1, 2, 3, 5, 8, 13, etc. While this created consistency in the difference between points (aside from 2, each number is about 60% larger than its antecedent one), the numbering still felt arbitrary.

In another team, we used T-shirt sizes (S, M, L, etc.) to represent the effort or complexity of our stories. There was a case where another team I was in used a variant of T-shirt sizes, but in such a way that there was no objective proportionality to each other nor consensus on what each size represented. This complicated our iteration planning and backlog refinement sessions.

I didn’t believe story points were supposed to be so difficult. As a result, I went down a rabbit hole to find out what it ought to be straight from the horse’s mouth. That was when I discovered a living legend who’s done software for over 50 years: Ron Jeffries.

Going back to the old school story points definition

Ron Jeffries — one of the 17 authors of the Agile Manifesto — created story points. First used in Extreme Programming (XP), the original definition of a story point was one ideal day.

An ideal day represents the ideal circumstances for development. A day without meetings other than the daily standup. A day without distractions. Serenity.

Technically, an ideal day consists of about 8 hours of ‘implementation’ time, as Ron Jeffries calls it. Think of implementation time as when you’re actively working on a story in your ‘assembly line’. That’s when you’re actively developing, testing, integrating, or deploying the story’s code.

Note that this is not the same as elapsed or cycle time. Cycle time is the total time it takes to complete a story from when you started working on it. Think of it as the time from when it moves into the ‘Doing’ column to when it moves into the ‘Done’ one of your Kanban board.

For example, if you spend an hour a day implementing a story for eight days, its implementation time would be eight hours - or one ideal day - and its elapsed/cycle time would be eight days.

The benefits of using ideal days as story points

Having worked in teams defining story points as the old school ‘ideal days’, I’ve experienced this definition being more effective than the other kinds of story points we used before. Because it has an objective description that’s easy to understand and it’s easy to convert to traditional estimates.

Faster estimates with ideal days

Ideal day story points have enabled my peers and I to estimate our user stories faster because we don’t have to consider cycle-time concerns. For example, we don’t have to think about how much time we’ll have outside of meetings, responsibilities outside our projects, or when our team members will be on leave. We just imagine how long it will take to implement in ideal days. As a result, our backlog refinement sessions are more productive.

Easy to convert ideal days to traditional estimates

Ideal day story points allow us to convert our story points to traditional estimates based on the solid data produced by our iterations. By having traditional estimates, such as the number of actual days it will take us to complete a story, we are able to effectively communicate with our stakeholders and express the work time in terms they are familiar with.

We can convert our points to traditional estimates using our average velocity, where velocity is the average number of story points completed per iteration. To get our load factor, we divide our velocity by the days in the iteration. For example, if our average velocity is 30 points and we work in two-week iterations, the ratio will be 3 (30 points / 10 iteration days).

To know how long a story will take in actual days (cycle time), we multiply its points by the calculated load factor. A 1-point story will therefore take about three actual days.

Ideal days allow us to calculate our flow efficiency

With ideal days, we can measure our Kanban board’s flow efficiency with a fair degree of accuracy. Flow efficiency is the ratio of implementation time to cycle time. Because we use ideal days, our average velocity reflects our team’s average implementation time per iteration.

We can calculate our flow efficiency as the average velocity per implementer to the days in the iteration. To get the average velocity per implementer, we divide our velocity by the number of implementers (developers and QAs).

For example, if our velocity is 32 points and we have six devs and two QAs, the average velocity per implementer would be 4 (32 points / 8 implementers). Now we can apply the efficiency formula. The flow efficiency would be 0.4 or 40% (4 ideal days per implementer / 10 iteration days). Leadership can now ask why implementers can only spend about 40% of their days implementing (on the assembly line).

In retrospect, I remember a project where excess meetings were one of the main reasons for such low efficiency. I wish I had ideal day story points to do this calculation back then. That would’ve shifted some pressure away from us implementers to those who bogged us down in superfluous meetings.

Conclusion

I love estimating with ideal day story points. It’s easy to understand. Quick to estimate with. You can convert it to traditional estimates. And you can use it to measure your workflow efficiency. How’s that for a reason to go old school on story points?

Apple

Steve Jobs' strategy when he returned to Apple in 1997 (to save them) is an example of enabling-constraint thinking.

His strategy was to produce only four products: A desktop and a portable device with consumer and professional models. He got rid of the plethora of other Apple products. He constrained what Apple worked on to enable them to develop those four products, with focus and simplicity, to perfection.

I value his insight:

Deciding what not to do is as important as deciding what to do.

Think about it. Constraints are decisions of what not to do.

Process

Here's an enabling-constraint perspective on Agile process.

Iterations

Working in iterations constrains us from planning, analysing, and designing (in detail) too far ahead. That enables us to validate our assumptions early and continuously.

Initial-plan desires

Agile says responding to change is more valuable than following a plan. The feedback (data) from completed iterations may signal that the initial plan won't work.

If we constrain the desire we have to forge ahead with it, it enables us to respond well. We'll then have enough time to 'turn the knobs' of the iron triangle to drive the project to the best possible outcome.

Daily standup

The daily standup enables a team to assess their progress and give feedback to those in attendance. Constraining it to 15 minutes max enables dynamic and productive feedback.

Kanban boards

Kanban boards help us optimise our workflow. The WIP limits on columns constrain multitasking. That enables us to focus and resolve bugs quicker. As a result, we'll be able to complete more stories.

Extreme Programming (XP)

I love XP! It's my favourite Agile process. As a tech lead, I've relied on its practices to make our engineering productive.

XP's Circle of Life depicts these practices in a memorable way:

Pair Programming

Pair Programming constrains engineers from always coding alone. That promotes collaboration and enables them to have context of each other's work. It also bakes peer-reviewing into the coding process.

Test-Driven Development (TDD)

TDD constrains us from just writing production code. When doing it, we write unit tests first. That lets us know if our code works right after changing it. It also promotes more decoupled code.

Refactoring

Refactoring (a là the Campground rule) constrains us from just writing new code. We must continuously improve existing code (even if our peers wrote it). That enables our codebase to stay clean.

Simple Design

Most engineers seem inclined to over-engineer solutions. They do it just 'in case' it's needed in the future. Simple Design constrains this inclination to enable sophisticated solutions. It also reduces waste. YAGNI!

Coding Standard

A coding standard constrains us from coding however we want. That enables engineers to understand each others' code quickly. And reduce the cost of code changes.

Sustainable Pace

A software project is a marathon, not a sprint. Sustainable Pace constrains how often we work overtime. That prevents us from burning out.

Continuous Integration (CI)

CI pipelines with quality gates constrain us from merging broken or not-up-to-standard code into the main branch. That enables us to automate the enforcement of many standards. And have a trunk that's always ready to ship.

Small Releases

Small Releases constrains large-release (Waterfall) inclinations. That enables our customers to get early and continuous value. And us to get early and continuous feedback. Furthermore, it reduces the risk of deployments.

Customer Tests

Customer Tests are those tests included in the specifications of stories (also known as Acceptance Tests). It constrains developers from declaring a story as developed until all its acceptance tests have passed. That enables better flow by reducing bugs.

Whole Team

The practice where those working on a project co-locate (sit together). It constrains individual members from working wherever they like. That enables serendipitous and nonverbal communication.

Social Thought

Who should choose enabling constraints? Tradition suggests the answer lies in a balance of subsidiarity and solidarity.

Subsidiarity is a principle that says regulation should happen on the local level. By this principle, the team defines its enabling constraints.

Solidarity is about the unity and alignment of the whole. It motivates a central authority (such as the federal government in the USA) to regulate the entire organisation. By this principle, a central body chooses the enabling constraints.

Because a central authority isn't in the trenches, they may not know the best solutions for local problems. A balance of subsidiarity and solidarity is therefore needed.

Conclusion

We enable ourselves with constraints. How ironic! Strategy. Agile. Kanban. DevOps. You name it! Let's decide what not to do to enable what we want.

P.S.

This article has changed significantly since its initial publication on Apr 24, 2023.

Stability is determined by the likelihood a bit of code has to change. The less likely it’s to change, the more stable it is. And vice versa. Consider modules (libraries, components, or packages). There are many reasons why some may change more than others. Risky modules change less than low-risk ones. Expensive modules change less than cheap ones. Or users may request fewer changes to some than others. We need to figure out how our modules should depend on each other to optimise stability.

The Stable Dependencies Principle says modules may not depend on less stable ones. Consider two modules, A and B. Suppose A is likely to change 𝓧 times. And B is likely to change 𝓧/2 times. A may depend on B, as it's more stable (less likely to change). Now. Let's explore what happens if B is less stable. Say 2𝓧 as likely to change. If A depends on B, it could be twice as likely to change than it was alone. Because every time B changes, A may also have to. A violation of the principle. How can we adhere to it?

We should remove that coupling if A depends on a less stable B. As our mantra reminds us, it shouldn't know about it. We could do it by refactoring the code so A doesn't have to call B. Problem solved. But what if A must call B? We can’t then refactor that flow of control away. But we can invert the source-code dependency between these modules such that it points against the flow of control. This technique is called dependency inversion. This means A can call B at runtime without knowing about it in the source code. Brilliant! Let's use it to solve our problem.

Suppose module A has a class, Rules, that calls a class, Data, in module B.

We can create an interface, IData, in A to represent Data. Let Rules call IData. And let Data implement IData. We'll then configure an Inversion of Control (IoC) framework – such as .NET and Nest – to inject Data, at runtime, where IData is used.

Voilà! A doesn't know about B anymore.

Let’s bring it together. The Stable Dependencies Principle reduces the propagation of change. Dependency inversion can help us adhere to it. The lesser the propagation of changes the faster we’ll be able to make them. This increase in productivity lowers the cost of change. And enables us to use the time that would otherwise be used on changing superfluously affected code to develop new features. This is the way.

The theory says stability increases with dependants. Let’s explore this by juxtaposing parents and teenagers. A typical teenager doesn’t have dependants. They can afford to change their behaviour. They can change their sleeping patterns. They change their discipline, perhaps to play more computer games and study less. Because their changes, for the most part, only affect them. Parents are different.

Parents have dependants, their children. If they’re conscientious, this makes them stable. They can’t change their sleeping patterns, because children may miss out on important activities. They have to stay disciplined, be it to keep their job as a breadwinner or to help their children at home. Their behaviour remains consistent because changes to it may have a bad effect on their dependants. You may now think, 'That's commendable. But how is this relevant to unit tests?’

Think of unit tests as the expectations of what your code’s supposed to do personified as dependants. Writing them gives your code dependants. In theory, a unit of code's stability should go up when you make tests depend on it. Dependants can also provide feedback to their dependency about how well they're regulating their behaviour. A child can inform their parent if things are wrong. Unit tests also do this. Not to their units but to software engineers. They tell you when the changes to their dependency, the unit, is wrong.

That's it! A strange perspective of unit tests. They're dependants you give to units of code to increase stability.

Responsibility is about how you separate your concerns. This concept speaks to cohesion. The Single Responsibility Principle is used to do so. In a nutshell, it says you should separate your code such that each bit serves the needs of a single actor. An actor (from UML) is the role played by an entity (human or computer) at a particular moment.

When a barista makes coffee, they can be seen as a 'coffee maker' actor. When they clean the coffee machine, they can be seen as a ‘coffee-machine cleaner’. If you were to develop the software of the coffee machine, you’d have a module for each of these actors. Not one for a barista. Nor none at all. After establishing modules, figure out how to make each one know as little as possible.

Knowledge is about source-code dependencies. This concept speaks to coupling. A bit of code knows about another if it depends on it. This can be risky because the more code knows, the more fragile it becomes. If module A depends on module B, it can be affected by changes to B. Such changes could break A. If A also depends on C and D, even more things can affect it! A should, therefore, know about as little as possible. You may also discover the less code knows, the easier it's to understand.

The Stable Dependencies Principle helps me to determine if a module may know about another. It says modules may not depend on less stable ones. It can also guide you to clean source-code architecture, with layers and a prominent boundary that separates business rules from input/output (I/O) code. There's more to be said about stability. For now, note it's something you’ll need in your repertoire if you’d like to master making code know less.

There you have it! Knowledge and responsibility. A mantra that can help you to write cleaner code with high cohesion and low coupling.