Reply to thread

Message

<blockquote data-quote="Hollywood" data-source="post: 456776" data-attributes="member: 7408">&quot;Hard-coding&quot; and &quot;scripting&quot; without context are bad terms.&nbsp; &quot;Scripting&quot; is not any different than &quot;hard-coding&quot; EXCEPT that the &quot;code&quot; is available to the end-user, sometimes but not always, to be changed outside of closed system and is either interpreted at run-time or pre-compiled.&nbsp; &quot;Hard-coding&quot; is &quot;code&quot; that the user can not change, modify and recompile.With an open-source effort there becomes ZERO difference between &quot;hard-coding&quot; and &quot;scripting&quot; because everything is open.Just because someone, gamer or not, can &quot;code&quot;, does NOT mean they can engineer a quality piece of software.&nbsp; It takes a lot more than knowing a little bit of Java, or reading a few tutorials, to build a quality software product.&nbsp;&nbsp; The, as you noted, the subject must be understood and &quot;experts&quot; on the subject matter should be available to the technical people.&nbsp; Design goals must be laid out, both short term and long term, and absolutely NO scope-creep should be allowed until the first revision is finished... you may scale back features, but not add them.&nbsp; Technical architects must take said design goals and put together a solid architecture that will meet said design goals, both short and long term.&nbsp; Only then should the design and development of the software commence.&nbsp; 3rd party developers can get around some of that, especially in the case where there is a lone or very small [2 or 3] set of core persons working on the software, as they are more able to come to understandings quickly than a bulkier organization such as WotC.&nbsp; Even then, software can easily be turned into nothing more than spaghetti code.&nbsp; Taking short-cuts for a consultant, such as Fluid, when dealing with a large client such as WotC will only lead to failure of the product.Want to know if your favorite tool's developer is engineering the software rather than just &quot;coding&quot; it?&nbsp; Ask the developer about the BSAs [not so important to 3rd party developers], design and architectural documents, interface mockups and user feasibility tests, UML and database diagrams, etc.&nbsp; They don't have 'em?&nbsp; Then they are doing nothing more than shootin' from the hip.&nbsp; Period.Technically any data storage system can be called a database.&nbsp; As a software, game or otherwise, is meant to manipulate data, yes they did have prior experience.&nbsp; As for relational database experience, unless you've seen their resumes, you really don't know for sure.&nbsp;&nbsp; Database &quot;programming&quot; really is not all that hard at its base level.&nbsp; It rises in complexity based on the complexity of the data needing to be stored.&nbsp; 3rd edition data is fairly complex, but its not exceedingly complex nor is there a very large volume of it.&nbsp;&nbsp; Good engineers can come up with very good database designs even if their actual database experience isn't all that much.</blockquote>

[QUOTE="Hollywood, post: 456776, member: 7408"] "Hard-coding" and "scripting" without context are bad terms. "Scripting" is not any different than "hard-coding" EXCEPT that the "code" is available to the end-user, sometimes but not always, to be changed outside of closed system and is either interpreted at run-time or pre-compiled. "Hard-coding" is "code" that the user can not change, modify and recompile. With an open-source effort there becomes ZERO difference between "hard-coding" and "scripting" because everything is open. Just because someone, gamer or not, can "code", does NOT mean they can engineer a quality piece of software. It takes a lot more than knowing a little bit of Java, or reading a few tutorials, to build a quality software product. The, as you noted, the subject must be understood and "experts" on the subject matter should be available to the technical people. Design goals must be laid out, both short term and long term, and absolutely NO scope-creep should be allowed until the first revision is finished... you may scale back features, but not add them. Technical architects must take said design goals and put together a solid architecture that will meet said design goals, both short and long term. Only then should the design and development of the software commence. 3rd party developers can get around some of that, especially in the case where there is a lone or very small [2 or 3] set of core persons working on the software, as they are more able to come to understandings quickly than a bulkier organization such as WotC. Even then, software can easily be turned into nothing more than spaghetti code. Taking short-cuts for a consultant, such as Fluid, when dealing with a large client such as WotC will only lead to failure of the product. Want to know if your favorite tool's developer is engineering the software rather than just "coding" it? Ask the developer about the BSAs [not so important to 3rd party developers], design and architectural documents, interface mockups and user feasibility tests, UML and database diagrams, etc. They don't have 'em? Then they are doing nothing more than shootin' from the hip. Period. Technically any data storage system can be called a database. As a software, game or otherwise, is meant to manipulate data, yes they did have prior experience. As for relational database experience, unless you've seen their resumes, you really don't know for sure. Database "programming" really is not all that hard at its base level. It rises in complexity based on the complexity of the data needing to be stored. 3rd edition data is fairly complex, but its not exceedingly complex nor is there a very large volume of it. Good engineers can come up with very good database designs even if their actual database experience isn't all that much. [/QUOTE]

Verification