Article For Thought

Kurt Griffiths kurt.griffiths at gmail.com
Thu Dec 20 17:43:32 MST 2007


One great advantage of modular programs (and really, any system
or product) is that you can offload the development and maintenance to other
people (preferably competent ones). You have to be careful with this,
however, because the more tightly coupled you are to other people's work,
the more communication overhead you will have. This can be mitigated
somewhat via good interface design, or simply making sure you are only
loosely coupled with 3rd party code.

With that in mind, there is no denying that the overall complexity (and,
therefore, tendency toward code entropy) goes up the bigger you system gets.
Although languages like Ruby can certainly reduce the amount of lines you
write, the lack of really great tool support means you reach the point of
unmanageability (is that a word?) faster (I am reaching that point right now
with a Rails app at work).

What you need is a healthy mix of a good language, best practices and good
tools. Will it blend? <http://www.youtube.com/watch?v=qg1ckCkm8YI>

On Dec 20, 2007 11:13 AM, Ken Snyder <kendsnyder at gmail.com> wrote:

> Kurt, I completely agree.  After reading the whole article, I find that
> his argument that large codebases are /inherently/ bad is a weak one.
> I'd like to comment on two of his major points: a) Large codebases are
> *unmanageable*, even by IDEs and b) Large codebases are *hard to learn*,
> remember, maintain, and extend.  Steve is pushing a very good concept
> here: Parsimony (extreme frugality).  It is one of the 17 rules of Unix
> Philosophy
> (
> http://software-quality.blogspot.com/2005/12/basics-of-unix-philosophy.html
> ).
> However, it seems like he is missing some key design patterns as you
> mention, Kurt.
>
> a) Large codebases don't need to be unmanageable. They should be
> composed of lots of small codebases--tool kits, frameworks,
> sub-applications and what not.  The trick is to make each part a simple
> /part/.  The whole may be complex, but enhancing a modular codebase will
> require additions of and changes to a small number of simple parts.
> Loading huge codebases into Eclipse is silly; load a small portion of
> the codebase instead.
>
> b) Large codebases don't need to be hard to learn.  A good codebase will
> have searchable documentation that is auto generated.  It should require
> learning a small subset of the modules and functions by eliminating the
> need to manage low-level operations and following the principle of least
> surprise.  Consider a database connector.  The main things developers
> need to learn are functions like connect(), query(), beginTransaction(),
> rollbackTransaction() and commitTransaction().  It is easy to remember
> because the method names are intuitive.  The database connector probably
> has dozens or even hundreds of files to manage drivers, connections and
> compatibility, but editing those files is unnecessary--the database
> connector can be a separate module that never is loaded into Eclipse at
> all.
>
> - Ken Snyder
>
>
> Kurt Griffiths wrote:
> > If you are trying to reduce the size of your code base and switching
> > languages simply isn't an option (for one reason or another), there are
> > several other areas you can focus on that can really help:
> >
> > 1. DRY
> > 2. Relying on operating system services/libraries
> > 3. Using 3rd-party components
> > 4. Using code generation and/or an embedded scripting language
> > 5. Supporting plug-ins and templates
> > 6. Choosing smart DAL and UI frameworks that don't require a lot of
> > boilerplate code
> >
> > On Dec 19, 2007 10:44 AM, Nathan Blackham <kemotaha at gmail.com> wrote:
> >
> >
> >> This article was mentioned in the IRC channel.  Remember that he is
> >> describing a problem that can exist in any language.  He isn't bashing
> a
> >> given language other than to get his point across.  I am not a big
> >> programmer, but I can understand his argument and is something I think
> >> every
> >> programmer should look at and examine if they fall into the big code
> base
> >> trap.
> >>
> >> Without futher ado:
> >> http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html
> >>
> >> Later,
> >> Nathan
> >>
> >> /*
> >> PLUG: http://plug.org, #utah on irc.freenode.net
> >> Unsubscribe: http://plug.org/mailman/options/plug
> >> Don't fear the penguin.
> >> */
> >>
> >>
> >
> >
> >
> >
>
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
>



-- 
Kurt



More information about the PLUG mailing list