Thanks for your comments Maarc. I didn't really start programming for UOX until after the initial Alphas of .9x so wasn't entirely sure what was a new feature of it, and what wasn't.
As a side note, we must also remember that at the time of the introduction of the .9x builds, there was no RunUO, and the other other system that compared to what was hoped with v1.0 was PoL, at least in the area of scriptability. Times, of course, have changed, and it's unfortunate that there haven't been enough around (and those of us who have been haven't had the time) to keep UOX up.
Blacksmith Menu look
-
Maarc
- Developer
- Posts: 576
- Joined: Sat Mar 27, 2004 6:22 am
- Location: Fleet, UK
- Has thanked: 0
- Been thanked: 0
- Contact:
It's been long enough that I don't remember all of it myself, so I've no doubt that I missed some things in there. If push came to shove, I could probably find old enough source on both to do a real compare, but I'd have to dig through a stack of CDs, and that stack just keeps getting bigger by the year, it feels.
But I'm also not trying to say it's perfect, either. Some decisions could have been better, I was still actively learning when I worked on it, and I am still actively learning now. It's far from perfect, but it's further along towards it, I think.
But hey, I also haven't looked at anything else in years, either
But I'm also not trying to say it's perfect, either. Some decisions could have been better, I was still actively learning when I worked on it, and I am still actively learning now. It's far from perfect, but it's further along towards it, I think.
But hey, I also haven't looked at anything else in years, either
Well it looks as if I made the mistake of assuming that the scripts did lie, at least partially, within the core speed-hungry sectors of the code. If they do not, then I do not have a problem with them as much as I did before. You made some very good points, and pointed out some things I was mistaken on, but there are some other points I’d like to bother you about as well:
First of all, even in an event-based setting, the scripting system is going to slow down everything. Granted, not nearly as much as it might have if it were in the core speed-intensive cycles, but the fact remains that, whenever an event is being triggered, everything else must slow down while the scripts are interpreted. So yes, 95% of the time on a small server, the scripts won’t have any influence, but the other 5% of the time, when people are causing events which trigger scripts, the whole server must slow to handle that 5%.
I would like to regress and say that, perhaps even with the above mentioned slow-down occurring, that might warrant JS for the increased user friendliness. As long as the JS does not creep into anything that is not event-triggered, then I won’t complain about it so much. Truth be told, however, a server is nothing but event-driven, so the more these events are exported to the realm of JS, the more the server as a whole will slow down.
As for your comment about C# being faster than C/C++… *sigh* I can’t believe you even believe that rubbish, I’ll say. It is wholly untrue that anything written in C# can not be written to execute faster in C/C++. Yes, C# can do some things faster is you write shabby un-thought-out code, especially in areas of 3D where you have to micro-manage a million little bits of information effectively, but the fact remains that, if written properly, C/C++ will always out perform or in worse case perform at the same level as C# code. There is nothing built into the C# language that allows it to execute faster than C/C++ code.
That’s like saying that something written in C/C++ can out-perform well-written assembly! In practice, that’s often the case, because people don’t care about getting all the speed they can in many situations. When it all boils down to the truth, though, nothing written in C/C++ can run faster as well-written ASM!
Now then, JS is not C#. JS is an interpreted language, whereas C# is a “just in time” language.
Don’t confuse intermediate byte code with what C# does. C# is compiled into machine code right before execution; therefore, it is the equivalent to any other compiled high-level language. Last time I checked, you guys aren’t doing that with JS.
Byte code is just that – byte code. Machine code is byte code that is thrown straight into the processor unaltered. Try throwing your byte code straight into the processor and see what it does with it!
When JS is compiled, it is compiled into byte code which is interpreted at run time. This is an order of magnitude much more inefficient than the machine code generate before execution by C#!
I wouldn’t be saying this if it weren’t true, I, more than anybody, despise C#, but unless you guys start writing JS compilers that compile it into machine code efficiently (if you can, you’re too smart to be working on a hobby project like this!), you can’t compare the two at all.
No matter how fast your JS interpreter is, it will ALWAYS be MUCH slower than machine code. Now way around that.
First of all, even in an event-based setting, the scripting system is going to slow down everything. Granted, not nearly as much as it might have if it were in the core speed-intensive cycles, but the fact remains that, whenever an event is being triggered, everything else must slow down while the scripts are interpreted. So yes, 95% of the time on a small server, the scripts won’t have any influence, but the other 5% of the time, when people are causing events which trigger scripts, the whole server must slow to handle that 5%.
I would like to regress and say that, perhaps even with the above mentioned slow-down occurring, that might warrant JS for the increased user friendliness. As long as the JS does not creep into anything that is not event-triggered, then I won’t complain about it so much. Truth be told, however, a server is nothing but event-driven, so the more these events are exported to the realm of JS, the more the server as a whole will slow down.
As for your comment about C# being faster than C/C++… *sigh* I can’t believe you even believe that rubbish, I’ll say. It is wholly untrue that anything written in C# can not be written to execute faster in C/C++. Yes, C# can do some things faster is you write shabby un-thought-out code, especially in areas of 3D where you have to micro-manage a million little bits of information effectively, but the fact remains that, if written properly, C/C++ will always out perform or in worse case perform at the same level as C# code. There is nothing built into the C# language that allows it to execute faster than C/C++ code.
That’s like saying that something written in C/C++ can out-perform well-written assembly! In practice, that’s often the case, because people don’t care about getting all the speed they can in many situations. When it all boils down to the truth, though, nothing written in C/C++ can run faster as well-written ASM!
Now then, JS is not C#. JS is an interpreted language, whereas C# is a “just in time” language.
Don’t confuse intermediate byte code with what C# does. C# is compiled into machine code right before execution; therefore, it is the equivalent to any other compiled high-level language. Last time I checked, you guys aren’t doing that with JS.
Byte code is just that – byte code. Machine code is byte code that is thrown straight into the processor unaltered. Try throwing your byte code straight into the processor and see what it does with it!
When JS is compiled, it is compiled into byte code which is interpreted at run time. This is an order of magnitude much more inefficient than the machine code generate before execution by C#!
I wouldn’t be saying this if it weren’t true, I, more than anybody, despise C#, but unless you guys start writing JS compilers that compile it into machine code efficiently (if you can, you’re too smart to be working on a hobby project like this!), you can’t compare the two at all.
No matter how fast your JS interpreter is, it will ALWAYS be MUCH slower than machine code. Now way around that.
One could argue the merits of code tireless, with ever reaching a conclusion, especially since the ones discussion haven't even agreed on the criteria that would be use to rank the merits *grin*giwo wrote:Thanks for your comments Maarc. I didn't really start programming for UOX until after the initial Alphas of .9x so wasn't entirely sure what was a new feature of it, and what wasn't.
As a side note, we must also remember that at the time of the introduction of the .9x builds, there was no RunUO, and the other other system that compared to what was hoped with v1.0 was PoL, at least in the area of scriptability. Times, of course, have changed, and it's unfortunate that there haven't been enough around (and those of us who have been haven't had the time) to keep UOX up.
As for what was considered the current state at the time the development of the current code base was begun, is really immaterial. It is today, and one is making decisions today. So one gets to look at it today, and decide where to go.
As for lack of programers, and all the reasons, personally I would tend to agree with Xuri, thatdocumentation isn't the real issue. There appear to be some characteristics fo the project that has plaqued it today and have been present for some time:
1. changes implemented unilaterial without real impact analysis. This falls into a few categories:
a. The next great idea they saw somewhere else, without a real thought/discussion on if the pay off was there for this project (what may be good for one project, may not be worth it on this one).
b. Starting something without really thinking it through and taking a critical look at it to discover the flaws (versus just to look to keep rationalizing you made a great decision).
2. changes started, never finished before starting something else
3. Lack of cohesive understanding or ability to work beyond a team of two to three people that is willing to incorperate and balance others priorities, even it means rework on things not considered high on one's personal list (not enough ability to compromise to get a good product as a team, versus what one percieved as the best product by themself.)
Now, this is just one persons consideration, and clearly, one has to take a a critical and open look at onesefl (not how one see's onself) to even begin to decide if this has any symbolize of reality or not. Now does it mean it that these characteristics would impact the progress of UOX in its current niche and approach. It mearly offers that perhaps the inability to attact it isn't technical, documentation, or features (for those all come and go). But perhaps something else, and perhaps some aspect of the above.
-
Maarc
- Developer
- Posts: 576
- Joined: Sat Mar 27, 2004 6:22 am
- Location: Fleet, UK
- Has thanked: 0
- Been thanked: 0
- Contact:
Sydius, you may believe it to be "rubbish", but it's not. I do understand the differences between interpretation, intermediate code, and just in time compilation down to machine code.
And it's not rubbish at all, in that the comparison that I eluded to is not for trivial pieces of code, but for a 3D engine that supports vertex/pixel shaders, shadowing, skeletal animation, multiple scene graph support and many other things as well (not to mention supporting OGL as well as DX7/9). It is certainly a non-trivial application, and there are some demonstrable cases where the C# engine was running faster than the C++ one. And it is not poorly thought out code or design, it is designed extremely well and with great forethought.
Nor did I say it would happen in *all* cases, I said it happens in some. And it isn't even about the language itself, but the environment it runs in. I have no doubt that it would be entirely possible to write a C# compiler that compiles straight down to machine code, just like C++ does. It is just, in its popular implementation, designed with a different target in mind. Though the lack of pointer support, except via unsafe code, does allow certain optimisations that C++ cannot reliably do (pointer aliasing is a big issue for C++, and why languages like Fortran can do better in scientific computing).
Just like OOE has helped extract greater runtime performance for CPUs, JIT execution engines can do similar adaptations, adjusting to the usage and runtime dependencies that are not visible at compile time, including processor target support.
However, that's somewhat of a digression, and it more meant as a side point (script languages don't have to be performance toilets). We also make some optimisations with our implementation of the JS script engine as well. When we load the JS scripts, we tell the JS engine to compile them into an intermediate code, so it's not string parsed and executed every time an event might fire.
But we take every effort to avoid the JS engine where possible. The first time an event is triggered for a script there is a potential slow down. But if the event doesn't exist, it gets flagged at the code level so that future attempts on those scripts won't even hit the JSE, and just skip over it, so there's a negligible performance penalty.
I'm sure what you say is what you believe to be the truth, just as what I say is what I believe to be the truth. But, all in all, it's too encompassing a subject to easily wrap up in anything less than a dissertation, I'm sure, and even then, it wouldn't be fully covered. Which isn't to say that I'm correct, I'm only expressing what my understanding is, which I will admit isn't as broad as some.
As for Punt....
I agree, it can be argued till one's blue in the face. And today is not yesterday, or the day when the 0.9x series was released, or a day before that, you're entirely correct. However, the purpose of my posting here wasn't to say "this is great" or anything like that, it was to point out the misunderstandings of Sydius in what the code base actually brought, in terms of improvements over the old system. He was ignorant about some of the improvements that the 9x series brought. I wasn't trying to say something was right and proper, just provide him with more information that he was lacking to make an informed decision. And you're entirely right, it's a snapshot of the past, and today is far more relevant.
I didn't want to weigh in on the lack of support issue, and I don't really want to know, I didn't want to contribute all that much to this thread (but that's no longer impossible). Your points are well taken, and I think would be a good start, and not entirely covering everything. But it does hit on the key thoughts and issues. And I will admit to being guilty myself on some of those points as well. I certainly hope that I don't try and spend time rationalising decisions I made, to the detriment of progress, but that's not something that can easily be decided upon for myself, as I don't think I do, but I could be wrong.
I will make only two comments about points 2 and 3, and they're not a defense or anything like that, just some information I believe is relevant.
2) This is a major issue, I wholeheartedly agree. Some of it bears from internal pressures, some from external. When people run into faults and issues that need rectifying quickly, inevitably, it takes a higher priority than what is being worked on currently (user usage is more important), so that fixing user issues happens more importantly than development. A solution to this, which would require greater work by others (including myself) would be trying things such as development and release branches, to seperate the new from the old or maintenance.
3) People have different time committments. I would suggest that, at any one time, there's probably only one, *maybe* two, people doing work. Others might be busy with study, work, family, whatever. Consequently, discussion would be minimal (or possibly, not public, but I'm conversations). Communication, more than documentation, I think needs to be improved.
But you're right, on those points. Communication, between developers, between developers and prospectives, between users, and between developers and users, needs to be improved, and compromise needs to be an essential part of that (communication is both talking *and* listening, something that's not always realised). Documentation is an aspect of communication, but not the sole way of doing so. Your second point can be alleviated to some degree by improved communication, and roadmapping, so deployment times can be understand, and that if someone can't work on it, the information is there for others to finish it.
This is getting long enough as it is, so I don't really want to touch on your first point. Suffice to say, I think different people have different ideas as to what level of research and analysis is required for certain things. Or that the world view is limited, so not all repurcussions of such decisions can be seen. And this would feed back into the communication.
Ultimately, I see it as a communication failure, more than anything (and Sydius's ignorance of what 9x brought, which started this to some degree, is a shining example of that).
And it's not rubbish at all, in that the comparison that I eluded to is not for trivial pieces of code, but for a 3D engine that supports vertex/pixel shaders, shadowing, skeletal animation, multiple scene graph support and many other things as well (not to mention supporting OGL as well as DX7/9). It is certainly a non-trivial application, and there are some demonstrable cases where the C# engine was running faster than the C++ one. And it is not poorly thought out code or design, it is designed extremely well and with great forethought.
Nor did I say it would happen in *all* cases, I said it happens in some. And it isn't even about the language itself, but the environment it runs in. I have no doubt that it would be entirely possible to write a C# compiler that compiles straight down to machine code, just like C++ does. It is just, in its popular implementation, designed with a different target in mind. Though the lack of pointer support, except via unsafe code, does allow certain optimisations that C++ cannot reliably do (pointer aliasing is a big issue for C++, and why languages like Fortran can do better in scientific computing).
Just like OOE has helped extract greater runtime performance for CPUs, JIT execution engines can do similar adaptations, adjusting to the usage and runtime dependencies that are not visible at compile time, including processor target support.
However, that's somewhat of a digression, and it more meant as a side point (script languages don't have to be performance toilets). We also make some optimisations with our implementation of the JS script engine as well. When we load the JS scripts, we tell the JS engine to compile them into an intermediate code, so it's not string parsed and executed every time an event might fire.
But we take every effort to avoid the JS engine where possible. The first time an event is triggered for a script there is a potential slow down. But if the event doesn't exist, it gets flagged at the code level so that future attempts on those scripts won't even hit the JSE, and just skip over it, so there's a negligible performance penalty.
I'm sure what you say is what you believe to be the truth, just as what I say is what I believe to be the truth. But, all in all, it's too encompassing a subject to easily wrap up in anything less than a dissertation, I'm sure, and even then, it wouldn't be fully covered. Which isn't to say that I'm correct, I'm only expressing what my understanding is, which I will admit isn't as broad as some.
As for Punt....
I agree, it can be argued till one's blue in the face. And today is not yesterday, or the day when the 0.9x series was released, or a day before that, you're entirely correct. However, the purpose of my posting here wasn't to say "this is great" or anything like that, it was to point out the misunderstandings of Sydius in what the code base actually brought, in terms of improvements over the old system. He was ignorant about some of the improvements that the 9x series brought. I wasn't trying to say something was right and proper, just provide him with more information that he was lacking to make an informed decision. And you're entirely right, it's a snapshot of the past, and today is far more relevant.
I didn't want to weigh in on the lack of support issue, and I don't really want to know, I didn't want to contribute all that much to this thread (but that's no longer impossible). Your points are well taken, and I think would be a good start, and not entirely covering everything. But it does hit on the key thoughts and issues. And I will admit to being guilty myself on some of those points as well. I certainly hope that I don't try and spend time rationalising decisions I made, to the detriment of progress, but that's not something that can easily be decided upon for myself, as I don't think I do, but I could be wrong.
I will make only two comments about points 2 and 3, and they're not a defense or anything like that, just some information I believe is relevant.
2) This is a major issue, I wholeheartedly agree. Some of it bears from internal pressures, some from external. When people run into faults and issues that need rectifying quickly, inevitably, it takes a higher priority than what is being worked on currently (user usage is more important), so that fixing user issues happens more importantly than development. A solution to this, which would require greater work by others (including myself) would be trying things such as development and release branches, to seperate the new from the old or maintenance.
3) People have different time committments. I would suggest that, at any one time, there's probably only one, *maybe* two, people doing work. Others might be busy with study, work, family, whatever. Consequently, discussion would be minimal (or possibly, not public, but I'm conversations). Communication, more than documentation, I think needs to be improved.
But you're right, on those points. Communication, between developers, between developers and prospectives, between users, and between developers and users, needs to be improved, and compromise needs to be an essential part of that (communication is both talking *and* listening, something that's not always realised). Documentation is an aspect of communication, but not the sole way of doing so. Your second point can be alleviated to some degree by improved communication, and roadmapping, so deployment times can be understand, and that if someone can't work on it, the information is there for others to finish it.
This is getting long enough as it is, so I don't really want to touch on your first point. Suffice to say, I think different people have different ideas as to what level of research and analysis is required for certain things. Or that the world view is limited, so not all repurcussions of such decisions can be seen. And this would feed back into the communication.
Ultimately, I see it as a communication failure, more than anything (and Sydius's ignorance of what 9x brought, which started this to some degree, is a shining example of that).
Well said… long, but well said. I dare say you may never find another UO emu forum in which a conversation such as this could continue in a civil manner such as has been the case thus far! I find it refreshing and educational.
Perhaps I did have some preconceived notions of what I thought the modern UOX is, and perhaps some of those are wrong. Yes, I did not know the extent to which JS was hampering normal cycles, but on the other hand, it is still the only reason why I am not more actively involved in the development.
I didn’t mean to offend anybody, by the way. I realize that the JS was being translated to intermediate byte-code long before interpretation, but byte code interpretation at best is still a speed toil in my mind compared to machine code. Perhaps this is unjustified, but I am an optimization perfectionist, concentrating on 3D engines (which is why I will still say that a C# 3D engine being faster than a well-written C++ one is rubbish!), so ANY slowdown that is unnecessary from my viewpoint is a bother to me which is difficult to overcome.
You do have a very valid point about the difficulty in maintaining a single primary source which would not branch into a new version of its own every time somebody wanted to customize something. Maybe another alternative could have been to export any potentially often-customized feature (such as the way skills work) to DLLs? That way, any updates to the core would not completely destroy any custom DLLs the end users are using.
That doesn’t address the “user friendliness” but at this point, anybody who desires that, has many better choices for emulator – even with JS, UOX is still far from as easy to customize as most of the others available. Yes, this was an issue worth pursuing a few years ago, but that time has came and gone, and the rabbit is too far ahead to make the chaise worth pursuit at this point.
What my real point is, is that, you have to find a niche audience if you are going to have an audience at all. That niche, I believe, could easily be the people who want the most serious, fastest, and most stable servers. That is the niche which I find is sorely lacking in good choices!
Learning C/C++ is not much more complicated than learning JS (maybe that is a skewed opinion since I learned the latter later), and I believe anybody intent on making the best server possible would gladly exchange the extra learning curve for the additional speed and power. I know I would!
Yes, pointers, classes, and garbage collection is all difficult to learn and far more difficult to master than JS, but for the typical user who might make custom DLLs, most of that wouldn’t even need to be known if a template is given to them – regular C alone would suffice, and I’m sure you agree, would execute many times faster than intermediate byte-code.
Before you point it out, yes, I know FUSE used a system of DLLs like I said, and I know it failed horribly because of that. That was when easy-to-use emulators didn’t exist, and once they start popping up, people left. Now many of those same people who left to use an easier one are looking for something a little more capable than RunUO or Sphere, and are left out in the cold unless they want to start their own version of UOX, which is what I did.
I admit I’m not making myself sound any better, and you guys will never agree, but I’m enjoying the conversation regardless. I like being blue in the face, you know.
Perhaps I did have some preconceived notions of what I thought the modern UOX is, and perhaps some of those are wrong. Yes, I did not know the extent to which JS was hampering normal cycles, but on the other hand, it is still the only reason why I am not more actively involved in the development.
I didn’t mean to offend anybody, by the way. I realize that the JS was being translated to intermediate byte-code long before interpretation, but byte code interpretation at best is still a speed toil in my mind compared to machine code. Perhaps this is unjustified, but I am an optimization perfectionist, concentrating on 3D engines (which is why I will still say that a C# 3D engine being faster than a well-written C++ one is rubbish!), so ANY slowdown that is unnecessary from my viewpoint is a bother to me which is difficult to overcome.
You do have a very valid point about the difficulty in maintaining a single primary source which would not branch into a new version of its own every time somebody wanted to customize something. Maybe another alternative could have been to export any potentially often-customized feature (such as the way skills work) to DLLs? That way, any updates to the core would not completely destroy any custom DLLs the end users are using.
That doesn’t address the “user friendliness” but at this point, anybody who desires that, has many better choices for emulator – even with JS, UOX is still far from as easy to customize as most of the others available. Yes, this was an issue worth pursuing a few years ago, but that time has came and gone, and the rabbit is too far ahead to make the chaise worth pursuit at this point.
What my real point is, is that, you have to find a niche audience if you are going to have an audience at all. That niche, I believe, could easily be the people who want the most serious, fastest, and most stable servers. That is the niche which I find is sorely lacking in good choices!
Learning C/C++ is not much more complicated than learning JS (maybe that is a skewed opinion since I learned the latter later), and I believe anybody intent on making the best server possible would gladly exchange the extra learning curve for the additional speed and power. I know I would!
Yes, pointers, classes, and garbage collection is all difficult to learn and far more difficult to master than JS, but for the typical user who might make custom DLLs, most of that wouldn’t even need to be known if a template is given to them – regular C alone would suffice, and I’m sure you agree, would execute many times faster than intermediate byte-code.
Before you point it out, yes, I know FUSE used a system of DLLs like I said, and I know it failed horribly because of that. That was when easy-to-use emulators didn’t exist, and once they start popping up, people left. Now many of those same people who left to use an easier one are looking for something a little more capable than RunUO or Sphere, and are left out in the cold unless they want to start their own version of UOX, which is what I did.
I admit I’m not making myself sound any better, and you guys will never agree, but I’m enjoying the conversation regardless. I like being blue in the face, you know.
Never hurts to look at something from another point of view!-
Xuri
- Site Admin
- Posts: 3704
- Joined: Mon Jun 02, 2003 9:11 am
- Location: Norway
- Has thanked: 48 times
- Been thanked: 8 times
- Contact:
Gah! First I saw this:
...and rubbed my hands gleefully together while giggling insanely to myself, as I thought "Aha! I can make an obscure reference to Fuse!", then of course you destroy my plans with your follow up comment:Sydius wrote:You do have a very valid point about the difficulty in maintaining a single primary source which would not branch into a new version of its own every time somebody wanted to customize something. Maybe another alternative could have been to export any potentially often-customized feature (such as the way skills work) to DLLs? That way, any updates to the core would not completely destroy any custom DLLs the end users are using.
That wasn't very nice of you, Syd. *sob*Sydius wrote: Before you point it out, yes, I know FUSE used a system of DLLs like I said, and I know it failed horribly because of that. That was when easy-to-use emulators didn’t exist, and once they start popping up, people left. Now many of those same people who left to use an easier one are looking for something a little more capable than RunUO or Sphere, and are left out in the cold unless they want to start their own version of UOX, which is what I did.
-= Ho Eyo He Hum =-
I want to ensure one understands how to interperate the observations, especially observation 2/3. Regardless of time commitements, a team approach can still be insititutionlised. The UOX project has more of an "individual process", with an integration at the end. If a single person has an idea, and even if others agree, it is usually left for the one person to implement all modifications for that change. Personally, I believe that contributes heavily to the symptoms one sees in the other observation. Even if time is different, and commitments can't be guaranteed, the approach of I will work this, if you have the time to work on UOX, you will make these mods for support of this change. If not done when one gets there, then clearly the initiater will get there.Maarc wrote: will make only two comments about points 2 and 3, and they're not a defense or anything like that, just some information I believe is relevant.
2) This is a major issue, I wholeheartedly agree. Some of it bears from internal pressures, some from external. When people run into faults and issues that need rectifying quickly, inevitably, it takes a higher priority than what is being worked on currently (user usage is more important), so that fixing user issues happens more importantly than development. A solution to this, which would require greater work by others (including myself) would be trying things such as development and release branches, to seperate the new from the old or maintenance.
3) People have different time committments. I would suggest that, at any one time, there's probably only one, *maybe* two, people doing work. Others might be busy with study, work, family, whatever. Consequently, discussion would be minimal (or possibly, not public, but I'm conversations). Communication, more than documentation, I think needs to be improved.
If one doesn't take some aspect of that approach, and when you couple with the other observations, there really isn't much for anyone to gain by contributing to the project. They don't really gain any support in the codeing aspect of their changes, nor any concept that high priority things in one's eyes will even be considered, if it means replowing some aspect of ground that the "old" team did (which of course, they replowed someone elese at one time). Clearly it is a balanceing act, but the key is balance, and compromise so that all benifit from working in a team. They can accomplish the same by just monitoring the code, and doing their own.
As for the incomplete code aspect, unfortunately it has been clear that some changes where never finished when other changes have been started that where not "fixes". However, some of this is clearly attributed to the paragraph above, that a change is basically left for one person to do, not the team.
It is far easier to work by oneself, or work in a team of 2/3 people, especilly when one feels they have "ownership" of the current design. It is hard for anyone, not just UOX dev's, to make the mental and process changes to expand a team beyond that size, especially people with new and different ideas that may even address some past decisions. It is more then communication, although that is a large part of it. It is fundementally how does a team operate? A federaion of essentially independent developers, with an integrator/decision maker or a set of team decisions/objectives that address at least some aspect of all the team's input, and then team works to make that happen (not a list of individuals).
I’ve never worked in a team on a programming project before, so I don’t have any experience to throw into this mix. I’ve always stuck to myself out of a seeming necessity, I suppose. A blatantly incorrect assumption of necessity would be a better way to put it!
I have a hard time agreeing with other people on how something should be implemented and even coding style. The biggest issue is probably a lack of coordination and too many varied skill levels which turns me off in a lot of ways. Not that varied skill levels shouldn’t work on a project like this, but like you said, punt, people are just biting off whole chunks to do on their own and that almost always involves something a little bit over the head of many of the people making the changes, I would suggest based on my observations of the source (I could be wrong).
It sounds as if we are making progress towards something better, though. I don’t know to what end, but certainly all this text can’t go to waste on def ears?
I think we should get something rolling with UOX, and I will work on it now that you guys have educated me enough about the roll of JS to make me want to even look at the source, that is if you want my help!
First, though, we need to get some kind of organization a level above what punt pointed out is happening right now.
A single leader I would not agree to easily. They are too prone to mishap in the future – they disappear randomly, cause fights, become egotistic, and just in general make people lose faith in a project anytime there is a disagreement. You guys all know this is true.
Instead, I believe an official “team” should be created of people who want to contribute to the project in some way. I believe the team should be open to the public, and allow anybody who is at least semi-active in the project (via the forum, IRC, coding, whatever) to join – any skill level, any time.
When joining the team, I think a summation of the person’s strong points in whatever area they plan to help with should be made by themselves so as it to make apparent to everybody in the team what they would be good at and what they would be willing to help with. This would just be for organizational purposes.
Next, I think an overall goal of the project should be established. Everyone in the team could contribute objectives, and then they could be put up for a vote to be come part of the “official” objectives. Everyone in the team would have an equal vote.
Once an official objective is decided on, then sub-components of the objectives would be decided on in the same way. Then, when everything is decided on, people can begin coding.
Instead of biting off whole “objectives” like they are now, they would bite off sub-components of objectives… small tasks that sum to the whole. The difference would be that the entire team would be able to see what everyone is working on and have a say in how important it is. Because everything would be defined before coding, a lot of potential problems and conflicts could be found before any time is wasted coding, and everything in the end would be of higher quality.
People would volunteer for sub-objectives, and automatically get the task if nobody else has it. At any time, any person working on a sub-objective could be voted out of doing it, if, for example, they just disappear without a word. Or do a crappy job.
Once finished with a sub-objective, it could once more be put up to vote as to the fitness with the rest of the code. If it is accepted, it becomes part of the official code base, if not, a list of changes which must be made can be compiled somehow, and work can be done to make it fit.
This idea would decentralize the organization process, allowing people to join and leave the team easily without the project faltering. The down sides, are, obviously, the voting system would be comparatively slow, and when there aren’t very many team members, the chances of them all working on the same sub-objective would be slim.
The way to fix the slow voting issue would be, I believe, to put a time limit on each vote. Say, a week for official objectives, a half-week for sub-objectives, etc. That way the process moves forward at a fixed rate.
As for the second problem, I think that could be solved largely if you only accepted small “official objectives” while the team is small.
If there are only 3 or 4 coders, then I would not vote to accept more than one official objective at a time. Then all of us could vote on and work on the sub-objectives contained within that one official objective. If the team grows, we could put more official objectives up to vote.
Anyway, what you guys think?
I know this whole idea is kind of complicated and would probably need a lot of ironing out, but it’s a start, and a start is needed, I would say.
I have a hard time agreeing with other people on how something should be implemented and even coding style. The biggest issue is probably a lack of coordination and too many varied skill levels which turns me off in a lot of ways. Not that varied skill levels shouldn’t work on a project like this, but like you said, punt, people are just biting off whole chunks to do on their own and that almost always involves something a little bit over the head of many of the people making the changes, I would suggest based on my observations of the source (I could be wrong).
It sounds as if we are making progress towards something better, though. I don’t know to what end, but certainly all this text can’t go to waste on def ears?
I think we should get something rolling with UOX, and I will work on it now that you guys have educated me enough about the roll of JS to make me want to even look at the source, that is if you want my help!
First, though, we need to get some kind of organization a level above what punt pointed out is happening right now.
A single leader I would not agree to easily. They are too prone to mishap in the future – they disappear randomly, cause fights, become egotistic, and just in general make people lose faith in a project anytime there is a disagreement. You guys all know this is true.
Instead, I believe an official “team” should be created of people who want to contribute to the project in some way. I believe the team should be open to the public, and allow anybody who is at least semi-active in the project (via the forum, IRC, coding, whatever) to join – any skill level, any time.
When joining the team, I think a summation of the person’s strong points in whatever area they plan to help with should be made by themselves so as it to make apparent to everybody in the team what they would be good at and what they would be willing to help with. This would just be for organizational purposes.
Next, I think an overall goal of the project should be established. Everyone in the team could contribute objectives, and then they could be put up for a vote to be come part of the “official” objectives. Everyone in the team would have an equal vote.
Once an official objective is decided on, then sub-components of the objectives would be decided on in the same way. Then, when everything is decided on, people can begin coding.
Instead of biting off whole “objectives” like they are now, they would bite off sub-components of objectives… small tasks that sum to the whole. The difference would be that the entire team would be able to see what everyone is working on and have a say in how important it is. Because everything would be defined before coding, a lot of potential problems and conflicts could be found before any time is wasted coding, and everything in the end would be of higher quality.
People would volunteer for sub-objectives, and automatically get the task if nobody else has it. At any time, any person working on a sub-objective could be voted out of doing it, if, for example, they just disappear without a word. Or do a crappy job.
Once finished with a sub-objective, it could once more be put up to vote as to the fitness with the rest of the code. If it is accepted, it becomes part of the official code base, if not, a list of changes which must be made can be compiled somehow, and work can be done to make it fit.
This idea would decentralize the organization process, allowing people to join and leave the team easily without the project faltering. The down sides, are, obviously, the voting system would be comparatively slow, and when there aren’t very many team members, the chances of them all working on the same sub-objective would be slim.
The way to fix the slow voting issue would be, I believe, to put a time limit on each vote. Say, a week for official objectives, a half-week for sub-objectives, etc. That way the process moves forward at a fixed rate.
As for the second problem, I think that could be solved largely if you only accepted small “official objectives” while the team is small.
If there are only 3 or 4 coders, then I would not vote to accept more than one official objective at a time. Then all of us could vote on and work on the sub-objectives contained within that one official objective. If the team grows, we could put more official objectives up to vote.
Anyway, what you guys think?
I know this whole idea is kind of complicated and would probably need a lot of ironing out, but it’s a start, and a start is needed, I would say.
-
Xuri
- Site Admin
- Posts: 3704
- Joined: Mon Jun 02, 2003 9:11 am
- Location: Norway
- Has thanked: 48 times
- Been thanked: 8 times
- Contact:
Does it really have to be any harder than having people post their plans/ideas in the forum, for instance "I'm thinking about doing ..blah blah..and this.. blah blah .. and then ..blah blah blah." and allow for some responses before going ahead with it?
Or "What if we.. blah blah... I could do it myself." Or replying to bug-reports saying "I'm on it, should be possible to fix by blah blah blah.". Or any number of such variants.
I'm all for keeping it simple and accessible to everyone who wants to participate. *shrug*
Btw, I'd LOVE to see you coding for UOX3, Syd =)
Or "What if we.. blah blah... I could do it myself." Or replying to bug-reports saying "I'm on it, should be possible to fix by blah blah blah.". Or any number of such variants.
I'm all for keeping it simple and accessible to everyone who wants to participate. *shrug*
Btw, I'd LOVE to see you coding for UOX3, Syd =)
-= Ho Eyo He Hum =-
That really wouldn’t solve the issues with impacts on other parts of the code base, or anything else, for that matter. The process needs to be more drawn-out, I think, with more planning over every little change before it is made, instead of changing every little change a million times down the road…
Assuming the project felt there was even an issue they wanted to resolve, I beleive the KISS (Keep It Simple Stupid) would probablyhave some merit. Again, the number one change that one perhaps get the most bang for the buck (as it addresses multiple of the observiations), was the mental and implementation shift from individual contributors toward team effort. If the next thing is to change X, but X requires the following changes through out the code, that is divided up, not left to the one dev who proposed it in the first place. In other words, the "team" finishs one thing as a whole (not an individual) before the next goal. Clearly some don't need more then one persons effort, but that is identified by exception.
The second process change is compromise. Willingness to compromise to gain the "teams" desire, not just one's own or others objectives. If it comes down to one team member never feeling as if their primary desires are EVER implemented (or some part of), then clearly eventually that person will draw the conclusion, the team isn't helping them acheive any aspect of what they want, and leave. So that is the next consideration for change.
Both of these don't require a lot of "process" or documentation. It is more a fundemental philosophy shift. But of course, first one has to decide there is an isuse first, and that one really does want to expand beyond what the current size is (for one loses control when that happens as well).
The second process change is compromise. Willingness to compromise to gain the "teams" desire, not just one's own or others objectives. If it comes down to one team member never feeling as if their primary desires are EVER implemented (or some part of), then clearly eventually that person will draw the conclusion, the team isn't helping them acheive any aspect of what they want, and leave. So that is the next consideration for change.
Both of these don't require a lot of "process" or documentation. It is more a fundemental philosophy shift. But of course, first one has to decide there is an isuse first, and that one really does want to expand beyond what the current size is (for one loses control when that happens as well).