FWIW, I think what Don says is exactly right. I'm always interested to read about the "absolute horror stories."
😊
Jon, what you mention is a serious problem in software development that affects the ACS as well. There are "broken windows" or pieces of code that have problems, are hacks, or have questionable designs that persist for a long period of time. The presence of these windows is demoralizing and causes other parts of the system to slip. The Pragmatic Programmer has a great discussion of this, and other software engineering problems.
We try to identify such problems early and find ways to resolve them, but it is fundamentally difficult, espescially with short schedules. Creating a package that offers parallel functionality later is an acceptable way to address this, particularly if you were able to work out an interface in advance. Using the SDM to record the presence of broken windows with as much context as possible when you encounter has worked out great for us; it really is a fantastic tool. Keeping a thread running about the problems that you find is a great way to start a conversation and get ideas, and many of us at aD find it very interesting to follow along with what is posted here. Once you've got the problems out on the table, you can prioritize and address them in future versions.
Tangent: The conversations here are exactly what I hoped we'd see when ACS 4.0 got released, but, with few exceptions, never really happened. One of the claimed advantages of open source is that people will read and hack the code and let you know about these things. I think aD has always been open to such conversations and contributions in the form of patches, but what has been lacking was a concrete goal to organize non aD-developers around to really hack the code. Supporting multiple databases is a goal that has the quality of providing that motivation and excitement that was missing for so long.
