The Artima Developer Community
Sponsored Link

Programming is Gardening, not Engineering
A Conversation with Andy Hunt and Dave Thomas, Part VII
by Bill Venners
April 14, 2003

<<  Page 2 of 3  >>

Advertisement

Coding is not Mechanical

Bill Venners: You say in your book, "Conventional wisdom says that once the project is in the coding phase, the work is mostly mechanical, transcribing the design into executable statements. We think this attitude is the single biggest reason that many programs are ugly, inefficient, poorly structured, unmaintainable, just plain wrong. Coding is not mechanical." You seem to feel strongly about that.

Dave Thomas: The ultimate objective of writing software is to produce code that generates some business value. And that value is produced by writing code. It's only at the time that you write the code that you know, yes, this is actually working. Before that time, it's all theory. You can do your best to validate your designs and check your architectures, but really it's all theory until it actually runs. In the running of the code, you get the feedback that you need to know you're going in the right direction.

What happens if you don't do that? What happens if back at the design level you say, "I'm an omnipotent designer. I can produce things. I know they'll be right. These are just coding details." You are eliminating an entire level of feedback. And I think it's actually the most valuable feedback you can get, because it's the feedback that says, "This is what the program does."

Quite often you'll be programming some requirement that should be simple, but turns out to be really complicated. Why is this? Often it is because the requirement has been poorly stated or understood. You say, "Wait a minute, I don't like how this is turning out." You go back to the client and say, "You asked for this, but it is having all these ripple effects in the code. Why is this?" And the client will say, "Oh, I didn't really mean it that way. I meant it this way." The code is a mirror, a model of the reality you're actually implementing. If the code has problems, it could well be because the reality as expressed to you has problems. Simply seeing code as mechanical loses all the benefit of that feedback.

Andy Hunt: As an anecdote, on one project Dave and I were implementing legal requirements in code. These were actual laws that had been passed. We got about three quarters the way through it and realized that the law as stated was wrong. It was inconsistent. If you read through the law one way, it said something had to happen. But in the next paragraph it contradicted itself. Nobody had caught it up to that point, because nobody had tried to do a detailed implementation enacting this legal requirement. This mere mechanical act of coding actually catches bugs in the real world. If you dismiss it as just a mechanical translation, what are you going to do? You find genuine requirements problems while coding. You've got to be able to react and adapt to them.

<<  Page 2 of 3  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us