On Nov 21, 2007 9:35 AM, Dustin Puryear <dustin at puryear-it.com> wrote: > I was just thinking about posting a similar note. Seems to me if a true > document management system is overkill then a wiki would work great. > Just create a hierarchy of pages and each leaf page would be dedicated > to a document (attached) and metadata (wiki notes). > > main > -dept1 > -proj1 > -doc1 > -doc2 > -doc3 > > Here at Puryear IT we actually use a mixture of systems. Not ideal, but > it's working so far. Basically, for project management we use a > web-based system which allows us to attach versioned documents to a > project and/or project tasks. For documents not specific to a project we > either dump then on network storage or we write them directly as text in > an internal wiki. >
Dustin, Over here the main barrier to adoption (and refinement) is simply, use. Too Busy... to do...this...got..to..code.....can't..use this... don't know how....don't have time figure it out.....gotta code... gotta get my fix in....I didn't come up with this documentation system it sucks....it gets in the way of my process....can't find anything.....I'll just stub it out and put in the specifics later (never).... .. are the developer impressions I get in general when I've seen developers forced onto a rigid system. <rant> Most developers have a split personality when it comes to using the keyboard : they like to churn out code and get things done; they hate to commit to anything specifically NOT code. (The same goes for completion dates, estimates, requirement analysis, etc) I find this quite amusing since I play both sides of the development cycle. :-) Developers, as a class, are die-hard perfectionists have a magnificent work-ethic for code specific work; they love to be working hard. They live for this stuff. This slanted effort feeds the "excuse" for the more drudge work avoidance. That most developers have an overwhelming workload, gives validity to this "excuse". In the end, stuff either gets done or not. Whether it gets done timely or results in a useful solution is another issue entirely. A documentation system that only causes pain (real or perceived) will not be usefull. </rant> Ease of use...hey man this really works for me....wow, cool! neat trick....I can do this.... are the impressions my ideal documentation system should make. Perhaps I should be referring to "Document Generation & Maintenance" as "refactoring the project's English codebase. Any guidance on what works and the context use is/has been appreciated. Lots of good stuff to think about. Thanks fellow luggers.
