
Bricks (2007) - llambda
http://weblog.raganwald.com/2007/08/bricks.html
======
nodemaker
The idea that software should be built out of building blocks (if not bricks)
is actually a good engineering approach .The problem is

1) These blocks are not of the same size or complexity

2) The relationships between these blocks also varies .All bricks in a wall
are surrounded by a fix number of other bricks, whereas some modules may have
a few dependencies and some modules may have hundreds.

3) It is often more complex than what can be pictured as a two or three
dimensional analogy.A better idea is not to think about a spatial
representation at all.

4) Although this is my opinion,I think if there are more than three people on
a project they should NEVER work on a common block.Each should have a fixed
number of independent blocks that they create and write tests for.Anyone not
competent enough to create his blocks from scratch,write tests and maintain
them does not have the minimum level of competency to participate in the
project.Highly skilled engineers of course not only create and maintain their
own blocks but also understand and learn from other's blocks.

These ideas are actually very derivative of the ideas in the book "The
mythical man month".

~~~
GFischer
The fun comes in separating the project in one-man-sized blocks (which won't
be the same size).

Indeed, you can track progress by seeing how many features are coming along,
but I believe you can't predict a delivery date accurately because of the
variance - but you can give a ballpark estimate (days, weeks, months, years,
age of the universe).

Agree with giving each developer a separate brick, but on the Kanban approach
I was recently introduced to, if someone is stuck, the idea is to "swarm" him
and help him/her.

~~~
raganwald
There’s something subtle but important your comment raises. Feature are not
bricks! The brick metaphor is about assigning chunks of implementation that
have a possibly many to many relationship with units of business value (call
them features).

Dividing up a project by feature and/or tracking progress on a project by
feature is very different from tracking project by brick.

~~~
GFischer
Sorry, what I had in mind was the Work Breakdown Structure advocated in the
"traditional" (PMI/Pmbok), and the lowest divisions as "bricks", or the agile
approach of separating a project into User Stories.

<http://en.wikipedia.org/wiki/Work_breakdown_structure>

<http://en.wikipedia.org/wiki/User_story>

It's not what you were talking about.

Your points at the end of the article are pretty similar to what I was taught
in a short agile project management seminar this week, if it helps :)

------
SteveJS
This is mostly spot on. But I believe there is a part about decreasing
parallelism that is subtly wrong. The posts specific arguments against
parallelism seem to imply the optimal way to create shared understanding is to
locate it in a single head.

The issue with trite parallelism is that it creates priority inversion. The
critical resource is the devs who understand the problem and the code. Trite
parallelism merely occupies all the devs who understand with the task of
teaching new people, thus prevents progress on diagnosing existing problems.
It is however important to know that increasing the number of devs who
understand an area is a postive. With increased understanding of an area, new
ways to partition work can be discovered or created. Reducing the latency to
correctly triage outstanding bugs is also important for re-scoping, which is
somewhat more powerful than merely re-estimating.

