Neverwinter Nights Forum News

Remove all ads!

(Originally posted by chevalier)

Here are today's Neverwinter Nights forum highlights. Please take into account that these are only single parts of various threads and should not be taken out of context. Bear in mind also that the posts presented here are copied as-is, and that any bad spelling and grammar does not get corrected on our end.

Don Moar, Tools Programmer

RAD tools: The problem isn't the RAD tools.

I venture to say that this is how software development is done in most companies:

1. Users want to see a functional GUI in a simulated production (not test) environment before they will "sign off" on a prototype.

2. Programmers burn all their design, development and shakedown time trying to get "sign off" on their prototype.

3. Managers with schedules to follow and resources (time, staff, money) to budget want the program done on time.

The end result is a rather comical chain of events. First, the "users" complain to "management" that they're falling behind because the "programmers" haven't finished the program. "Management" then pressures the "programmers" to get the program done (typically resulting in severe overtime). "Programmers" polish off the prototype since that's pretty close to what the "users" want and because (they think) it'll take less time than doing it the right way. Finally, the program is rolled out. The "users" are happy, "management" is happy and the "programmers" just want to move on to something else. Unfortunately, there are subsequent changes or bugs left in the system that require additional time and which can't be dealt with effectively due to the lack of proper design. At last, the program is finished but now, the schedule has lost valuable time needed on the next project.

This happens regardless of whether RAD tools are used, it's just that with RAD tools, the cycle is more... rapid. As professional programmers it is our responsibility to communicate to the rest of the team (i.e. non-programmers) that programming is more than just banging out code. On all but the simplest of projects you have to break your schedules up into time for design, ui prototyping, development, qa, shakedown, communicaiton and some buffer. Note that this doesn't imply a waterfall cycle approach - these tasks can be done using whatever development methodology you choose but all the steps are necessary. Included in each of these phases must be time for adequate documentation. If things start to slip, you have to communicate them back up the chain as soon as it happens.

You also require a formal approach to change-management. The goal is to prevent half-implemented or untested features from making it into the next release build but remain flexible enough to handle emergency requests. As a professional programmer, it is up to you to move your organization towards a more disciplined approach to software development. Record what you're doing today to serve as a baseline, read books to find ideas on how to improve your situation and then talk to your management and users. These people are not programmers and cannot be expected to understand what you require to do your job if you cannot explain and justify it yourself. If you're working in a lousy environment don't just blame management, work towards changing it.

Further:
I sympathize, PJ. Fortunately, I've been able to make many of the changes I just described to tools development at BioWare over the last couple of years and I'm continuing to work on the others. Tim, RAD is not a development methodology - at least that's not how I've been using the term. To me, RAD is matter of using special tools and programming languages such as C++ Builder or VB. So I think the comparison between RAD / non-RAD and C / ASM is a valid one.

The problem is that today's tools are so good that discipline and training are not as required as they were 20 years ago. Using these tools it is possible to make many simple programs perform adequately on small datasets. This approach simply doesn't scale to larger and more complex projects. The problem is that pretty much every programmer has to learn this on his or her own because it's not taught effectively at most schools.

Here's another example of the problem. While not technically a RAD tool, many source control programs support the simultaneous check-out of the same file to multiple users. While this does eliminate the problem of programmers being blocked by each other, it requires the careful merging of changes. The risk is that changes can be accidentally overwritten or otherwise replaced resulting in the introduction of more bugs. It's another case of a tool supporting capabilities that require training and discipline to use properly. Personally, I don't like this feature. I think any file that's so big (in size or functionality) that it requires multiple programmers to work on it simultaneously should be split up. But then, I'm extremely risk-adverse in my approach to software development. Right, Tim?