Subject: Consciously Writing Bad Code

From: Shlomi Fish <[email-masked]>
Date: Sun, 19 May 2002 12:12:53 +0300 (IDT)

Sometimes when I write new code, I consciously decide to write it in
a sub-optimal way. I know how it can be more modular, but I don't write it
that way. I'm just too anxious to get a working version, so I follow the
path of least resistance.

Later on, I either keep it that way (until I find a very good reason to
refactor it) or re-organize it so it will be more modular. Does it happen
to you too?

Some software engineering paradigms (most notably Extreme Programming)
claim a code need not be much more modular than it should be to accomodate
for all of its features. Even if you think two steps ahead, you'll
eventually need to advance for three and more. But still, crude
workarounds should be avoided, anyway you look at it.

Most of the code I write now is not mission-critical and I can always
re-factor it later. So the question is whether when I program for a
living, I should make sure I have more discipline and write the code well
in the first place.

Regards,

	Shlomi Fish

----------------------------------------------------------------------
Shlomi Fish        [email-masked]
Home Page:         http://t2.technion.ac.il/~shlomif/
Home E-mail:       [email-masked]

"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"

---

From: Oleg Goldshmidt <[email-masked]>
Date: 19 May 2002 12:52:36 +0300

> path of least resistance.

Why does it take you less time to produce "suboptimal" (from the
design point of view) code than "good" code? Hint: can it be because
you don't train yourself to write non-critical or even throw-away code
well?  Maybe if you get into the habit it will be natural and fast?

Consider this: for relatively small programs (and no big program can
be considered non-critical or throw-away) figuring out a reasonably
good design and modularization is a correspondingly small effort given
a bit of knowledge, skill and experience. The overhead, if any, will
likely be smaller than the time and effort you will invest in
refactoring or rewriting times the probability you will refactor.

For large projects, investing in proper design is an absolute
necessity, of course.

> Does it happen to you too?

No. Habit. This is not to say I never refactor. This means that when I
do refactor it is because I missed something in the original
design. That does happen to me.

> for all of its features. 

I am not sure I understand the statement. It sounds like
"overengineering is bad," which is sensible. On a more general note,
it seems to me that the useful elements of extreme programming are
sensible but not original.

> Even if you think two steps ahead, you'll eventually need to advance
> for three and more.

Always true. But the thought you put into the first two steps will
make the third step so much less painful...

> re-factor it later. 

Man, you have a lot of time on your hands! I am absolutely sure
neither myself nor my team of developers nor any other team at the
company will have the resources to rewrite badly written code. Ever.

> So the question is whether when I program for a living, I should
> make sure I have more discipline and write the code well in the
> first place.

Let me know what you decide. On the basis of that I'll decide whether
I will ever agree to maintain your code. Or hire you, for that
matter...

;-)

-- 
Oleg Goldshmidt | [email-masked] 
"We work by wit, and not by witchcraft,
 And wit depends on dilatory time..."

---

From: Shlomi Fish <[email-masked]>
Date: Sun, 19 May 2002 16:20:56 +0300 (IDT)

> well?  Maybe if you get into the habit it will be natural and fast?

The ironic thing is that it does not necessarily take me less time. It's
just the first thing that comes to my mind.

> refactoring or rewriting times the probability you will refactor.

It's not that I don't design or modularize. I just know that the code
could have been written in a better way from the time I started writing
it.

> sensible but not original.

Actually it does mean that "overengineering is bad". A code can never be
too modular. But then again, you have to stop somewhere if you want to get
a working one.

> make the third step so much less painful...

Right.

> company will have the resources to rewrite badly written code. Ever.

I don't usually re-write the whole thing from scratch. Parts of it - yes,
but not the entire codebase.

> I will ever agree to maintain your code. Or hire you, for that

Like I said, I don't usually leave my code in the bad state that I may
have written it in. But sometimes I say to myself "the best way to do it
is by following path A, but I'll follow path B".

And even my bad code is relatively good. ;-)

Regards,

	Shlomi Fish

> To unsubscribe from this group, send an email to:
> [email-masked]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>