|
RE: Re: Development: A Structured Problem Area?: msg#00028programming.language-of-the-year
> -----Original Message----- > From: Robert Watson > [mailto:robertcwatson-/E1597aS9LQAvxtiuMwx3w@xxxxxxxxxxxxxxxx] > Sent: Wednesday, June 16, 2004 4:27 PM > To: pragprog-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx > Subject: Re: [pragprog] Re: Development: A Structured Problem Area? > > Greg Jorgensen <gregj-/VAaTXopHTZWk0Htik3J/w@xxxxxxxxxxxxxxxx> wrote... > > > > In 25 years of professional programming I have never seen formal > > requirements or specifications that were worth the time > spent on them. > > Having the programmer(s) work directly with the customer/user, > > possibly with a skilled analyst acting as mediator, always (in my > > experience) leads to a better result. Without that interaction > > projects either fail or turn into death marches. > > I'm only a couple of years behind you and I couldn't agree > more. However in medicine, it took centuries of > blood-letting, chants and snake-oil sales before the populous > was willing to accept that the human body was too complex and > there were too many variations from person to person for > simple rule-based diagnoses and treatment solutions. > > Doctors, with their unstructured body of experience, thus are > allowed to occupy a rare nitche that is far less susceptible > to automation than most and thus remains very expensive. It > is quite reasonable then for non-programmers to assume that > this is the exception to the rule and that software > development, like most other jobs can be greatly simplified > and automated thus making it cheaper. > > However, having had some training and experience in the > medical field, I find the processes used in both endevours to > be largely identical. The difference is only in the body of > knowledge (i.e. the data). When I'm debugging a program, I'm > using the same reasoning, testing and diagnostic processes as > a doctor. And to the health of the business or organization, > that software is usually just as important as a person's health. Your example, debugging, is a good example of where expert programmers use intuition. I think it true that the most effective way for an expert programmer to debug a system is to rely on her vast experience with similar problems. However, my question is whether the same problem can be solved with a rule-based method, though perhaps not as efficiently by humans. If so, I think this opens an opportunity for the CMM to act as a leading wedge for final automation. And rule-based automation *might* just outperform a human expert performing at the peak of ability. Of course, I don't really expect debugging to be automated. What I think might be automatable is the initial production of implementation from requirements and that this, done correctly, would render debugging a moot point, unless you were the programmer maintaining the automation. The question, in my mind, is still whether there is anything intrinsic to producing an implementation from requirements that prevents a rule-based solution. By intrinsic, I mean a property of the problem, not a property of the agent solving the problem - arguments that the best humans perform best intuitively, while true, miss the point. I still have yet to hear an argument that couldn't have been made about 3GL compilers and they clearly are possible. Isn't this just raising the level of abstraction another layer? Derek Richardson ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Domains - Claim yours for only $14.70 http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/nhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/pragprog/ <*> To unsubscribe from this group, send an email to: pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | RE: Development: A Structured Problem Area?: 00028, Derek Richardson |
|---|---|
| Next by Date: | Re: Development: A Structured Problem Area?: 00028, Glenn Vanderburg |
| Previous by Thread: | Re: Development: A Structured Problem Area?i: 00028, Bryan Ewbank |
| Next by Thread: | Re: Re: Development: A Structured Problem Area?: 00028, Edmund Schweppe |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |