Possible feature creep (and potential solutions)

[in1tiate]

Having had a look at the current state of the issue tracker and having had a hand in the recent development of this application, I'm extremely concerned that we are neck deep in feature creep at this point. Every feature currently implemented has exceptions for exceptions built on top of a solid base, and I'm worried adding yet more exceptions is not the way to go to maintain a maintainable codebase. It may be prudent to do some slimming down, even. The current agenda of seemingly accomodating every edge case will result in an unmaintainable mess in the not so distant future, I believe, if left unchecked.

Here's what I believe needs to happen to keep this project maintainable:

1. A feature freeze should be put into effect. No new features, not until the base is rock-solid.
2. Extending existing functionality should be put on indefinite hold - otherwise the feature freeze will be useless
3. Recently developed features should be given a 'second pass' - examined from a design perspective, and potentially retooled based on those examinations.

I think if these measures are effectively utilized we can preserve the maintainability of this project for the next AO2 developers. Thank you for your consideration.

[oldmud0]

I appreciate the sentiment and the petition. A proper response would be a bit long, but the answer is something to the tune of, "Yeah, we know."

One of the largest mistakes of AO's design, I think, is not giving the server enough authority on managing emotes and layers. The server should schedule how sprites should move across the screen and what should be loaded and from where, and the client should simply follow along. The client should not need to interpret emotes on its own. This has the added benefit of only having to upgrade the server to support a new type of emote or asset, rather than both the client and the server, and this would certainly benefit a community as large as this one that is beginning to encounter protocol compatibility issues.

As you know, I attempted to perform a refactor about two years ago. Although I was personally satisfied with the results, the issue was threefold:

• There did not seem to be a great deal of interest in others developing on it due to high standards of style and design. My goal was to have code that is self-documenting: code that is simple enough to understand that adding comments would be redundant.
• I didn't have a whole lot of contiguous blocks of time to work on it. But the longer I took to work on it, the farther it diverged from the trunk, and it was impossible to backport because of the way in which everything had been reorganized. People were not interested in testing a branch that regressed in features. They want the same or more features, not less.
• A refactor couldn't address basic architectural issues in the game, especially the network protocol - the best it could do is hide them behind a layer of abstraction.

What it comes down to is this - how do we get ourselves to redo 4 years of work in a few weekends? I've asked myself this question many times. It seems more reasonable to continue adding features, refactoring, testing, and migrating incrementally rather than making big explosive changes all at once. Unless someone comes up with a lot of free time...