4. Aristocracy, democracy and system design

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

This chapter is about the impact that easiness of use and project scale, impact on the system design and the teams’ organisation. Continue reading “4. Aristocracy, democracy and system design”

Advertisements

3. The surgical team

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

I guess most of us feel that small experienced teams are far more productive per developer than large teams with dozens or even hundreds of developers…

But how can we build a huge project with just a small team…?! No matter how good the developers would be, it would take forever…

The dilemma is a cruel one. For efficiency and conceptual integrity, one prefers a few good minds doing design and construction. Yet for large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance. How can these two needs be reconciled?

The mythical man-month pg. 31

Continue reading “3. The surgical team”

2. The mythical man-month

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

In this second chapter, we go through the projects time and effort estimations, their problems and possible solutions. Continue reading “2. The mythical man-month”

1. The tar pit

This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.

“The mythical man-month” is a historical, emblematic and seminal book about management of software development projects. It was first published in December 1st 1974, but republished 20 years later, in 1995, with four extra chapters. Despite having been written so long ago, it is still today a reference and a worthwhile reading, with the due context adjustments.

The author, Frederick P. Brooks has been involved in the development of some of the most important and emblematic early electronic computers and has been awarded countless times throughout his career, including the Turing Award, generally recognized as the highest distinction in computer science and the “Nobel Prize of computing”.

This is the first chapter, and Frederick P. Brooks starts off by identifying the craft of system programming and the joys and woes inherent in it. Continue reading “1. The tar pit”

Architecture 1st design step: Partitioning

There are many ways of partitioning an application. Usually, what we do is actually classify the code according to some criteria and organise the code following that criteria.

This chapter of the book explores four criteria:

  • Functionality vs. Domain;
  • Conway’s Law;
  • Geographic constraints;
  • Cultural concerns.

All in all, the idea is that we partition our codebase with long-term local autonomy in mind, according to history, standards and conventions, experience and common sense (Coplien 2010, p.91).

Continue reading “Architecture 1st design step: Partitioning”

What is Lean and Agile about Software Architecture

Good Software Architecture embodies several Lean and Agile principles, always with the same goal of long-term productivity and lightweight feature development.

Delaying structural decisions will outcome in undisciplined structure, which in turn outcomes in waste. Therefore we must think of Software Architecture as an investment that we need to make now to get medium and long term gain.

Continue reading “What is Lean and Agile about Software Architecture”