Today, I would like to
dedicate my post to the management side of the software development
process, and especially to the team organization laws.
I was inspired by a post on
an IT specialized website which I follow. I was impressed about the
usefullness of these laws and the concise flow of the presentation.
At the end of the artile, the source was mentioned, a book in
progress by Alan Kelly, entitled: "Xanpan book 2: The means of
production".
I find the way these laws
are presented very nice and tidy, so I thought that sharing this, or
at least backing this up as a later "Must read" for myself
is a very good idea.
Instead of copying what is
mentioned in the article, or in the book (which you can read online
for free, at least at the time of this post creation), I thought it
would be nice to have it in a format like this:
- Law name
- Statement
- Source (wikipedia)
- Optional short explanation/example
So, you can find below a
very concise presentation of these laws.
Also, if you want more info
on the topic, feel free to access links below the post.
Basic Laws of
constructing development teams:
1. Brooks'law:claim
about software project management according to which "adding
manpower to a late software project makes it later".
2. Conway's law:
organizations which design systems ... are constrained to produce
designs which are copies of the communication structures of these
organizations
3. Dunbar's number:
is a suggested cognitive limit to the number of people with whom one
can maintain stable social relationships (150 max).
Proponents assert that
numbers larger than this generally require more restrictive rules,
laws, and enforced norms to maintain a stable, cohesive group.
4. Miller's law, 7 +- 2:
the number of objects an average human can hold in working memory
is 7 ± 2.
Practical example: It is
recommended that a Scrum team match the number 7+-2. Teams with more
than 9 people create too many coordination problems.
This rule does not include
Scrum master and Product Owner, except if they are not included in
the sprint to reduce delay.
5. Parkinson's law:
the work expands so as to fill the time available for its completion.
Practical example: a
sufficiently large bureaucracy will generate enough internal work to
keep itself 'busy' and so justify its continued existence without
commensurate output.
6. Hofstadter's law:
It always takes longer than you expect, even when you take into
account Hofstadter's Law.
Practical example:
difficulty of accurately estimating the time it will take to complete
tasks of substantial complexity. You might estimate more than you
think, and even this might not be enough
7. Kelly's first law of
Project Complexity: Project scope will always increase in
proportion to resources
Concise example: Putting
more people to work will have an inverse effect on the results and
more probably not fulfill expectations.
8. Kelly's second law of
Project Complexity: Inside every large project there is a small
one struggling to get out
Explanation: If you have a
project with lots of resources, the original project will get lost
inside of it.
9. Gall's law:
Complex working system is always created from simple working systems.
A complex system built from scratch will never work.
Explanation: Start the
project small, and grow up gradually.
Interesting fact: If you by
mistake (as I did) search instead of Gall's law, Hall's law, you
will, very likely end up reading this Wikipedia
article.
Strange as it might seem,
but one might find a tight connection between Gall's law and what
this inventor John Hall did, not counting the coincidence in First
Name!
Sources: