Interview with Steve McConnell

In this interview with Steve McConnell he shares some sobering thoughts on software development. I found item 3 of particular interest, there he talks about recurring problems in software development (for the last decades):

• Code and fix practice
• How much design up-front should be done
• Trying to anticipate future functionality
• Silver bullets to increase productivity (tooling e.g.)
• Uninformed use of software development practices
  

Code Complete 2: Design in construction

I downloaded chapter 5 in the new version of the famous Code Complete. It had many good point, amongst which I found the following most interesting:

• "Once you understand that all other technical goals in software are secondary to managing complexity, many design considerations become straightforward."
• Abstractions and encapsulations are just sub-themes to managing complexity.
• We need to manage complexity because our brain capacity is limited: "Hiding complexity so that your brain doesn't have to deal with it unless you're specifically concerned with it."
• Two reasons why we hide details: to hide complexity and to hide sources of change.
• "A study of great designers found that one attribute they had in common was their ability to anticipate change."
• "One of the most effective guidelines is not to get stuck on a single approach [in design]."
• Reviews: "If the goal is quality assurance, I tend to recommend the most structured review practice, formal inspections ... But if the goal is to foster creativity and to increase the number of design alternative generated, not just to find errors, less structured approaches work better."
• "Design is a wicked problem ... a wicked problem [is] one that could be clearly defined only by solving it, or solving part of it".

I have to mention that I found the reading of the chapter rather boring though, it is too wordy, as is often the case with North American technical literature.

UML diagrams

I find that I usually only use 3 types of UML diagrams: the class diagram, the sequence diagram, and the activity diagram. Perhaps this is so because it is often almost as easy to describe other parts of the design in words as it is with diagrams, as, e.g., for components and deployment. Or perhaps it is just that sometimes the UML standard intimidates me: I feel that I am serving it rather then it is serving me :|

P.s.
A fine summary of UML 2.0 diagrams is maintained by Scott Ambler.

Object Oriented defined

I was once asked in a job interview to explain what object oriented meant, I was a bit taken by surprise and I don't think that I gave a good answer (at least I did not get hired ;). I have been thinking about it since. I like to distill things rather than listing everything that comes to mind, like I feel that Americans tend to do, and my distilled version of what OO is is:

• Object oriented programming/design is class inheritance coupled with class data encapsulation.
  

Here I deliberately omit the following concepts: "polymorphism" (included in inheritance), public/private/protected visibility constraints (implementation of data encapsulation), abstract classes (sub theme of inheritance), interface (actually interfaces are rather a super theme to OO), classes (assumed known that classes are composed of data and function definitions), objects (instances of classes).

In distilling I think it is important not to over-generalize or become too metaphysical, but focus on what are the primary concepts and which are derived or auxiliary.