2

Can we kill the word ‘project’ please?

 1 year ago
source link: https://georgestocker.com/2023/01/22/can-we-kill-the-word-project-please/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Can we kill the word ‘project’ please?

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.

Enjoyed what you've read?

Sign up below to get these writings as they're published. One thought about building better software, daily.

I promise that you'll get more value out of these emails than the time you spend reading them. Unsubscribe at any time.

9ed3482ccbb461fbf8796b251caf8f4d?s=49&d=identicon&r=gAuthor geostockPosted on January 22, 2023January 22, 2023Categories Uncategorized


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK