Thomas, I'm sorry that you're frustrated with past ArgoUML refactorings, but you've set up a false conflict here.
On Thu, Jun 5, 2008 at 4:09 AM, Thomas N. <[EMAIL PROTECTED]> wrote: > the recent discussions about the import interface revealed a conflict between > two goals of open source software development, that split the developers in > two types: > - enhance the codebase to make it maintainable, extendable and > state-of-the-art > - add new domain specific functionality that users need There is no need for these two types of developers to be in conflict and as a matter of fact it's much more normal for every developer to adopt each of these roles at different times. Doing it "right" doesn't have to take more time, than just "hacking it together." This also isn't unique to open source software. The same things happen in commercial projects. The mere fact that you've identified a separate category of developers (which doesn't include you) to take care of correctness, good design, etc, is a real problem, because it implies that all this stuff is someone else's problem when, in fact, it's *everyone's* problem. If you absolve yourself from worrying about it, then someone else has to worry about it. I started contributing to ArgoUML because I wanted to see it support UML 1.4 so I could use it with AndroMDA and because the quality sucked so much it made it difficult to work with. I didn't join to play "architecture god" or be king of refactorings. Every hour that I spend cleaning up someone else's code, whether it's from the CS 201 uni students who hacked on ArgoUML 5 years ago or a current developer, is an hour that I can't spend adding a new feature that I want or cleaning up a piece of the UI that makes me grate my teeth every time I use it. If you're not familiar with the concept of "technical debt," take a minute to read http://c2.com/cgi/wiki?TechnicalDebt. ArgoUML has such a mountain of technical debt that it can barely pay the interest. The team can either keep borrowing until it collapses into bankruptcy or it can chip slowly away at the debt until it's manageable. > [I] had to postpone my feature ideas for YEARS for several reasons, sometimes > I even had to > abandon plans. First there was the breaking of sequence diagrams, then the > move from NSUML > to MDR, then multiple reworks of whatever event mechanism, now we will have > sequence > diagram 2 or 3 and UML2/EUML/AMOF/DI/... and so on. You didn't "have" to postpone stuff. You chose to. If you didn't like the turmoil of the NSUML->MDR migration (or the earlier homebrew->NSUML migration), you could have stuck with UML 1.3 (or 1.1). If you wanted UML 1.4, I'm not sure how you think you get that without changing anything. One of the thing proper design that minimizes inappropriate coupling does is to allow multiple independent aspects of the system to be changed without interfering with each other. That's one of the reasons good design is important to everyone. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
