4 ms·
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 o
by nodemaker 15y ago
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 15y agoThe 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 15y agoThere’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.
- nodemaker 15y agoYes I forgot to point that out.....The blocks are not directly related to individual features....For example one block can deal with Network Requests and it can use another smaller block to cache data....One block for managing thread pools. But I guess one could create a mapping between the set of blocks and the set of features.A feature then would be complete when all its mapped blocks satisfy their test cases.But I am yet to see a project management system based on this approach.
- GFischer 15y agoSorry, 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/Work_breakdown_structure http://en.wikipedia.org/wiki/User_story 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 :)
- deleted 15y ago[deleted]