Category: Uncategorized

Sprint, Such a cruel name for the practice of delivering software features at a fixed interval, especially because of the carelessness in which the name was created:
​

And so my team embarked on what we called “Sprints”. We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and then stop to see where we were. — Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time

Some teams make their time-box two weeks, some make it a month, some make it 6 weeks, nearly all call it a sprint, and perhaps disastrously, Scrum dictates that you should be able to ‘sprint’ continuously:

​”Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.” – ​The 2020 Scrum Guide​, “Scrum Team”

“Sprints are the heartbeat of Scrum, where ideas are turned into value.

They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.” — The 2020 Scrum Guide, “Scrum Events”

So “Sprint” at a sustainable pace, indefinitely? That makes a ton of sense.

But, the unfortunate name that stuck is not the only reason Sprints are inherently a problem, even if it’s one of the lowest hanging fruit. The Sprint introduces regularity into your development cycle, no doubt; but it also artificially constrains your team’s thinking. How much time is spent by your team trying to fill the ‘capacity’ for a sprint, or deal with the fact that a piece of work might have to go into the next sprint, or whether the schedule should be adjusted because the sprint ends up falling into a holiday, or event trying to match up your sprints with a fixed deadline like a trade conference or a quarterly budgetary review by the C-Suite?

Besides the management to the sprint issues, there’s the constant pressure to deliver a chunk of work every two weeks, constantly, and without fail.

Do you know what the prime ingredient of a death-march is? It’s the relentless nature of the work. And nothing sounds more relentless than the definition of a sprint, especially combined with the idiotic “agile capacity planning” that happens.

The idea of software development as having the regularity of manufacturing is appealing, and far too appealing to folks who have nothing else to latch on to. But the myopic nature of the sprint causes teams to artificially stuff their work into that timebox, without giving them the benefits of a forcing function like a timebox.

Does the overhead of a sprint really help your development team deliver value? Or does it give them extra work to do without any extra benefit? Put another way, is the juice really worth the squeeze in the year of our Lord 2024 when continuous delivery has never been easier?

Moving on, another issue is size. Once work is ‘too big’ to fit into a sprint, someone has the bright idea, “Well let’s try to see what we can deliver in that two weeks that has value but may not be the whole enchilada feature?” And so the team spends valuable time trying to figure out how to deliver something in that two weeks, while the business folks are watching with equal parts impatience and amusement at the strange rituals of these software developers.

If you’ve asked for a car and someone hands you a tricycle because that’s what they could deliver in two weeks, your first thought probably isn’t to thank them for the tricycle.

Much like the majority of Scrum, the sprint and its events manifest as a dog-and-pony show meant to soothe the egos of the folks asking for them, and not at all empirically useful to the folks doing the work or the folks who will benefit from the work being done.

If your team is product-focused and it feels like the wild-wild-west, Scrum can give you structure and regularity. But once your team has that structure and regularity, you’re far better off jettisoning scrum for something custom suited to your company and its culture. Some folks say “scrum, but” as if it’s a insult, when in reality scrum, but is the only sane way to practice scrum.

I always wondered what authors meant when they said they sat down to write one thing and ended up writing something else completely different; or that they sat down with one motivation for their protagonist, and halfway through had to change the entire premise because they realized their protagonist’s motivation was different than they thought it was.
​
‘Wondered’ here is in past tense because as of yesterday, I no longer wonder. It happened to me. I sat down to write an email titled ‘what I mean when I use the term agile’, and got halfway through it and realized I was writing a completely different email entirely. So here’s the email you were originally supposed to get when I wrote the “agile is not a process” email. (Authors note: For the folks viewing this on my blog, this paragraph may seem out of place; Every so often I post things from my email list here, and this just happened to make it. To be sure you get these sorts of things when they’re published and not potentially weeks after, if at all, subscribe to my email list in the box below).

I want to start out by saying that despite my experience and belief showing that we’re entering a post-agile world, that unlike some folks, I do have a concrete set of things I mean when I use the term ‘agile’. This may not agree with your definition (if that’s the case hit the reply button and let me know what your definition is), but it’s a definition, and if we’re going to have any sort of coherent conversation on the merits of agile for software development, we’ve got to start somewhere. This is that somewhere.

Agile is a contrast to waterfall-based development; in that waterfall treated software development like construction or other hard engineering applications with the following discrete and sequential phases: Requirements, Planning, Design, Development, Testing, Maintenance. Once you went to a new phase, you didn’t go back to the previous phase. Waterfall projects are typically defined with lots of ‘gates’ and documentation, and do not handle any change in requirements well at all. They’re expensive when they work, and even more expensive when they go off the rails, and since Software Development is still in its infancy as a discipline, they go off the rails quite a bit.
​
Agile instead defines software development as an iterative process, where those phases may happen dozens of times during a project’s planning and launch; and even more so, jettisons the idea of extensive documentation with embedding the customer into the team, and working with the business people in a collaborative fashion, instead of through these well-specified hierarchical channels. If you can produce working software quickly, you have less need of extensive documentation — since the documentation was there to describe how it worked.

Another principle of agility is the idea that since requirements change quite unpredictably, the software team should expect that and operate with flexibility towards that outcome. To that end requirements (according to some agile processes) can change every planning cycle.
​
So to distill the meaning of agile down to something that can fit on a postcard:
​
Agile is a philosophy of software development where software is released frequently and iteratively, based on the requirements needed in that moment, with the business and development team collaborating and involving input from the customer during the development process.

Not everyone would benefit from the various processes that implement the agile philosophy.
​
Besides the structural deficiency in the agile principles themselves; the various processes that tout their alignment to agile principles ignore one of the most foundational elements of any effective process: they pay no attention to introducing scientific process rigor into the experiments that are “Iterations”.

Leaving that gaping process hole aside, there’s also that even if your favorite flavor of ‘agile’ was perfect for the scientific rigor needed for your context, not all processes are suited to all companies in all contexts.

We fully expect this sort of nuance in other industries, even if we completely ignore it in software development. What works for McDonald’s wouldn’t and shouldn’t work for your local mom-and-pop burger joint, because their aims are different.
​
So too with Software Development. The aims, structure, and goals of an organization dictate what processes should be used to achieve those aims. Slapping some agile on a team because it’s the most popular methodology is the height of folly the bounds of which are only surpassed by the insistence that it’s the best we can do.

Those issues aside, even assuming for our purposes that agile really is the best we can do, here are three situations where it’s ill-suited for success:

1. A known scope, known timeline project wouldn’t benefit from an ‘agile’ approach because the customer both knows what they want, and they have expectations on how to get there. A team ‘inspecting and adapting’ is a likely to be irritating to them as it is useless to the overall goal.
   ​
   A corporate IT project falls in this category quite a bit, especially for a system rewrite. Now rewrites are terrible for other reasons, but if you’re trying to fit an ‘agile’ process into that situation, at best it will feel awkward, and at worst becomes a sort of Kabuki theater.
   ​
   2. A variable scope, known timeline project fits better, to be sure, but it suffers from the “adapt” part of agile. If you have a known timeline all work has to be finished by (whatever that work is), then what matters is getting the most done in that amount of time. If agile is the art of “maximizing the amount of work not done”, then a situation where you want as much done as possible is antithetical to the agile way of thinking.

​
3. A true fixed-budget startup cannot afford the ‘trial and error’ nature of agile. You only get so many iterations before you fail, and you need something deeper than ‘inspect and adapt’ to survive.

If you find yourself in any of these situations, adapting an ‘agile’ process, especially one like Scrum, is going to feel kafka-esque at times, and any success you may achieve may be in spite of your choice to adopt an agile philosophy, and not because of it.
​

I don’t dislike agile. I think Agile is a welcome change if your team’s current method of developing software is “we release every 6 weeks and conduct a UAT, and come up with a detailed plan before we start working, complete with timeline and commitments from the team”, and in those situations I’d shove the nearest copy of The Phoenix project or The Unicorn Project into your hands and say “Let’s give it a go, where you’re going is better than where you’ve been, but it’s going to be a bumpy ride so buckle up.”

And it would be better than the thing you’re doing, and maybe you even decide to keep it.
​
That’s all fine. No issues there, and in fact there are lots of bits of agile I happen to think are good practices for a team to consider.

But, and this is the important part: Not all teams should ‘do’ agile and all teams that are doing agile but not having the success they are looking for are probably running into a foundational problem with the philosophy of agile itself.

But, to keep this positive, I want to talk for a minute about some of the practices I like that the various agile methodologies tout.
​
Talking to the folks using your software daily? Seems basic now, but can you imagine 20 years ago? It was revolutionary.
​
Getting to the point where you can release whenever you want? Besides the immediate benefits, it also means that all of those silly little things you were doing manually are automated, and from a software developer’s perspective automation is akin to godliness.
​
Ditching the plan at the first sight of trouble? I’m a Big fan, especially since software as a discipline is still in its infancy. We aren’t building bridges where we’re dealing with all known quantities and calculations and domains (not to mention for our purposes the rather iron-clad laws of physics). Software development is still at least one-part magic, and until that’s not the case the ability to ditch the plan at a moment’s notice is a good thing.

What about you? What do you like about agile?​

This post originally appeared on my daily email list. I’m reproducing it here in vain hopes you’ll join said email list. The box to join should be below. Someday I’ll have this process automated so my daily emails pop up here too, but the cobbler’s kids and all that.

I bandy about the term ‘agile’ on my email list a lot. While it may seem like I use it to mean “practices we adopted but didn’t solve our problems”, it also has both a specific set of things it means, and at the same time is a too broad categorical list of things executives want it to mean. To say it’s a process or a methodology is being too generous, as it’s a process in only the most hand wavy sense of the word.

It’s a set of values and principles, and we’ve somehow created from that a central thesis that it is useful as a definition of a development methodology, and is somehow prescriptive in what it means.

“We’re agile” has come to mean “We’re moving fast and breaking things to get new, not-thought-out untested features delivered this quarter to make our executives look good at the industry conference”. Or, “No we don’t have a plan, we react to whatever is happening now”, or “Our development team runs at 100% utilization because idle developers cost us money, and developers are expensive.”
​
But, those archetypes of modern agile aside, even if we were to take the agile values and principles at face value, you’d be unable to articulate an actual process you’re supposed to follow if you adhere to these principles and values.

If you hired a consultant, and they said to you, “Value People and interactions over Processes and tools”, I hope you’d slap them silly (after asking them what they possibly mean by that in a practical sense). Does that mean runbooks are out? Style Guides? Checklists? Of course not, they’d exclaim! Then what does it mean? And at this point they’d probably just repeat what they said, and both of you could share an awkward silence. What does it mean? Seriously, I’m asking. At best it means “don’t let following the book keep you from throwing the book out when it needs to be thrown out”, and that both vague and, to be fair, not a bad fortune cookie fortune. When would you throw out the book? Under what circumstances? When it’s inconvenient? When it actively detracts from what a particular user wants? When it gets in the way of the quarterly profit? When? The problem with this sort of ‘value’ is that it sounds good but doesn’t actually define its parameters, making it terrible as part of an actual process definition.

Likewise, taking at (not really) random an agile principle: “The best architectures, requirements, and designs emerge from self-organizing teams.”
​
I have to ask what sort of hate the inventors of agile have for the rest of us that they imposed their context and view of the world on us and we just said, “Yea, that sounds right”.

The best architectures, requirements, and designs demonstrably do not emerge from self-organizing teams, because those self-organizing teams have constraints they don’t control. It doesn’t matter if the four of us on a team get to pick what we work on, or what tech-stack we use, or whether we make it a relational database or a no-sql database. We’re not the Avengers. We don’t have superpowers that obviate the need for resources and budgets. (As an aside, in the MCU movies, shield doesn’t seem to do anything other than get in the Superheroes way; whereas for the non-superheroes among us, we’re always dependent on some sort of bureaucracy to support our work).

Normal teams don’t control their budget, the market, the board of directors, or the C-suite that is hunting for a quarterly profit. It is both defeating to claim there is such a thing as a self-organizing team (and have it be true) and downright dangerous to think that with any sort of seriousness. There will always be external constraints, and putting the idea that the team, by virtue of being ‘self-organizing’ can somehow navigate an entire corporate culture, and know what is right for the customer, product, and business, is foolhardy — at best.
​
It is also stupidly dangerous because it isolates the ‘development team’ from the business in which it operates with a blue flag that says “Just let us organize ourselves!”. The flag may as well have a snake and say “don’t tread on me” (It’s election season here in the USA).

Now, I understand the desire behind that principle: That if you let a team figure out what they need to do and how they’ll be more bought in and do a better job than if you had some VP or director standing over their shoulder indicating what they can and cannot do and how. And if you say, “well it doesn’t actually mean any of that, it only means that they get to choose how they get the job done”, I’d like to sell you a bridge. Agile pretended that somehow multi-million dollar budgets were in the control of the team, or head-count, or technology choices, or what sort of features get worked on. As a principle it’s unrealistic, and even if it were completely realistic and attainable, would be about the worst way to run a software team as can be imagined. Human Hierarchies and interdependent groups exist because that’s the ‘best’ way we’ve figured out how to work for at least since the middle-ages. The builders are not also the dreamers, and the dreamers are not also the folks with the money, and you need all three to get anything done.
​
Agile is a set of values and principles; it’s not a well-defined (or even an ill-defined) process, and treating it as such will at best lead folks to misunderstand each other and lead to bad outcomes. It’s a set of values and principles you can use to create a process, but it’s not a process in of itself. As much as I dislike the results of Scrum, it’s at least a process.

This post originally appeared on my daily email list. I’m reproducing it here in vain hopes you’ll join said email list. The box to join should be below. Someday I’ll have this process automated so my daily emails pop up here too, but the cobbler’s kids and all that.

Does your software team:

• fight a lot of fires?
• release a lot of ‘hot fixes’
• constantly push back releases?
• release half-baked features only to never return to them again?

​

Do your senior leaders blame any of the above on “the market” or “market forces” or “business dynamics” or even “the team”?
​
The answer in reality is a bit closer to home (than even blaming the development team!)
​
The problem is you. Specifically, That thing that surrounds your entire company that would be called a ‘system’ in systems thinking. It surrounds your company, every action you take, how your customers respond to that action, other ‘market forces’, and just about anything you can (and can’t!) see, smell, touch, and experience as an executive.
​
It’s like the Force, except it’s real.
​
The book definition is that a system is ” system is any group of interacting, interrelated, or interdependent parts that form a complex and unified whole that has a specific purpose. ” (Kim, Daniel H. (1999) Introduction to Systems Thinking. Pegasus Communications, (Pg. 21))
​
Yea, you have a system, even if you don’t know it. — and I don’t mean agile — that’s not a system for developing software. It can be a part of a piece of a system, but it’s not the whole system itself. In this case, a system is both the parts, their dependencies, and inputs and outputs that result in software being delivered and loved (or hated) by the folks that use it.
​
Things like:
​

• Culture
  – Management Culture
  – HR Culture
  – Company Culture
  – Developer team culture
• Past Events and how your senior leadership handled them
• Policy
  – PTO policy
  – reimbursement policy
  – training policy
  – BYOC (Bring your own Computer) policy
  – Requiring specific brand/model computers purchased by IT
  – Financial policies meant to save the company money
  – Travel policy
  – WFH Policy
  – RTO Policy
• Training
  – Management Training
  – Developer Training
  – Financial Training
• Layers of Management
• What gets rewarded
• What gets punished
• How the team receives feedback
• How the team receives information
• Your budgeting process

​
​And right at the very bottom, after all those things that actually matter, are the systems we think of when we talk about developing software:

• The methodology the team uses to develop software

​
But, that’s just one tiny bit of the picture, and on its own its almost meaningless to how your software actually gets developed and used and whether your business is successful or not. Don’t believe me? Here’s one simple way to find out: If you’re an agile team, look around at your agile process and ask yourself, is the business’s success with software totally in our hands? Or are we dependent on someone external to the development team for success?
​
A final thought before we go: If the agile methodology de jour isn’tthe whole of the system your business uses to develop software, then why do you give it the importance of being responsible for the whole of the system? It’s a tool, and a tool for a tiny piece of your business’s overall success or failure.

This post originally appeared on my mailing list. From time to time I put posts from my mailing list onto here, but not always. If you want to read what I’m writing, your best bet is to sign up for my email list, below.

Moq is a mocking library for .NET Unit Testing (cue the TDD folks reminding us mocks are unnecessary), and it is by far the most widely used mocking library in .NET (475 million downloads vs 87 million for the next largest, NSubstitute). Yesterday, its author released version 4.20.1; which added nagware and a backdoor to Moq, in a bid to drive up paid usages of Moq through ‘Sponsorships’.

This had the predictable result of enraging folks that use Moq, and the change was subsequently removed in version 4.20.2 (released a few hours ago as of this writing), ostensibly because it broke MacOS restore. The author of Moq wants discussion on the topic of sponsership under Github issue #1374.

I’ll get the tactical analysis out of the way first by way of these three points:

1. This was a backdoor (unintentionally) to supply-chain attacks. The project linked to an obfuscated DLL that provided two functions: a) retrieving its settings from a third-party server, and b) spawning a git process, and sending hashed git email addresses to that same server.
2. This is also nagware. A message popped up in the build window if the person wasn’t a supporter (by checking hashed email addresses found locally vs. what’s on the server), to tell them to sponsor the project.
3. This action by the maintainer is a cry for help. They have 475 Million downloads, and their work on Moq can’t support them financially. This is a cruel and unjust world where giving away software that supports Fortune 50 companies would result in poverty if they didn’t keep their full time job. They get to choose between maintaining Moq, or seeing their family.

For the security minded among us, there are any number of ways for this to be exploited, from DNS based attacks to any code vulnerabilities to simply waiting for that domain to expire and taking it over, to any number of attacks that an enterprising malware author would find. This is a textbook opening for a supply-chain attack.

There’s also a betrayal of the social contract involved with OSS software: You don’t rely on closed-source software as a necessary part of ensuring your software does what it says it does, and you don’t surprise the folks that depend on your work.

This is also one of those character-building opportunities for the author and an object lesson to everyone else in the .NET OSS community on what not to do. But more so an object lesson for us that .NET open source is not sustainable. Popular projects become force multipliers for Fortune 50 companies that would otherwise have to spend hundreds of thousands of dollars in salaries recreating the functionality, or spending tens of thousands of dollars on licenses to buy software that does what OSS provides for free.

I won’t spend too much more time on the tactical part because there’s a much more interesting strategic problem sitting here waiting to be dined on: The .NET Foundation and .NET Open Source Software.

I wrote a while back about the .NET Foundation’s fundamental problem, and if the Discussions tab is any indication, the .NET Foundation as a community is dead. 4 discussions in 2022, and 4 in 2023 is not a healthy community. Also, all but one committee stopped meeting (wg-projects, wg-maintainers, wg-marketing, wg-membership, wg-corporate-relations, wg-education have all stopped meeting/posting their minutes/updating agendas) — the wg-outreach team is the only committee to have met recently.

Update: Glenn Watson, .NET Foundation Board Member, had the following response to the above:

Committees are meeting regularly. The thing is I went hunting for meeting details. if I wasn’t getting invites by the foundation I wouldn’t know the times and where and how to join. Something I need to fix. Also we hire a company at the moment to take notes and minutes and I need to discover where that is going. I will get back to you on this one too.

With that update down, back to the original post:

Ok, great, George, so an OSS project is feeling the pressure of producing software for free, and the .NET Foundation has about as much activity as your blog, how does this all connect? Allow me to quote from the .NET Foundation’s own front page:

The .NET Foundation is an independent, non-profit organization established to support an innovative, commercially friendly, open-source ecosystem around the .NET platform.

It appears the problem of supporting an innovative, commercially friendly, open-source ecosystem around the .NET platform is right up their alley. Literally. Now, I have my concerns with the way they wrote commercially friendly, and there’s been no clarification since that blog post of their intentions, so at this point that part is an open question: Who does the .NET Foundation want software to be made commercially friendly for? Is it for maintainers? Is it for Microsoft? Is it for other large companies? Who is the beneficiary of the .NET Foundation’s work? Who does it serve?

The .NET Foundation should be all over the open-source commercial viability problem. We should see leadership from them not only on this Moq issue, but on the state of open-source in .NET. Maintainers aren’t business folks, and they don’t know how to turn something that has 475 million downloads into a viable business, and yet every enterprise that uses .NET more than likely uses Moq. Heck, even the streaming music industry pays better than .NET Open source. If the foundation is foundering, and looking for problems to solve, the viability of open-source is right up there, waiting to be tackled.

The .NET Foundation should be that interest group for open source, enacting policies and frameworks to help OSS maintainers get paid, to build the foundation for what it means to be sustainable for open source.There’s no question, Open source software has to change, and money has to come into the equation. In one possible future, projects join the .NET Foundation, and their maintainers are paid by the .NET Foundation, while corporate members pay thousands to 10s of thousands in dues every year in return for support and commercial licenses to use .NET Foundation projects. Dual-licenses, and an interest group sitting in between that handles the payment backbone of OSS is a possible path forward, but it’s going to take someone like Microsoft leading the way. Do they have that leadership potential in them? Only time will tell. For our part, we should continue to remind the .NET Foundation as to why they exist, and use our soap-boxes to get them to take action on this pressing issue. We won’t have open-source viability until we fix the sustainability issue.

You’ve probably heard of the Pareto Principle, stating roughly that 80% of the outcomes come from 20% of the causes, or put another way: 80% of the value comes from 20% of the effort.

You probably believe it. Heck, I know I do.

Do you think that 80% of the value of your software “project” comes from 20% of the effort?

If not, why not?

I ranted a little bit yesterday on killing the word ‘project’, and and I was asked, “well, what should we use instead?”
​

Great question, I would love to tell you.

Projects give off an aura of “beginning, middle, and end”. At some point, this thing will be done. And that’s not true in software. There may be a point where we don’t use it any more (we ‘kill’ it), or it may fail at its purpose, but as long as we’re using it, it’s not done. It’s going to need security updates, framework updates, and at the very least bug fixes.

And so calling software a “project” is a bit like having a kid and calling it an accessory to your lifestyle.

Instead, software that isn’t meant to be a ‘product’ (that is, have the understanding going into it that there will be long term support and a budget) should be called an experiment. Because it is.

We’re not naive enough to believe this IT Modernization project (see, I just did it!) will succeed because we spent millions of dollars and tens of thousands of people hours on it. It’s an experiment. It’s an experiment because Sue in accounting who has been here for the last 25 years basically runs your entire payroll infrastructure even though her title is “Sue in accounting”. Your modernization project will fail if Sue in Accounting isn’t happy, regardless of how you dress up the project. So it’s not a project; it does not have a beginning, middle, or end. It has a beginning, Oh-god-I-hope-we-win-Sue-over, and then support. And if you don’t win Sue in accounting over, you’re going to have a bad day.

So call it an experiment, and don’t let anyone lie to you about the real nature of software: it only succeeds if we successfully sell it to the people who are going to use it.

This post originally appeared in my daily email list on January 13, 2023. I publish emails daily, and put them here when I remember to. If you want to stay up to date, join my mailing list. Details below.

One of the things I do in the realm of strategic architecture is help companies migrate their legacy systems. This can be referred to as ‘modernization’, and generally it means rewriting the application in a new stack that may get developers psyched to go to work again.

The current fad is to move .NET Framework to .NET Core/6+, and to migrate away from MVC/Webforms to a JavaScript SPA based front end. Now, there are several questionable decisions here; but I’m not going to focus on those (like that you should only use a SPA if your application needs to be a SPA. Most don’t. Especially, especially Line of Business applications). The questionable decision I want to focus on is the idea that this is a project.

As I said, these are typically termed as ‘projects’, which is detrimental to everyone involved; from the executive who got approval for this to the developers who will spend the next few years of their life on this ultimately doomed project.

There’s lots to say on this topic; but I want to focus on two parts:
​
1. software is only a project only if it never needs upkeep. That’s never true. Projects have a beginning, middle, and end. Software never ends. As long as that software exists, you must either pay to keep it running or you must pay to kill it. If you simply leave it alone and do nothing to invest in it strategically (or hell, tactically) the cost will be more expensive than you can ever imagine. For instance: you build a home-grown search application, and that sees use. Well, as that system sees more use (and it’s in ‘maintenance mode’ because we did it, we shipped the project!) the design of that system is stressed; or an unforseen bug comes to the surface. It doesn’t matter. Eventually that system’s usage will exceed its design, and years of neglect or leaving it in maintenance mode will come back to bite you.
​
As long as a system has users it is a living organism that needs to be fed, watered, and cared for, as often as you would your own pets.
​
2. You can both reduce the impact of a ‘modernization’ effort and keep the longevity of your working system going while you have time to rebuild it by instituting an event-driven architecture. In short, introduce events and queues into your present working system; let the system work as normal with those new primitives added in, and have your new system also act on those primitives; whether it’s storing the data from it or introducing new processing or replacing existing processing the old system does. The goal of a modernization shouldn’t be to turn the old system off, it should be that neglecting the old system no longer results in problems for your users.

Until next time,

George

This post originally appeared on my mailing list, if you want to get my emails as they’re sent, you’ll want to sign up for my mailing list below.