Re: Word vs ???? phylosophy

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

<<lots of great software corporation bashing deleted :-)>>

John McGhie [MVP - Word and Word Macintosh] wrote: 
On 6/9/05 6:25 AM, in article uqUD$flsFHA.1132@xxxxxxxxxxxxxxxxxxxx, "Jeff
Wiseman" <throwawayacct223@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

My impression is that there are far more "gotchas" when learning
Word basics than Interleaf basics. There have just seemed to
always be far more "exceptions to the rule" that a novice Word
user has to learn and guard against to avoid his thesis being
trashed in unexpected ways.



OK, now here is where you and I have a philosophical departure from the Word
design teams.  Firstly, Word is designed in three "layers" -- "Unskilled
User", "Power user", and "Solution Designer".  Three completely incompatible
user groups being served by three sets of often mutually-incompatible
features.


And yet those types of people frequently work in overlapping roles at the office in a totally compatible fashion! That means its the application creating divisions that have the problems--usually by attempting an overly simplistic solution to an inherently complex problem.

The statement I have a bit of a problem with (as I would assume John does too) is "Word is designed in three layers". No. That implies that a cohesive set of layered functions existed that the product was designed around. The layer concept has been introduced later to an already legacy product.

The pre-existing functional controls of Word have been arbitrarily shoved into three groupings of increasing complexity that MS wants to call "layers". New functions have been added against such layers which does improve there cohesion some. However, these layers were invented after the fact--they do not really reflect an internally layered infrasturcture of essential operations and their relationships. The nitty-gritty inconsistencies in the UI's presentation of these functions is evidence of this.

In MS's defense, this again is a good (correct) approach but at the core of the thrust, they need analysts/architects with tremendous abstraction modeling capabilities, the drive to maintain cohesion (i.e., fight software entropy), and keep marketeers on leashes.

Entropy begets entropy and structure begets structure. If you start off with a scrambled product, in general, it will only get more scrambled and will enjoy a short evolutionary life until it reaches a point that no one dares change or add anything for fear of breaking it. On the other hand, a product who's architecture is highly structured around its application will actually get better over time with less effort since the structure tends to become "stronger".

The Mac OS is an example of this. It's entire structure was forced into an "object oriented" mode because a non-programmer was specifying what the UI was supposed to do long before the concept of OO even became common. UNIX is another example with its application being development driven.

To drop reduce the entropy level on a product until it reaches "critical mass" so that it begins to restructure itself in an evolutionary fashion is very difficult. I've seen it happen on one product in my life so I do know it is possible (it was in fact a product that I worked on). If a large enough "chunk" of software is added to a legacy product that has been very highly (and CORRECTLY) strucutred to the problem domain of the product, it can actually cause the future maintenance of the product to start becoming easier. In the product I worked on, once we added the structured piece, over the next 2 years many times adding new features wound up resulting in the compiled size of the product being less than the previous release with fewer features in it.

Creating a layered system only works if there are true layers in the problem domain for the feature set (i.e., the layers are truely cohesive in their definition). Implementing it can be a problem it corporate minds don't look long term and analysts don't understand the long term evolution of application feature needs.


Microsoft has literally hundreds of millions of dollars worth of research
that proves conclusively that most of its users not only do NOT want to
learn their product, they will strenuously resist any attempt to teach them.



It cost them THAT much to discover that?  :-)

Of course, the corollary is that if you design a product that's foolproof, only a fool will want to use it...



Usually what is happening there is that Marketing is dictating
not essential features, but rather design decisions that are not
their business. When allowed to do so, this ties the software up
in knots!



When not allowed to do so, you get a spike in local unemployment, consisting
largely of "programmers" ...


Ooops. Silly me, I was thinking of efficiently providing for the end customer :-) If we let marketing drive it we can keep developers employed changing things that weren't needed, improving things that weren't implemented completely, regression testing release after release after release. And don't forget the customer service people trying to explain how all these simple features in overly complex user interfaces are really suppose to work (assuming that they are not all in India, etc.) since no one reads the huge documentation sets that must be upgraded and tested from release to release.

Oh heck! I just realized..."getting it right the first time" through effective analysis only gives folks like ME any job security. Everyone else is out of luck!

I see what you mean John. Bummer.


solution is having good systems analysts that have excellant
object analysis and modelling skills. When you have folks like
that to spec the requirements on your systems, what usually
happens is any knee-jerk design decisions can either be blasted
out of the sky immediately with a mass of information as to the
ramifications of putting such a change in,



Oh, dear, you *have* been out of the loop for a while, haven't you :-)  Let
me disabuse you with some of the sadder realities of software as it is
thrown together these days...

1)  The skills you are talking about belong to good software architects.
Software architects get paid four times what top business analysts get, so
nobody with those skills is going to be sitting there analysing
requirements.


Actually, I'm talking about engineering analysts. Basically system architects that aren't allowed to do design. Business analysts usually lean more in the marketing areas. The trick is to get the senior developer *OUT* of the Design role and into the spec role. Hard to do since they usually don't find it as much fun :-)


2)  Microsoft has a software development budget approaching eight billion
dollars.  They can afford the right people :-)



Or ONE high power CEO and an offshore development team :-)


3)  In the modern software development environment, you are not going to
"get" the six months it would take you to derive requirements this way.  You
got a month to do this, Joe...


Right. But you ARE allowed the next 3 years to fix what you screwed up. That's ok, the customer backlash can be handled, they've done it before...


4)  The more you analyse the problem, the more information you collect.  But
the more senior the manager, the less they have time to read.  It's a fact
that anything over five pages won't be read -- anything over ten pages is
wasted typing.


Again, I'm proposing a function in the Engineering realm that can provide feedback in the distilled fashion needed by senior management.


5)  There's no point in producing this information because nobody with the
chance of influencing the decision is going to read it!  I won't say where
or when, but quite recently I saw the "Specification" for a 60 million
dollar system development.  It was six PowerPoint slides.  They removed two


True, but cohesive specs should really be done with pictures anyway. I took a 73 page spec for a telecomm product security system that no one could really understood anyway and condensed it into a one page entity relation diagram that everyone could understand. It also within 1 hour of being distributed revealed 3 long term security holes that had been in the system for years...

Good structural analysis is wonderful. It can be applied to just about anything. People think in a certain natural structure (i.e., things and how they relate). If you can reduce any description of a system down into this simple form, it is far easier for others to understand and communicate it.

However, the concept is a lot like a flowchart. Just about anyone can read or understand them. They are simple creations. However, actually creating one yourself that is GOOD and clean can be very difficult sometimes.



--
Jeff Wiseman
to reply, just remove ALLTHESPAM
.

Relevant Pages

  • Re: OOP/OOD Philosophy
    ... The methodology is well-documented. ... It is agile because the term 'extreme' as been so over-exposed that the ... > in which you do design can enable the team to respond to change, ... > that surveys of users have shown that nearly 50% of all features in a BDUF ...
    (comp.object)
  • =?windows-1252?Q?www=2Eelectronics=2Dmac=2Dsony=2Ecom___Motorola_KRZR_K1_Phon?= =?windows-12
    ... Product Features and Technical Details ... the KRZR K1 is the definitive handset for those who ... design, you get Bluetooth wireless technology, an integrated music ... detailing and premium materials shrouded within a distinctive metallic ...
    (alt.cellular.verizon)
  • Re: Difference between randomness and automated selection
    ... alternative features in an organism on some metric of "differential ... Gene Poole Pond, where they dump in all their gametes ... My world view is only within a YEC pattern design dichotomy. ... If your definition differs from the above, ...
    (talk.origins)
  • Re: Testing your data access layer in another project part of same solution
    ... You're missing some layers. ... DAL that act upon the database model. ... Domain Driven Design and Test Driven Design. ... You need to find out how to use the ADO.NET Entity Framework an ORM ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Code generation - Was: AOP in PHP - Was: OO in PHP
    ... It's called meta programming and though the concepts ... else (or there is no performance problem at all), ... There is much design humbug with respect to C++ and Java ... More features usually means more code. ...
    (comp.lang.php)