Article For Thought

Ken Snyder kendsnyder at gmail.com
Thu Dec 20 11:13:27 MST 2007


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.
>> */
>>
>>     
>
>
>
>   




More information about the PLUG mailing list