On 19 May 2002, Oleg Goldshmidt wrote:
> Shlomi Fish <shlomif@...> writes:
> > 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.
> 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?
The ironic thing is that it does not necessarily take me less time. It's
just the first thing that comes to my mind.
> 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.
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
> 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.
> > 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.
> 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.
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.
> > 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...
> > Most of the code I write now is not mission-critical and I can always
> > 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.
I don't usually re-write the whole thing from scratch. Parts of it - yes,
but not the entire codebase.
> > 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
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. ;-)
> Oleg Goldshmidt | ogoldshmidt@...
> "We work by wit, and not by witchcraft,
> And wit depends on dilatory time..."
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Shlomi Fish shlomif@...
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@...
"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"