Right Flow

The concept of Systems Development Life Cycle (SDLC) is something we are all familiar with. It is not uniquely applicable to software engineering. This linear progression of a project from a starting state to State-N, where State-N is considered special, e.g., "released", "fixed", "case closed", "sold", appears everywhere in life. So in my effort to reach the broadest audience, to provide the maximum value, I am going to discuss an aspect of SDLC that everyone reading this can relate to...and hopefully make use of. An aspect that is all too often over-complicated. But first...

What is SDLC?

SDLC is a big-bucket term, but we can summarize everything in the bucket as "the process of project stakeholders working together with the common goal of getting from a start state to State-N". That sounds pretty general purpose to me, sounds like it describes just about any project. Let's see about that...

Here in New England (we hope) we are finally emerging from what felt like a Very Long Winter. There were a few perfect storms that wreaked havoc, and many communities are still dealing with the damage left behind. In Stow, like in many towns, we lost power during some of those storms. After 24 hours without power you have entered the acceptance stage and somewhat adjusted to living without power, but you Never stop thinking about when it will return.

In past power outages I have thought about the people responsible for getting power flowing again, but for some reason this year in particular I spent a lot of time thinking about them. And when power returned, I literally took a moment to myself and thanked them for all their hard work that I was no doubt completely clueless about.

So, that was an example of a process (delivery of power), of stakeholders (power companies), and of working together with a common goal of getting from a starting state (no power) to State-N (power). This concept of SDLC is ubiquitous in life. We see it everywhere, not just in software engineering but in sports medicine, education, publishing, law enforcement, litigation...the list goes on and on.

Now, in some areas of life SDLC seems more complex than in others. For example, while the sale of a house has many complexities that (hopefully) culminate in Sold, real estate "projects" are generally one pass through. Or in other words, once Sold we are pretty much done. There generally isn't Sale 2.0 (thankfully). Compare that to an NFL season where you make 16 passes through the project of winning a game, and then more passes through if you progress through the playoffs.

In SDLC terms these passes through the project culminate in "targets". And here, finally, we are getting to the subject of this post. Whether you call them targets, outcomes, or goals, they are the reasons you are doing the work you are doing. For example, you are working with an athlete to rehab a frozen shoulder - your targets are breaking down scar tissue, followed by redeveloping range of motion, culminating with strength and stability conditioning. These targets necessarily are linear in progression and, in general, there is no "skipping" of targets. You need to reach targets L and M before arriving at target N.

The project managers among us have refined their craft over the years to maximize the speed of target progression, while minimizing risks of target failure. They have generalized this into methodologies of all sorts of shapes and sizes and names, but every single one of them is a Flow. And it is this Flow that software engineering, for one, has greatly over-complicated. I want to help you software engineers, managers, operations, to see the over-complexity and see how simple it can be.

Git Flow

Want to see how over-complicated Flow is? Take a look at this "simple" diagram. If we peel away the complexity, we see the simple things we have been talking about (targets, time, work). The tags, e.g., 0.1, 0.2, 1.0 are your targets and they progress linearly over time from top to bottom. The stuff in between the leftmost and rightmost lines...that's the work. If you're a Developer, or a DevOps Manager, and you are about to get defensive...this is just an article. Ain't no harm in seeing if a simple Flow accomplishes everything the complex Flow does.

In every project, software or otherwise, we set targets. Now, these targets are great and all but they are by no means enough of a step-wise progression. If all we did was leap from target to target, then we would live in a world according to Escher. Think about your projects. You don't start your day going after your Big Target. You have this hour's work, this day's work, and this week's work, geared towards a target. And nothing goes perfectly, right? So you have the equivalent of bugs and changes randomly injected into your progression towards your target.

And it's not just you right? You're part of a team, maybe multiple teams. All of you working to reach the target. And as the Target Team grows, so does the number of bugs and changes. Well, let's see what a Simple Flow would look like that takes care of all that.

Simple Flow

What I propose is quite simple: that we make our Targets the focus of the Flow rather than the work. Get rid of all those work branches, get rid of all those bug fix branches, get rid of all those change branches. What's left is a linear progression containing only the Targets. So using left-to-right as Time, we have Start > TargetOne > TargetTwo > TargetThree... And at least in terms of software projects, you generally only need 3 (i.e., Current, Beta, Alpha).

I'm going to pause this for now...it's as good a spot as any, and I've got stuff on the stove so to speak. I'll pick up from here tomorrow with Right Flow, Conclusion.