[Courses] [C Programming] Anyone still here?

[Terri Oda]

At 08:59 AM 24/05/02 -0700, you wrote:
>I have a different sort of question, a very basic level one: I've done
>some simple programming in a few languages and it's fun. But I always
>feel like I'm missing some basic level understanding of the process. I was
>a science major, not CS, and so just figured out how to write some Perl,
>etc out of necessity. My question lies in how do you know how to approach
>a problem, how do you know where to start, other than "well see if this
>works, if not then try something else, until something apparently works"?
>That approach strikes me as a great way to write really bad mistakes.

Actually, this is far from a basic question!  I've seen quite a few CS 
majors who haven't gotten the hang of this, and I have one friend who 
commented that the large company he works for has, um, problems with this 
aspect of things.  ("They don't write any specifications until *after* the 
code is written.  Our process is all backwards!")

Many of the people I know who do software design could divide it into a few 
stages:
* Figuring out what you need (Requirements gathering)
         Asking the people who will be using the thing what they want out 
of it, trying to guess what they're not saying and what requirements might 
change.  Try to ignore what you know can and can't be done -- this is a no 
limits stage.  You don't want to end up thinking "they don't want this" 
when it's actually "I can't implement this, so I steered them away from it".

* Finding a good way to solve the problem
         Here's where you look at the requirements and figure out how they 
fit together *and* how you want to extend it.  Sure, right now no one you 
know has more than X phone numbers and Y addresses, but what if...  If 
you're into design patterns, you might want to try to find some that fit 
your problem.  (Design patterns are established good solutions to various 
types of problems and well worth taking a look at whether you want to use 
them or not.)

* Actually implementing the solution
         This *should* be the easiest part.  It isn't always, but if you do 
your design right you don't have to reimplement... much. :)  (Changing 
requirements mean I can't say you never have to reimplement a good design.)

* Testing the solution
         I'm not sure if this should be in with "implementing" but I 
decided it was important enough to warrant its own section.

There's lots and lots of different ways to actually do each of these 
steps... Programming books, nice as they can be, usually concentrate on the 
last step. I can probably dig up some links to the diagrammatical and 
documentational solutions I've been asked to use in school and outside, but 
I've left this post sitting in my outbox for several days and if I leave it 
much longer I'll never send it.

Oh, and these steps aren't really discrete.  Often times, something gets 
forgotten in one step and you have to move backwards.  I *wish* I could see 
all the requirements in phase one, but often they change or I've just 
misunderstood someone's request, or they've misrepresented what they 
actually want.

My own feelings?  My approach depends on the problem.  If I'm writing a 
quick shell script and most minor CGI stuff, often I can do it off the top 
of my head, no conscious design necessary.  Many times, once you've seen 
similar things solved, you can find a good solution intuitively.  My 
databases prof said "You know, even my grandmother would come up with a 
decent database design if I asked her.  Lots of people do these things 
automatically."  So yeah, some computer scientists *might* be miffed at the 
idea of being taught what they do intuitively.  The key here is that once a 
problem approaches a certain size, it's a bit dangerous to do that.  So 
people who refuse to think about *how* they program either (a) work with 
similar problems so often that it *is* intuitive for them, (b) want to 
pretend that they're good without accepting that being good takes work or 
(c) probably have to reimplement their systems often. :)

If I'm working with something bigger, I like to doodle solutions.  I sketch 
out a system on paper or in a text editor, play with it it a bit, and try 
to figure what needs to be done.  Actually, I do this with all sorts of 
things.  If there's something about *anything* that irks me, I'll tend to 
sit down and plan how I'd do it better.  It's practice, I suppose, but I 
actually do it to vent frustration when, say, my car has a lever in the 
wrong place for me or the registration system I'm using on someone's 
website doesn't do what i want or whatever.

Once I've got some doodles, I run them past some friends/co-workers if I've 
got time.  Who depends on what I'm working on... sometimes, I want a fellow 
programmer's opinion, sometimes I want an opinion from someone who's got a 
better sense for the aesthetic, sometimes I want an opinion from someone 
who'll be using the finished product or uses similar things, sometimes I 
want an opinion that just isn't mine. :)  More doodles, more consultation, 
maybe some preliminary coding so I can see how things work and eventually 
I'm ready to actually build whatever it is.

I could go on, but I think that's enough for now. :)

  Terri