Extremely naive view of software engineering Was Re: [OT] was: Where is NSList? (All Threads)
Extremely naive view of software engineering Was Re: [OT] was: Where is NSList? (All Threads)
- Subject: Extremely naive view of software engineering Was Re: [OT] was: Where is NSList? (All Threads)
- From: "Erik M. Buck" <email@hidden>
- Date: Fri, 30 Jul 2004 09:52:21 -0400
>
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.