Re: Extremely naive view of software engineering Was Re: [OT] was: Where is NSList? (All Threads)
Re: Extremely naive view of software engineering Was Re: [OT] was: Where is NSList? (All Threads)
- Subject: Re: Extremely naive view of software engineering Was Re: [OT] was: Where is NSList? (All Threads)
- From: Janek Priimann <email@hidden>
- Date: Fri, 30 Jul 2004 17:03:47 +0300
On Fri, 30 Jul 2004 09:52:21 -0400, Erik M. Buck
<email@hidden> wrote:
>
>A very good programmer will first:
>
> 1) analyse his data structures and required methods (procedures)
>
> 2) available languages and resources
>
> 3) intended distribution (effects choices in 2)
>
> 4) time table for development
>
>
Ok, I got a great laugh out of the above quote. I am still smiling. I
>
would have thought by now that this type of naiveti was so thoroughly
>
discredited that universities would no longer teach it. It is particularly
>
ironic or perhaps sad that the poster went on to list the archetypical
>
example of premature optimization. He described a way to make matrix
>
arithmetic much more computationally efficient by making the algorithm/code
>
much more complex. The whole point is that there is no need to make the
>
code more complex unless profiling reveals that matrix multiplication is the
>
performance bottleneck in the system. If instead displaying the results of
>
the matrix math is what limits the programs performance or fetching the
>
matrix values from disk is the limiting factor, somehow making the math take
>
zero time will have little or no effect on the performance of the software.
>
Prematurely implementing the matrix math in any way other than the simplest
>
most self documenting way will degrade the future maintainability of the
>
software for no benefit. [I might add the simplest most self documenting way
>
is probably to call an existing library routine.] Furthermore, the specific
>
hardware operations that limit code performance are often surprising and can
>
not easily be predicted. For example, memory access is so slow/expensive on
>
the Itaniums systems I use that almost any amount of computation to avoid a
>
memory access is worth it. Typical patterns such as recalculating a table
>
of constants and looking up the values as needed is overturned on these
>
systems because it is usually faster to recalculate the constants on demand.
>
>
Finally, just to ridicule traditional "Software Engineering" for fun:
>
>
Any software development process that requires the existence of complete and
>
correct requirements is doomed to failure. I assert that in all of human
>
history, no non-trivial software development project has ever had complete
>
and correct requirements at any time in the development process. It _may_
>
be premature to attempt step one in the sadly misguided list of steps above
>
at any time before a full prototype product exists that can be profiled,
>
analyzed by potential users, tested for "correctness", etc. Wait until the
>
prospective users tell you that your carefully and expensively chosen data
>
structures and "required methods" contribute little value to the software
>
because it is much more important to them to have a better visualization of
>
the fluid dynamics being modeled and the way input data is collected from
>
the sensors has inadequate precision or is so slow that the critical
>
measurements are being missed. You might say that the users should have
>
given clear requirements up front for the precision of the sensors and the
>
sampling frequency and the requirements for visualization. Too bad!
>
Customers and bosses are famous for not having any imagination, and they
>
probably don't know a-priori what sampling frequency is needed, and they are
>
likely incapable of describing what they mean by "visualize." Hence, only
>
after prototyping [possibly several times] can the true requirements be
>
determined, and only then can any "data structures and required methods"
>
other than the simplest and most self documenting be profitably selected.
>
>
And don't get me started on the most common but unrealistic expectation of
>
"bosses":
>
1) A development schedule must be devised, and one of the early activities
>
in the schedule will be to identify all the requirements for a software
>
system.
>
2) The schedule can not have too much "pad" in it.
>
3) The software development team is expected to perform to the schedule and
>
meet all milestones in the schedule.
>
selected at the start of a project before even the requirements are known.
>
>
The above process has never worked, at it is obvious why:
>
>
A) How can a schedule for software development be made before the
>
requirements are fully known ?
>
B) The requirements are often NEVER fully known.
>
C) It is impossible to predict the future and complex multi-year software
>
projects are the most impossible of all ;{
>
>
Finally, read Fred Brooks, the most famous "software engineer" of them all:
>
http://www.amazon.com/exec/obidos/ASIN/0201835959/qid=1091195357/sr=ka-1/ref
>
=pd_ka_1/104-9091647-2243152
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
>
>
I completely agree with Erik.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.