Why learn modern system design if the old ways still work?

It is a fair question, and one I get from developers who have been shipping software longer than the people teaching architecture have been alive. The premise is right. The old ways do still work.

I have a couple of VB6 line-of-business apps in the wild that have outlived two database vendors and an entire operating system rewrite. Procedural, form driven, inline SQL. They run. Users depend on them. They have done their job well for a long time.

So if the old ways still ship, why pay any attention to modern system design at all?

Because some of it is genuinely good company in a toolkit you already have. A few of the techniques are nice to keep in your back pocket for the days when a particular project would benefit from them. None of it asks you to give up anything you already use.

When the old way is exactly right

Procedural and form driven styles are good at one thing in particular: momentum. You can get from idea to working behavior fast. The friction is essentially zero. Decisions happen in the order the typing happens, and that is genuinely productive when the scope is bounded.

If you are building a tool you will use yourself, or a small utility for a stable customer base, or an internal app that will be replaced by the cloud version next year anyway, the direct style is probably the right call. The architecture vocabulary is overhead you do not need to pay for.

I have shipped a lot of code that way. I have no regrets about any of it. The economics worked. The customers got what they needed. Some of those apps are still in production twenty years later.

What modern design adds, when you want it

The modern techniques are useful when a project starts asking for things that are harder to get from a direct style. Easier change when requirements move. A smaller search space when chasing a bug. Code another developer can pick up without reading every line first. The ability to move the database to a different one, swap a part of the UI for newer controls, or wire in a service that did not exist when you wrote the app, without rewriting the parts that have nothing to do with that change.

Those properties cost a bit of structure up front. For a small enough piece of software, the cost is more than the benefit. For a system that is going to live for ten years, get touched by five developers, and integrate with three outside services that did not exist when it was written, the cost starts looking attractive.

One of the nice things about these techniques is that you can pick up as much or as little of them as a project rewards. There is no minimum buy-in. A two-form WinForms app might benefit from one extracted class and a small wrapper for database calls, and that is the whole modernization for that app. A larger system can have clearer separation between the form, the rules, and the database. The size of the change matches what the project actually asks for.

The interface is fine

Here is something that comes up enough I want to mention it, in case you have not been keeping a close eye on what is in current Visual Studio. WinForms in VB.NET 10 on Visual Studio 2026 is a perfectly modern stack. The form is fine, the events do what they have always done, and Visual Studio is right where you left it. WinForms still ships in current Visual Studio releases, the runtime is current, and the event-driven UI model is a fine place to write a modern application.

The thing the modern techniques touch is what you put inside the event handlers. Not the form. Not the events. The contents of the handler.

Imagine the click event for a Save button. The familiar shape is, the handler reads the text boxes, validates the values, builds a SQL string, opens a connection, runs the query, checks the result, updates the UI, and writes a log entry. All in one method, sometimes in one long stretch of code.

A more layered shape, in the same form, in the same language, on the same IDE, looks like this. The handler reads the text boxes, packs the values into a Data Transfer Object (DTO), which is just a small class that holds the values and nothing else, hands that DTO to a class that knows how to validate and process it, takes a typed result back, and uses that result to update the UI. Maybe twenty lines, most of them about the form, none of them about the database.

The validation, the SQL, the business rule, the logging, those live in classes outside the form. They are testable on their own without launching the application. They can be reused on a different form, in a different project, or anywhere else you need them, without copying the code.

You did not stop using events. You did not stop using forms. The framework, the UI, and the IDE all stayed exactly where you left them. You added a couple of classes behind the form, and the form got a little simpler. That is the move.

Translation, not replacement

The experience earned shipping Line of Business (LOB) applications in VB3, VB4, VB5, and VB6 is real engineering experience. Knowing what your users actually need, making good trade-offs when a deadline is real, and shipping something that works this quarter instead of an ideal version next year. Those skills do not depreciate. They are the foundation that everything else sits on top of.

The modern habits sit on top of that foundation. They add a vocabulary for where decisions go, what depends on what, and which parts of the code you can change without dragging the rest of the app along with you. You can apply that thinking in modern VB.NET, in C#, in any language that lets you organize code into more than one big procedure.

The shape is the hard part. The language is the easy part. Anyone who came up writing VB has already figured out most of the shape part by instinct, just by shipping working software for years. The vocabulary catches up to the instinct, not the other way around.

Where to start, if you want to

If you have a working app and you would like to try one of these techniques, the cheapest entry point I have found is to pick one feature. The one that has bled the most maintenance time over the last year. Reshape just that one.

Pull the business logic out of the form. Put it in a class with a name like InvoiceDiscountPolicy instead of a BAS file called Module1. Put the database access behind a function that takes parameters and returns a typed result, instead of returning a recordset that the form code then pokes at directly.

Run the app. It still works. The form is now thinner. The rule is now testable. The next time someone changes the rule, you do it in one place.

If it felt like overhead, you picked the wrong feature, choose a more painful one. If it felt like relief, that is the signal. Repeat on the next painful feature when you have time.

There is no expectation that you rewrite the whole system. Most of the system probably does not need it. The five percent of the system that is responsible for fifty percent of your support tickets is the part that benefits most. Start there.

Closing

The old ways work. They have always worked, and they will keep working for the kinds of software they were good for in the first place. Anything you have shipped under that style is real software, and it deserves the respect it has earned.

The modern techniques are a set of optional tools for a particular problem, the problem of code that has to keep changing, by people who are not the original author, for a long time. If your code does not have that problem, you do not need the tools.

If it does, or if you can see it coming, the form stays a form. The event handler stays an event handler. The new pieces show up behind them, quietly, where they do their work without getting in the way of yours. They are there for the day a project asks for them, and not a day before.