The Artima Developer Community
Sponsored Link

Weblogs Forum
Programming as Typing

57 replies on 4 pages. Most recent reply: Jul 12, 2006 12:20 PM by James Watson

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 57 replies on 4 pages [ « | 1 2 3 4 | » ]
Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming as Typing Posted: Jul 7, 2006 5:38 PM
Reply to this message Reply
Advertisement
Bruce Eckel wrote
-snip-
I'm not defending Larman. I tend to come down on Issac's side of the fence on this one.

Here's a funny thing - Craig Larman and myself seem to be on the same side of the fence.

"My view is that software engineering shouldn't be religion and should indeed be based on evidence and statistics, and appreciate Isaac's or anybody's improvements to whatever I wrote."

Now if only we could have some corrections posted on the book website :-)

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Programming as Typing Posted: Jul 7, 2006 8:07 PM
Reply to this message Reply
Over the years there has been a tremendous variation in approaches to software development. Some development has succeeded and some has failed, but there really hasn't been a common methodology you could pin success or failure on. If there's any general conclusion you can draw from this, it's that methodology really doesn't matter.

It's more likely that success or failure is project-specific. It depends on the individuals involved, the schedule, the budget, the requirements, the technology, etc (We see this philosophy embodied in the testing that Underwriters Laboratory preforms. UL tests each product without regard to the certification of other products a company makes).

So the problem with these unscientific experiments is that people try to draw too general a conclusion from them. Any approach can work some of the time, especially if the people involved have the extra motivation of proving a pet theory.

The real question is why organizations would want to go to the time and expense of adopting a new methodology without any hard evidence that it will work. I think I have an insight into why.

My mother used to be a secretary for a rheumatologist. Many patients were in great pain due to arthritis and they were always asking the Dr. about quack remedies they heard about. Arthritis, as you may know, is a disease that sometimes goes through a natural remission, so once in a while the patients would try one of these "cures" and it would apparently work. So they spread the word about the new "cure".

In much the same way, organizations feel the pain of software development and are willing to try just about anything to make the pain go away. They try something a new and the first time it might work. Then they're convinced that the new way is responsible for their success, forgetting that they've been successful using the old methods too.

Barry Hawkins

Posts: 1
Nickname: barryh
Registered: Jul, 2006

The Perceived Prevalence of Testing Posted: Jul 8, 2006 2:29 PM
Reply to this message Reply
"I've learned not to trust the fact that there's a lot of noise about something. It usually doesn't correlate to reality. A friend works for a company that's just now learning about unit testing, and apparently testing in general. I've consulted with companies where testing is still a new thing. My guess is that the majority of software developers have not yet accepted the importance of testing, and that it's only the noisemakers on the leading edge who have been learning and talking about it, and thus giving the impression that it's now well accepted."

Well put, Bruce. That calls to mind my saying about unit tests I shared with you: Unit testing is like toilet paper; everyone has it everywhere I go, but the quality varies widely. ;-)

I am dismayed by the number of "noisemakers" I run into who proclaim the good news of testing yet when pressed (or better yet code reviewed) it turns out they're sold on the idea of testing, not the practice.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: The Perceived Prevalence of Testing Posted: Jul 9, 2006 10:01 AM
Reply to this message Reply
> I am dismayed by the number of "noisemakers" I run into
> who proclaim the good news of testing yet when pressed (or
> better yet code reviewed) it turns out they're sold on the
> idea of testing, not the practice.

I agree, and yet my own experience has been a slow addition of more and more testing techniques over time. I was sold on the idea after my first experiment, which was with "Thinking in C++, 1st edition," significantly before unit testing became popular. But I find that I've added more testing a portion at a time, as I've come to understand that particular portion.

I think testing may be a bigger fundamental shift than we acknowledge. It's "just testing," like it's such an obvious idea. And yet the whole scientific revolution was based on the concept of testing your ideas, and that has been a fundamental shift in civilization which has taken centuries to incorporate, and we are still struggling with it. In my own situation, I find that testing is affecting the way I design things in the first place, by making me design components for testability in addition to their basic functionality.

So I'm starting to think that we have to allow for the time and effort required for a foundational shift in thinking when we talk about testing.

Ed Borasky

Posts: 2
Nickname: znmeb
Registered: Sep, 2005

Re: Programming as Typing Posted: Jul 9, 2006 1:02 PM
Reply to this message Reply
> Another example of noise vs. reality: people are always
> saying that there are still more COBOL and FORTRAN
> programmers out there than any other kind. But when was
> the last time you saw one, much less talked to one? By
> that metric, they don't exist. But apparently there are
> tons of them.
Well ... I used to use FORTRAN and I'm still a programmer, so I suppose that makes me a "FORTRAN programmer". :) But seriously, folks, I wrote my last significant piece of FORTRAN in early 1990. My current languages are Perl and R, and I'm in the process of learning Ruby.

> I think the problem is that while many programmers
> understand that programming happens in the mind, and the
> code itself is just an artifact of the process, outside
> the field, the code looks like it's what you're doing. (An
> understandable perception, since the code is the core
> deliverable). So if it's about the code and not the mental
> process behind the code, it makes sense that you would do
> whatever you can to produce the code as fast and as
> cheaply as possible, and to discard anything that appears
> to hinder the creation of code. From this follows the
> logical ideas that coding is typing, so you want to see
> people typing all the time, and that 10 people can type
> faster than one person so if you can hire ten Indians
> cheaper than one US programmer, you're going to get a lot
> more typing done, so you'll get big economic leverage.
>
> In reality, study after study indicates that success
> comes from who you hire. This suggests that programming is
> not a mass-production activity where programmers are
> replaceable components.
You're using the kind of "noise" arguments you've decried earlier in your post. "Study after study indicates that ...", etc. So ... I showed you a "FORTRAN programmer", you show me the "study after study". :)

> This is probably why I keep fighting with the
> static-dynamic language debate, because it has the same
> feel to me. You can come up with all kinds of reasons that
> static checking is a good thing, until you have an
> experience programming in a dynamic language where you are
> vastly more productive than with a static language. But
> that experience defies the logic used to back up the
> reasoning behind static languages.
That depends on how you measure productivity. I've been programming a long time, and the two main factors in my productivity have always been familiarity with the application domain and familiarity with the programming environment. Throw in a new domain or a new language/OS/IDE/whatever and I slow down to the level of "average programmer" very quickly. But I'm equally productive in a static or dynamic language, other factors being equal.

> Here's another one. I believe that "details matter,"
> and that noise really does wear you down (studies show
> that noise makes you tired). What I'm talking about here
> is visual and complexity noise. So I was disappointed
> when, for example, Ruby turned out to have begin and end
> statements, and that it uses "new" to create objects.
> These are all noise artifacts from previous languages,
> required to support their compilers. If your language
> creates all objects on the heap, you don't need to say
> "new" to distinguish between heap and stack objects (like
> you do in C++, which was mindlessly mimicked by Java). And
> everyone always indents their code, so you can use
> indentation to establish scope. Besides the fact that I'm
> justifying the design minimalism of Python here, when I
> put these ideas out I will probably get a lot of perfectly
> reasonable rationalizations about why this is the best way
> of doing things. And without questioning the fundamental
> principles upon which those arguments are founded, those
> arguments will be pretty airtight, even if they really
> come down to "I'm used to that and I don't want to think
> differently about it."
I think once any programmer has learned macro assembly language, Lisp and Forth, he or she will always be disappointed in any other language. At least that's the way it has been for me. I started programming with a fairly decent macro assembler. But until you made this comment, I never really understood *why* I prefer macro assembler, Lisp and Forth.

Ed Borasky

Posts: 2
Nickname: znmeb
Registered: Sep, 2005

Re: Programming as Typing Posted: Jul 9, 2006 1:15 PM
Reply to this message Reply
> I have since thought of an even better analogy than
> writing novels, which should have been obvious since I've
> acted in a number of plays recently and because
> programming is more often a team activity. One difficult
> person in a cast can easily screw everything up. And
> choosing cast and crew must be done with care, selecting
> each person for the way their skills fit with the need.
> Actors are not interchangeable; you must get the right
> ones to do the job.

My experience has been that difficult people are not usable in any setting, small or large. They need to be promptly confronted with the impact their behavior is having and removed from the project if the behavior is not changed immediately.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming as Typing Posted: Jul 10, 2006 1:07 AM
Reply to this message Reply
> <p>I think the problem is that while many programmers
> understand that programming happens in the mind, and the
> code itself is just an artifact of the process, outside
> the field, the code looks like it's what you're doing.

In order to make programming a commodity and reduce it to typing, a higher level of abstraction is needed that what existing programming languages offer.

Take Java, for example: the programmer has to know what primitive types are, what are references, what 'new' means, what is a thread, how to synchronize between threads, what is 'break' and 'continue', what is the difference between '==' and 'equals', what is an interface, what is a class, what does it mean to override a function, what is the difference between array/list/map, what is an exception and what does throw mean etc.

All those details are very low-level, very computer-specific. A good high-level programming language would most probably had few datatypes (numbers, strings, aggregates, sets), few declarations (databases, procedures), few statements (if, while, invoke), intrinsic set operations (add, remove, clear, for-each)...there are high-level languages that have these elements, but they also have a lot of other stuff difficult to comprehend by average Joe programmers (like monads, for example).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming as Typing Posted: Jul 10, 2006 6:31 AM
Reply to this message Reply
> Jeff Ratcliff wrote
> > > I think the problem you're facing is that you are
> > > approaching these issues scientifically, but the
> > > proponents of methodologies such as CMM and Agile are
> > > not.
>
> James Watson wrote
> > Is it really fair to pick on Agile here? I've never
> seen
> > anyone provide any scientific evidence for the success
> of
> > any development model. It's all anecdotal as far as I
> can
> > tell.
>
> Ummm it doesn't seem like Jeff Ratcliff did "pick on
> Agile" - he gave CMM as an example as well as Agile.

Well, I don't really see CMM as a development methoddology. It's more of a process management methodology. It's kind of like saying Ford cars and GM factories can't fly. True, but Honda cars can't fly either. Prehaps Agile is incompatibe with CMM, but CMM doesn't say which development methodology to use. My point is that waterfall doesn't have any empirical data (that I know of.) Pick a development methodology. There's no proof it works. So it seems odd to speak only of how Agile isn't proven scientifically.

Jim Carroll

Posts: 7
Nickname: mrmaple
Registered: Jan, 2006

Re: Programming as Typing Posted: Jul 10, 2006 8:19 AM
Reply to this message Reply
Thanks Bruce!

I've been using a combination of C++ and Python to write a large scale application. Things have come together very well. I've been able to do what feels like some of the most productive software development I've ever done.

I think that code that's appropriate in Python doesn't necessarily translate to well designed C++. It does answer the questions along the lines of, "what is an appropriate object model" but the step from object model to C++ that keeps the dependencies on the abstractions is still a big step.

I do think that Python is letting me postpone the C++ implementation of some parts of my software. There are times when I know that a well-designed model layer in C++ is going to take a few weeks, but I can get the prototype implemented by substituting some Python lists and sets. Any issues that come up while I'm still prototyping can be addressed (seemingly) instantly using the dynamic Python structures.

Only once the prototype has solidified do I feel like I know enough to make the C++ effort worth the programmer-time.

It's great to read that you value Python in a similar way.

What I’m finding is that some of the strengths that Python has would take me years to duplicate in C++. So instead of considering my Python work a prototype, I’m thinking of it as full-blown application development.

-Jim

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Programming as Typing Posted: Jul 10, 2006 10:46 AM
Reply to this message Reply
> Well, I don't really see CMM as a development
> methoddology. It's more of a process management
> methodology. It's kind of like saying Ford cars and GM
> factories can't fly. True, but Honda cars can't fly
> either. Prehaps Agile is incompatibe with CMM, but CMM
> doesn't say which development methodology to use.

I was speaking in very general terms. Scrum is considered part of the Agile family and it's also a process management methodology.

>My
> point is that waterfall doesn't have any empirical data
> (that I know of.)

I don't have much to say about the waterfall because it's really a straw man, not a methodology somebody proposed.

Pick a development methodology.
> There's no proof it works. So it seems odd to speak only
> y of how Agile isn't proven scientifically.

Whether or not I was mixing Apples and Oranges, my intent was to not single out Agile and that's why I mentioned CMM. Pick any of the other "branded" methodologies, I would generally say the same thing: First and formost they are products.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming as Typing Posted: Jul 10, 2006 11:04 AM
Reply to this message Reply
> Whether or not I was mixing Apples and Oranges, my intent
> was to not single out Agile and that's why I mentioned
> CMM. Pick any of the other "branded" methodologies, I
> would generally say the same thing: First and formost they
> are products.

I looked back at the posts and I think I got off track. This was the comment that seems strange to me and was Isaac's, not yours:

"However you may be greeted with dogma and denial if you suggest that there should be experiments which demonstrate the effectiveness of Agile."

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

experiments & dogma Posted: Jul 10, 2006 11:26 AM
Reply to this message Reply
James Watson wrote
> I looked back at the posts and I think I got off track.
> This was the comment that seems strange to me and was
> s Isaac's, not yours:
>
> "However you may be greeted with dogma and denial if you
> suggest that there should be experiments which demonstrate
> the effectiveness of Agile."

And that was said in the context of Bruce Eckel's comment what the agilists are doing is a perfect analogy to the discovery of the scientific method... And if the experiment denies the arguments you've used in the past, you can't discard the results of the experiment. You have to change something about your argument.


I'm probably misunderstanding what you meant by Pick a development methodology. There's no proof it works. So it seems odd to speak only of how Agile isn't proven scientifically.

It seems like you're saying we (as an industry) have adopted all manner of techniques and methods in the past without demonstration that they actually improved on what was being done - so why try to do any better now?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: experiments & dogma Posted: Jul 10, 2006 11:55 AM
Reply to this message Reply
> James Watson wrote
> > I looked back at the posts and I think I got off track.
> > This was the comment that seems strange to me and was
> > s Isaac's, not yours:
> >
> > "However you may be greeted with dogma and denial if
> you
> > suggest that there should be experiments which
> demonstrate
> > the effectiveness of Agile."
>
> And that was said in the context of Bruce Eckel's comment
> what the agilists are doing is a perfect analogy to the
> discovery of the scientific method... And if the
> experiment denies the arguments you've used in the past,
> you can't discard the results of the experiment. You have
> to change something about your argument.

>
>
> I'm probably misunderstanding what you meant by Pick a
> development methodology. There's no proof it works. So it
> seems odd to speak only of how Agile isn't proven
> scientifically.

>
> It seems like you're saying we (as an industry) have
> adopted all manner of techniques and methods in the past
> without demonstration that they actually improved on what
> was being done - so why try to do any better now?

I think I've just read too much into the posts. I guess my point is that if you are going to reject one methodology (and I realize now that's not what you are doing) because it's not scientifically proven to work, you've got to reject them all. I don't know of many eperienced developers/managers who are ready to say "let's go back to having no process."

The scientific method is great and it has served humanity very well but I think we need to be careful about trying to apply it to all things. I can't prove to you scientifically that an Abrams tank is a superior military technology to the phalanx but it would be pretty absurd to say we don't know that it is because there is no emprical data on tank vs. phalanx battles. There are lots of things in life that are difficult if not impossible to qunatify and it's extremely dangerous to ignore or disregard things that cannot be proven scientifically.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: experiments & dogma Posted: Jul 10, 2006 2:24 PM
Reply to this message Reply
>I guess
> my point is that if you are going to reject one
> methodology (and I realize now that's not what you are
> doing) because it's not scientifically proven to work,
> you've got to reject them all.

Well, it would be equally logical to claim that if you're going to reject one methodology because there is anecdotal evidence against it, that you have to reject them all.

I think you have to weigh all the evidence of any type for/against each methodology and determine its relevance to the application you intend to build with it.


>I don't know of many
> experienced developers/managers who are ready to >say "let's go back to having no process."

I guess by process you mean "formal process" as opposed to ad hoc. It hasn't escaped my attention that a lot of great and successful software has been developed without a formal process. I think enough software is still developed that way that it may be more of a question of "going forward" to a formal process rather than retreating from it.

Managers in particular like a formal process because it makes them feel like they are in control.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: experiments & dogma Posted: Jul 11, 2006 7:07 AM
Reply to this message Reply
> >I guess
> > my point is that if you are going to reject one
> > methodology (and I realize now that's not what you are
> > doing) because it's not scientifically proven to work,
> > you've got to reject them all.
>
> Well, it would be equally logical to claim that if you're
> going to reject one methodology because there is anecdotal
> evidence against it, that you have to reject them all.

Yes. Of course.

> I think you have to weigh all the evidence of any type
> for/against each methodology and determine its relevance
> to the application you intend to build with it.

You can also use logic. Someone made some comments about how the ancient Greeks didn't bother to test thier theories, implying this was bad. On the other hand, the ancient Greeks came up with some pretty good stuff this way too: math and philosophy that we still learn about today.

> >I don't know of many
> > experienced developers/managers who are ready to >say
> "let's go back to having no process."
>
> I guess by process you mean "formal process" as opposed to
> ad hoc.

In your terminology, does 'formal' mean the process comes from outside the team?

> It hasn't escaped my attention that a lot of great
> and successful software has been developed without a
> formal process.

There have also been some spectacular failures. My personal experience is that it's hard to find a team that can execute without some controls.

> I think enough software is still developed
> that way that it may be more of a question of "going
> forward" to a formal process rather than retreating from
> it.

I have a hard time imagining how a team of more than several developers can create a non-trivial piece of software without any structure but perhaps that's what you mean by ad-hoc.

> Managers in particular like a formal process because it
> makes them feel like they are in control.

I can't disagree with that entirely.

Flat View: This topic has 57 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Programming as Typing Previous Topic   Next Topic Topic: Programmers Shouldn't Touch the Source

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use