Code Complete Chapters 1 - 3

I have been reading code complete by Steve Mcconnell with a good friend, Pete Gordon. This week we discussed chapters 1 through 3, and these were our primary points of interest.

What is "integration" in software construction?
Integration can mean a wide variety of things - it can be synonymous with any coding activity. It depends on what level of integration you're talking about.
Integration with a database or some external system?
...with another class that another developer wrote? 
...with a set of abstract classes?
...with another developer who is using code that you wrote?
...with code that was existing in the class that you are working with?

"Construction is a large part of software development"
It's a relative statement! After reading what he said about construction being a large part of the project - we looked at it from the opposite perspective. "Construction can be a relatively small part of the project". The book states that construction is usually between 30 and 80 percent of the total time spent on the project. Turn that around and you can say that 20 to 70 percent of the project is not construction! Interesting to think of it that way. Pete came up with a great concrete example:
Building a house is probably going to be about 10 percent design and 90 percent construction. Less time will be spent on design if you're using a canned blueprint/design. Now think about the St. Louis gateway arch. I think we can assume that a much greater time was spent designing the arch than was spent constructing it. Nothing is ever cut and dried in software development! Critical/creative thinking is required every step of the way!! 

Software Metaphors
Accretion vs. growing vs. building. How do you see a software development project? Which one is better? The author suggests that the visualization of building software is the best - I tend to agree with this. It also lends itself to being better able to serve your client. You need to continually be showing progress - by building out complete subsystems of the project you can show your customer progress that's been made after every chunk of effort.

The intellectual toolbox
Why do we need to be so religious about our development methodology? I have learned to be skeptical of someone who says they are strict in their approach to development by saying "I think xyz is the best way to develop software". Why hole yourself into a concrete implementation of a process? I think you need to be abstract in your approach to development and know what tools are available to you. This way you can adapt yourself and your team to changing circumstances.
How do you know what methodology to use?
I think to answer this question you have to ask what is most important to the project owners - both client and vendor. How easy is it to communicate to your client? If you sit on the opposite end of a desk, then maybe XP is great for you because you always have input and insight into how the system is to be built. If your client is halfway across the world and you have a weekly meeting to discuss requirements, then maybe you need to take a different approach with more documentation. I'm still trying to figure out how to think about this topic.

Trust
Something that Pete and I have been discussing almost every time we meet is the value of trust in your relationship with a client. When you come down to it I don't think a software project can be successful without a high level of trust.

Practices for your particular type of software project
We noted that the evolutionary model was acceptable for each of the three types of projects mentioned in the book. What I learned was that the evolutionary model takes two extremes (XP and waterfall) and tries to find balance in the middle. This brought up more discussion on how methodologies are really just semantics...you're always going to have to use critical/creative thinking in your processes..and be guided by a higher level process "ideal". I think that the reason that some projects leaders try to keep process rigid and stiff is because some people on the team will not be flexible and they need a definitive path.

What you need to start coding
The book suggests checklists to use before you start coding. One is requirements and one is design/architecture. I like the checklist because it's good to remember that there is a checklist. Folks who are not familiar with what it takes to construct code don't understand this and why you need to wait to start coding.

Justifying design and architecture
I really like the points that he makes about justifying your design decisions. One way that I learn the most is by analyzing design and picking out pieces I like and ones I don't. If you see enough designs you have a lot easier time coming up with one that meets your unique needs. Justifying your design also helps developers to understand your decisions - and will help pull them into the mold of your design. If developers are forced into a design they don't fully understand or grok, then they will probably make wrong decisions when they hit an edge case where a particular feature or design consideration is outside of what you've accounted for.

Conclusion
After reading the first three chapters of this book it is easy to see why it is considered legendary in so many circles. It is foundational to all software projects and I think that everyone involved in software should read and understand each key point that he brings up in this book. Great stuff - can't wait for more!