[Haskell-cafe] Recognizing projects schemes

Ben Franksen ben.franksen at online.de
Sun Jun 14 22:23:44 UTC 2015

Ruben Astudillo wrote:
> I recently came across the following blog-post:
> http://blog.cleancoder.com/uncle-bob/2015/04/15/DoesOrganizationMatter.html
> It speaks a bit of simplicity, efficiency and stuff that isn't
> important. What is important at least to me was the concept of
> project scheme, summarized on the following phrase:
> ``And so this gets to the crux of the question that you were really
> asking. You were asking whether the time required to learn the
> organization scheme of the system is worth the bother. Learning
> that organization scheme is hard. Becoming proficient at reading
> and changing the code within that scheme take time, effort, and
> practice. And that can feel like a waste when you compare it to
> how simple life was when you only had 100 lines of code.''
> And that is something I totally struggle at approaching new
> projects. The only reason I could understand XMonad for example is
> because they gave a general overview (thanks) of it on the
> Developing module.
> I feel I got a problem of methodology.  What approaches are you
> guys using to understanding new projects schemes on a efficient
> manner? How long it usually takes you?. Any advices? Thanks in
> advance.

I find it very difficult to understand large projects and I very well know 
the feeling of being overwhelmed with masses of detail. One way that often 
worked for me is to just start hacking. Find something that bothers you, a 
lacking feature, or some badly written piece of code you think should be re-
factored, anything that gets you motivated. Start with a small change 
somewhere, then see what breaks. This lets you explore at least the parts 
that are somehow related to the change. It helps if there is a comprehensive 
test suite.

After a while, when you feel more confident, change something deep at the 
bottom, preferably so that it requires tedious work in many dependent 
modules to make the whole thing compile again. This gets you in contact with 
large parts of the system and has always been a great help to understand the 
whole because now and then you do have to think about what you do (not 
everything will always work if it compiles and in Haskell even getting 
things to compile can be a challenge).

"Make it so they have to reboot after every typo." ― Scott Adams

More information about the Haskell-Cafe mailing list