More on design, for programs, and for web.
> It's hard to define it briefly. A function point is essentially
> a single identifiable externally-visible action. In a browser,
> "follow a link" and "display a message" might be FPs. That
> probably raises more questions than it answers.
External, as in user-visible. Ah. I though it more like an internal
function or decision point. Under your definition, a good part of what I
said is not correct then. Though... one can minimize externally visible...
options through design; but not too much...
> > ... (Small wonder Yourdon says 60 percent of the DP projects fail!)
>
> Ed is an incurable optimist.
Yes, he is an optimist, but the typical web designer probably does not
understand the degree of disaster inherent in software development. After
all, no matter if there are a few spelling errors on a web site, it
basically works. A few spelling errors in a program, and it usually
crashes, sometimes after working for a little while. English is a
wonderfully forgiving language! Language English, forgiving wonderfully
is! Understanding possibly is despite screwedly ungramaticall
constructsions and eroniously unczecked spullings. But in programs, when
you mean acceleration = 1.23 * traversal_distance, and you say
aceleration, in some languages, you won't get an error. It will just
create a new variable called aceleration and assign to it. Meanwhile, it
will leave acceleration set to whatever it was before, like 1.0, resulting
in very subtle problems.
> > ... I would also say that quality is not a function of the
> > number of function points. A poorly designed system will need more
> > function points than one that has been well designed.
>
> FP count should be independent of the goodness of design; FP count
> measures what it does, not how well. However,
I could argue either way on that. However, I vaguely recall seeing
many cases where things could have been made much smoother, more along
variations of a theme, rather than distinct commands or controls.
In web sites, I think these are more like decision points on
pathways, which page do you go through next.
> > And as one develops
> > the system, it is probably that additional function points will have to be
> > added to "catch" the failures of other function points, distorting the
> > design and bloating the function point and line counts.
>
> In other words, design in fact ends up saying a lot about *what* the system
> does as well as *how*. So true.
Yes. Though what I meant, was that where the ... noding of the
internal functionality is not done well, (component compartmentalization,
whatever you call it,) there need to be more internal functions, and
exception handlers, and alternative functions, etc. As re-design
progresses, much of this rises as... becomes extraneous user-controls and
synchronicity requirements on those user controls, making it more
difficult to properly operate the tool. (Or find the way through a web
site. A web site is not a canyon. The helicopters are always hovering to
take a user back to the search engines.)
> > Since programmer productivity is about 2,500 lines of code per month,
>
> Over what population? We did some pretty extensive surveys in the early
> days of the Ada effort, and got figures like 700 LoC/month for simple
> systems and 100 or less for things like OSs, signal processing, fire
> control.
> You have no idea the extent to which the government wastes your money.
That bad!!!??? What I heard was that 2,500 was fairly consistent
across different languages. Which is why when I was forced to produce
140,000 lines of code in three months, I wrote something in Word Star Mail
Merge to do it for me. (Rule based form letters with a lot of conditional
clauses. Only difference was, the letters would be read by a C compiler,
not a pet owner. I wrote maybe 4,000 lines of real code in those four
months, and generated probably over half a million, most of which got
tossed out and re-generated differently as the specifications kept
changing. Which is why I went with a rule based approach in the first
place!)
> On the other hand, I once implemented a real-time kernel for the Navy
> with one other guy; we were competing with a team of six from Univac,
> using the same requirements specs and the same (extensive) suite of
> correctness and throughput tests. We did 5000 LoC/mm; they did <800.
> We had 3 bugs; they had over 200 when we gave up trying to get them
> through the test suite. Their source code was three times as big as
> ours and their executable image was twice as large.
Clarity in Design and Clarity in writing!
> > People who do something for an income are generally interested in the
> > income, and "getting it out the door". People who do something because
> > they enjoy it are interested in the craftsmanship of their own work, and
> > tend to implement improvements as they see them without such high regards
> > for deadlines.
> I don't buy that; it's not all one or the other. I work for the income
> because it lets me buy the toys and fat pipe to the net. I do good work
> because it get me the next job as well as for its own sake. I bust a
> gut to make my deadlines because I know that giving users a working system
> as early as possible is the best thing you can do.
If I am coding for myself, I'll take a stab at it with a crude
prototype to see if I have the idea down right. THEN, once I prove the
idea, I will try to write something that is cleaner, going back and being
a lot more willing to toss out chunks of code that just does not seem the
way _I_ want it to look.
I can't do that on my client's dollar that often, not unless the new
approach reduces code size significantly enough to get me to completion
faster.
> > So assuming Woodnose95 uses about average programmers, call it 5 on
> > the scale; ... Linux (programmers) are probably between 8 and 10
>
> I don't know, the small number of MS programmers I've known have been
> very good. They've mostly been graduates of the CS program at Brown or
> second-generation Brown -- kids taught by our kids who went off to teach
> at MIT, UNH, Princeton, Washington U, etc. I don't think that MS has bad
> programmers in general, I'd tend to put the blame more on their middle
> management and on whatever group it is that decides what features to add
> to new releases of their products. This latter group apparently has never
> met a feature they didn't like.
I agree about middle management. But what I kept seeing in the
lectures MS gave at the Software Entrepreneur's Forum, was a kind of "one
way" attitude, a one path focus that I found unsettling. There is rarely
a single best way. Whenever I get in on a disaster project, as I review
the existing code, I feel that the designer/coder/whoever stood at some
point, picked a fairly good approach, but didn't see the more generic
approaches, and optimized his decision structure for an overly narrow
design goal. Somewhere between a quarter to half way into the project,
(or more rarely before the intended three quarters mark,) management
changed the objectives, and he did not go back and start over. If it was
near or beyond the three quarters mark when the goal changed, then it is
just a mess with code that is grafted and slathered on haphazard, and
everything is beginning to flake and shake.
I always aim to create a more generic structure to the code, so when
the competition announces something, we have a better chance of adapting.
I call it structured modular frameworks, for lack of better name.
The same principles apply to web design, because web sites grow!
Good initial designs have to be modular to allow for extensions that will
come. (And my site is in dire need of redesign!)
[EMAIL PROTECTED] ------------------ [EMAIL PROTECTED]
----------------------- IMAGINEERING --------------------------
----------------- Every mouse click, a Vote -------------------
---------- Do they vote For, or Against your pages? -----------
----- What people want: http://www.mall-net.com/se_report/ ----
---------------------------------------------------------------
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------