Comments to my post about good vs. bad code

I’m glad to see that my post Good vs. bad code has received some attention. First, Edward Bilodeau comments:

The above quote just needs [deleting the sentence “Because software can’t be planned”]. Planning is a critical part of all development (i.e. determining objectives, users, requirements, design, etc), and to suggest otherwise is misleading.

And, later, in the comments to his post, he adds:

This statement [I think he refers to a quote from a Tim Bray post also in the comments: “This work has reinforced my conviction that you never really understand the problem until you’ve written some of the code.”] is a strong support for an interative [sic!] development model over the waterfall model. It is generally accepted that (a) planning is essential, and (b) there are some things that you will only understand once you try to work with your planning deliverable. This is true at all levels of the development process.

For example, you will probably need to refine your objectives as you begin to work on your requirements. Similarly, you will learn more about your requirements as you try to use them to design the site. Implementing the design will also reveal shortcoming [sic!] and new understandings that will cause you to rework your design.

Just because your downstream activities will cause you to revisit upstream planning activities does not mean that you should abandon those upstream activities. [Emphasis mine.] You just have to build that reality into your process.

Mentor Cana follows up on Ed’s comments:

I definitely agree with Ed’s observation. Planning is an important and indispensable part of any software or application development. Without proper planning, the software will perhaps be much more far away from its target functionality. Even the phrase “target functionality” is very fluid [emphasis mine] as it almost always changes during the cycle…. Or, should I better say the planned functionality ought to change if one is to produce quality software.

Perhaps it is this concept of the “moving target” always in flux that Tesugen has in mind when stating that “Good software adapts, and for adaptations to take place gracefully, the code must be susceptible to changes”. So, if by “Because software can’t be planned” it is meant to say that the initial plan is never modified, than [sic!] it is justifiable to say that software can not be planned. Indeed, such planning that does not modify itself throughout the process of software development from inception, to functional requirements, [etc.], is no plan at all because it wrongly assumes it knows all there is to know about the final software product [emphasis mine]. In most instances this is not true. To act otherwise leads to bad software functionality.

Here, he points to and quotes from an old post of his, titled Adaptive Structuration and Information Use in Distributed Organizations. Adaptive structuration theory seems interesting. Anyway, Mentor continues:

[A]nother statement is a bit puzzling: “But with some apps, you just know that they are well written. Those apps speak their quality loudly. They are coherent, they have integrity, their UIs make perfect sense, they behave as you expect, and so on.”

The above quote insinuates some sort of a correlation between bad/clean code and software/apps behavior. From personal experience I know this is not necessarily true. A particular code can be neat and clean, and yet does not behave as expected. Of course, the emphasis here is on “as expected”. [Emphasis mine.] I think that the correlation of expected behavior is stronger and more relevant with the systems (functional) requirements and design documentation.

I’ll get back to this later.

The above was posted to my personal weblog on September 5, 2003. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)