Considerations about the tech stack and architecture

In case this was directed at me: yes, of course - I believe I do. These terms reflect a desire for this software project to still be extensible and maintainable years down the road, something that I’ve yet to see with any existing implementation. While I’m nowhere close to agreeing with everything Robert Martin says , he makes a good point in his book Clean Code [2008]: in a software project, 80% or more of all work is not spent in the initial implementation, but rather in maintenance.
(Well, to be honest, this wasn’t said by mr. Martin himself, but actually James Coplien, in the foreword; and whether 80% is a precise figure is detatable [1]. The point, however, still stands.)

Most existing (FOSS) implementations I’ve seen where developed in a “I’ll figure it out as I go” fashion. At least two turned out to be good enough and managed to be usable in production, namely, AskBot and Question2Answer. I can’t speak too much for the first. As for the second, the architecture is, nowadays, fairly maintainable it seems to me, provided you don’t wish to deviate from general functionality too much. And yet you can look at their commit history and figure out how long it took them to refactor DB queries, data structures and important mechanisms (such as authentication and caching) until something maintainable was achieved. Took long enough, I’ll tell you that.

Interestingly enough, in AskBot’s initial page you’ll find a link to this Q&A: Why design is not better ?. Here’s what Evgeny Fadeev, the primary project maintainer (user id 1, mind you) has to say:

My guess is that the existing implementation is so bad that improving the design by tweaking what there is is pointless.

What is needed is a complete rewrite of the front end, probably not using the django/jinja2 templates, b/c it feels outdated compared to the modern UI approaches.

So. When I say that we want “something that lasts”, I’m referring to an implementation that is flexible enough to allow for adding improvements 5+ years from now, without anyone feeling distressed and discouraged to the point of considering a complete rewrite instead.

When I say that we want to build something “better”, I allude to the fact that SE has a damn good product to offer, and whatever issues me and other people are having with their services, the software is not one of them. Ultimately, I believe I speak for the team by saying that offering a product that is polished enough and on par, feature-wise, with SE is an essential goal if we are serious about replacing their platform.

Their implementation is ASP.NET and IIRC there have been talks over the last couple of years about switching to the obvious evolution to this stack, which is Core. We picked this as we feel it’s a worthwhile choice.
Note that the team didn’t vote for the stack they’re most familiar with - the majority isn’t. They (actually, we) voted for the stack we’re willing to learn and work with the most, which also happens to be the a stack we think is a great choice. ASP.NET Core is nowhere near 10-years old, it was first released in 2016 and has been considered production-ready for about 2 years, give or take.

Now, hopefully you are familiar with the distinction from ASP.NET, which is based on the much older and mature .NET Framework. .NET Core is similar enough to .NET, and yet it is a substantial evolution from it.

C# today features vast improvements compared to the C# from 10 years ago. Tooling is great, and totally free for open source projects like our own. The language is expressive, safe and performs quite well, while not imposing one specific programming style on everyone. By ‘safe’ I mean you can trust the compiler and environment to prevent you from messing a lot of things up. If that’s not enough you also get great static analysis tools. The debugger is widely acclaimed and the IDE offers more-than-decent refactoring tools. The production stack is fully open and support for OSS datastores is respectable.
You’d be hard-pressed to consider using a Microsoft stack with Postgres and host it on Linux a few years ago. Today things are, thankfully, different.

This is all to add on top of what Art said.

2 Likes