The Design of Design : New book from Fred Brooks

Some time back I blogged about the 'Mythical Man month'. Recently I have started reading the new book from Fred Brooks.' The Design of Design'. Like Mythical Manmonth this book is also a collection of essays and it also a book where you read a chapter and then you need to think and reflect on the ideas/thoughts in the chapter and your own experiences before continuing to next one.

First thing that struck me about this book is Authors gives examples from diverse fields  like music, civil engineer and construction apart from Software. These examples illustrate the author's knowledge about these other fields. I am greatly impressed by the case study about design of auhor's house and kind of design notes that he kept through out the process. I wish I was this systematic.

The book is divided in 6 sections

1. Models of Designing
   So models of design talks about the 'engineer's view of design, about Water fall model and why it doesn't work and what are possibly better design models.
   
   In my 15 years of experience, I have never seen 'water fall model' work in practice. However, all the software development processes defined in software companies implicitly assume 'water fall model'. End result is developers hate 'these processes' and organization cannot get expected benefits of process implementation. Someone (I think Albert Einstein) once said that 'Insanity is doing the same thing, over and over again, but expecting different results'. By this definition, many common software development 'processes' in software companies are 'insane'.
2. Collaboration and Tele collaboration
   Now a days any significant sized project is about 'collaborating with other' for design, coding/construction, testing etc. In the world of 'outsourced software development', tele-collaboration is increasing critical. As expected, Fred provides some insights on what works and what doesn't.
3. Design Perspectives
   Talks about various 'views' about the design, user models, aesthetics, constraints, examplars (or design patterns), where things go wrong.
4. Dream system for design houses.Authors thoughts and ideas for a 'dream system' to design houses and why of those ideas
   
5. Great Designers.
   Talks a common argument that software development should be like a 'factory'. Good Product development process will produce 'good designs'. I have heard this argument many times from Software Engineering Process Groups (SEPG) in the companies, CMM and ISO style processes etc.While, Fred argues that 'Great Designs come from Great Designers'. He also goes into the depth of why we need Product processes and how to make product processes that encourage and facilitate great design. I think this is a chapters that every manager should read.
6. Case studies.

It is not possible to reviews the ideas in this book in one article. So I am hoping to write multiple articles as I assimilate ideas from this book.

set/get functions in class.

This is actually a mail trail of a question that Ashish Khare asked me. With his permission I am putting parts of the discussion in this blog entry.

The question was

I am looking at a class which has 4 ints declared as private and for each one there is 1 Get and 1 Set functions which is public.
When all these ints are exposed ( indirectly ) to external world, why should I declare them as private? I could have all the ints as public with no Get and Set functions. What do you say? Is there any advantage in the way class is existing now ( private variables with Get and Set functions )? Is there some better way of designing a class if requirement is such that you need to get and set the variables.

My answer to this question was

In effect, there is no encapsulation in class. Only place where it helps is in debugging. If value of some variable is getting changed. Then you can track where it is getting changed by putting a break point on 'set' function.

Ideally reevaluate why you need the class and especially 'get' functions. Follow the principle of 'tell, not ask'. See where and how are you using those get functions. (.e.g 'ask') and what operations are done on those values after 'get'.

Ashish replied with :

Got ur point but basically this class is related to some database records where you often need to get and set values. For example, in a optimization study some parameter can vary from 5 to 10 with an increment of 1. So in first run, I get the value ( which is 5 ). I use this value, analyze the problem and see if criteria is met or not. If this is not met, this value is increased by 1 and now it needs to be set back as some parallel tasks also need the updates value from the record. Likewise the flow continues. I guess, in this case, I can't get away from get and set calls ( or make the variables public )!

From the words like 'I get the value ( which is 5 ). I use this value, analyze the problem and see if criteria is met or not. ' one can say that the design is in 'ASK mode' rather than 'TELL mode'. My reply was :

Lets look at your problem again. "So in first run, I get the value ( which is 5 ). I use this value, analyze the problem and see if criteria is met or not. ". That is ASKING. " Can put the "analyse" part(fully or partially) in a member function of your class and then call the function? That is "TELLING". Then you don't need 'get'. You can have another function "increment" to increment the current value. Then you can avoid explicit set.

Try to switch "TELL" mode than 'ASK'. Its not THAT difficult. You will find that the code generated is lot simpler to maintain and change.

From his response, I think he got the point. From my experience switching from 'ASK mode' to 'TELL Mode' is a major and important step in practicing Good OOD. Once you switch, design, code, maintaince, etc becomes a lot easier. Try it.

PS: One of the guidelines from my Mechanics of Code Review ppts was to question the need of every 'get' function.

Martin Fowler has written one of the best articles on this subject (Data Access Routines).