[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[$0.02] Re: What design is: 911 vs. Fleetwood



Greetings

I have not seen much of this newsgroup (as a rule, I don't read newsgroups;
haven't for years).

Of course, this being what it is, I do have some (hard won but changeable)
opinions on language design.

Let me add some Engineering viewpoints.  [I am simply going to state what
most of you already know, so you probably want to delete this missive now. 
Complaints to /dev/null].  


[1] Make a situation where you solve real problems and are able to "learn
fast".  You can grow-it instead of build-it only if you can learn really,
really fast.  How do you do that?

Make mistakes cheap and easy to fix.  In eXtreme Programming
<http://www.extremeprogramming.org> a number of rubrics (e.g. continuous
testing, all tests must pass 100% of the time, write tests first) make
mistakes {a} easy to find and {b} easy to fix (found a mistake before doing
much work beyond/based on it).  [Think of what language features would
support eXtreme Programming development].


[2] Have some goals which are reasonable and allow you to {a} understand
what is going on and {b} do things reliably.  The first principles of
interface design are visibility and control: What is going on?  What can I
do about it?  (Most things which make computing hard seem to be problems in
interface design, including sin-tax,  IDEs, and project management).

Something I have been thinking about for some time is where personal
computing went wrong.  I would like "over 60's computing" -- i.e. devices
my parents can use.  Systems which are reliable, never lose data, and can
be asked to explain themselves: What can I do here? What are you doing?
What are my options?


[3] Who is your customer?  Get them involved in determining the goals and
constraints.  Periodically ask them how you are doing.

When I undertake an engineering project, the LAST thing I choose is the
implementation technology.  The goals and constraints of a particular
project determining the shape of the design space which must be filled. 
Doing fundamental cost/benefit analysis gives the answer on what sw
implementation (language) technologies best match requirements.  What
features of the development process (not just the language or IDE) give
good cost/benefit from the point of view of the people making decisions
about implementation technologies?

Practicum:

Last year I worked in a startup which did a multi-platform 24/7 server
project (NT/Solaris/Linux).  We needed to sell into fortune 1000 financial
institutions, among others, which have expectations of zero data loss, 5
nines reliability, processes which run for 2..3 years or more.  Also, we
had to plug into whatever database and web technology out customers were
using
(IIS/Apache//PHP/JSP/ASP/Perl//PostgressSQL/SQLServer/Oracle/ODBC//..). 
When you can't afford to fail, what development technology do you use? 
[see draft article: http://home.earthlink.net/~kend0/ExtremeSuccess.html
for the answers we chose].


[4] Be aware of scale.  We still see people trying to use device-driver sw
development technologies to build major systems.  People also try to use
big systems methodologies and techniques in PDAs.  Some things just don't
scale.  Some do.


[5] Make it fun!!!  When I started programming people still wanted to make
things fun.  People seem to have lost that somewhere.  A lot of us think
it.  Let's go ahead and say it.


[6] Use good UI principles.  

I should be able to write code reliably which is self commenting and
evidently correct.  I needed a R5RS Scheme READ procedure recently.  I
wrote and debugged it in a day (in Scheme) because virtually all the code I
wrote worked the first time.  The few mistakes were easy to find and
trivial to fix.  It is OK to say "we aren't trying to keep losers from
losing, but to help winners to win big", but don't make obfuscation the
obvious thing to do.  Code should be written to be read and understood. 
[One of the winning things of Scheme48 is that it has the goal of being
comprehensible].


[7] Provide stellar debugging and tuning support.

The saying is that with procedural languages, you get to product by slowly
creating fast, broken code and debugging it into a product.  With dynamic
languages you rapidly create a working system which is then tuned into a
product.  Many dynamic environments lose on the tuning facilities.


[8] Value people and communication above (the/a) technology.


OK, ok, I'll get off the rant now.  But I didn't see these viewpoints
expressed (like I said, I just started reading).  I'll go back to coding
now.


Still Learning,
--- Ken Dickey
--- kend0@earthlink.net