management is flawed because it creates intermediate layers of redundant information, because it craves and hoards knowledge. management should be a conduit rather than a repository of information, allowing specialists to provide 'hooks' into their knowledge, directly to others.
peer-to-peer works best because hierarchy presents a barrier to communication; a reserve of doubletalk. social interaction encourages productivity with a kind of information ease and comfort.
the web works too fast; our project was groundbreaking six months ago, would be original now, and will be slow and static within six months.
(also content indecision; editorial pride, and bells-and-whistles of the comedy-cgi kind. maybe having to break down presentational boundaries between commodity and service information; realising that traditional genres of information no longer apply)
nelson is compelling me to hold it down, verbally; to be more reflective about gunk words like 'functionality' (then still risible; now embedded, seeming necessary). i want to achieve that kind of information precision.
self-sufficient objects, and the relation to this of the principles of object design. thinking about the issues in a more abstract way, identifying the patterns of 'management'.
after a certain point, the more overtly you manage, the more likely you are to fail. the more information you collect for re-distribution, the more chaos you create.
peer-to-peer communication is so important because it encourages information-share. you are more likely to adopt a principle if it is evolved rather than dictated; more likely to commit to and engage with a work in which you play a significant part. allowing people autonomy (note the underlying agency) encourages mutual respect.
reinforcing hierarchy and protective jargon in gobbledegook titles.
it's the extent of agency i find it hard to figure out, whether that's an important thing, or just part of the old model, and will wither away after the paradigm shift ;-) we probably have to admit that a project needs an architect, a vision, but point out that current management models fail to provide that successfully either.
we need a shared language, reinforced by a hyperglossary. our descriptive language (for projects, schemas, methodologies, anything that is a part of a 'work') should be based on domain terms, on the concepts and objects perceived by domain specialists. part of this process is 'delimiting' domains in order to exclude irrelevant aspects and focus on key ones; part of the overall design strategy to identify exclusive domains, and codify the relations between them.
existing functional domains within existing organizational structures are a good place to start. but the emphasis should be on function not title; titles don't communicate enough, are often misleading, and carry too much hierarchical baggage. the domain is definitely not the department, but functional specialisms within that department.
wondering if you could use a hyperglossary to define the same terms to different users, at different levels of abstraction or focusing on different areas of implementation detail.
inequalities in the workplace encouraged by excessive heirarchy excessive 'ceremony' ; excessive hierarchy heirarchised chains of communication, more opportunity for information to slip, decreasing signal-to-noise. distance between specialists and those planning and evaluating the project. tying up productivity with evaluation; reducing the productivity of specialists.
structuring a project around documentation fallacious; text can have too much weight on it. this is like vaporware, more pernicious because developers' time is misused.
the reading and writing of documentation is a solitary activity, less clear opportunity for knowledge-share, more possibility of misreading. reiteration of document instances generates noise. practitioners resort to hard copy for meaningful treatment and use of these documents; this is ridiculous and wrong, literal clutter and waste.
view of technical documents either as a progressive collection of clutter, or as a monolithic final statement of fact (a 'manual')predetermined chapter headings, to be filled in as required. symptomatic of the 'waterfall' model of development. (hypertext better suited to the iterative model)
instead of viewing components as large deliverables, expecting each one to be fully functional as is, taking a kernel of the whole project, a few pieces of core functionality, a 'skeleton' presenting the development as a kind of controlled, organic growth over iterative stages.
highly paid, talented analysts and developers sit idle for years on fated, unfeasible, neglected projects, dropped for political and commercial reasons. everywhere work, effort, resources and duplicated, multiplicated, through lack of communication and collaboration.
the practices of modern commerce are obfuscatory and divisive. to drive development by these forces is damaging.
the positive solution is encouraged by the principles of object design; iterative development, domain-driven modelling, rapid prototyping, and the patterns and abstraction stuff which i don't understand properly yet; or that these are principles only made meaningful by practice. the outcome / action of good design is that the model becomes simpler, the more you understand; a kind of ockham's razor, the best model is the simplest possible one; a bad model is evidence of a bad reality. we need to redesign the reality.
but a lot of that object design stuff is just plain common sense. and everyone i've spoken to about these issues is in complete agreement, recognises their experience, contributes their observations; everyone that is, on the 'factory floor',
02/07/98