Managing Forth Projects

The first part will deal with a question that arose from remarks I made last year. The second part will deal with an issue the estimation of  which has grown in my practice to one of overwhelming importance, that is, the role of documentation in managing Forth projects.

Last year in my address I took an approach that was for me the natural approach, that of treating the management of Forth projects as a problem of management  psychology. The minor tempest that arose as a result of that discussion and of a followup article in “Embedded Systems Programming” magazine this spring is both amusing and instructive.
Briefly, I stated that managing creative people could become trying under the best  of circumstances, and that furthermore the situation was exacerbated when the creative people happened to be Forth programmers, who tend to be intoxicated with the ideology of programming as an act of empowerment of the individual, and of Forth as the panacea for all issues in computer science. I offered some suggestions based on my experience, both as a member myself of said ideological clique, and as a manager of a team of very productive Forth ideologues of the type I had mentioned.

This turned out to be a controversial tack. T here were several people who felt that I had misled the public with the title of my paper, “Managing Forth Projects.” They wanted to hear a lecture on CASE tools, on methodology, etc. I had, it was true, dealt briefly with such subjects, but overall my listeners and readers had been treated to a discourse on management psychology, and some felt cheated. One correspondent went so far as to write me that my lecture had “as much to do with managing Forth projects as an article on the sex lives of air traffic controllers would have to do with the question of the existence of UFOs”.

ESC_1991_Vol2_Page796_Woehr – Managing Forth Projects.pdf

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.