Software Engineering discussion
Code Complete
>
Managing Construction
date
newest »
newest »
I liked the sections in this chapter on "human issues", because it seemed fresh compared to the Configuration Management and Estimation/Metrics sections. Both were presented well and had quality content.I did a double-take when I read the "Religious Issues" headline. Then I laughed when I read the bullet points below it. "Additional Resources on Programmers as Human Beings" was a funny section title too.
I like the Key Points at the end of each chapter in this book too. My "for fun" reading retention is terrible and the Key Points review is welcome.
Encouraging Good Coding. Considerations in Setting Standards advice sounds good. Techniques for Encouraging Good Coding also sound good but not very feasible in small organization. Setting standards and providing good examples like in previous chapters of this book may work as well.Configuration Management. I’ve learned the benefits of SCM when I started my job few years ago. Since then I’m trying to organize my own things using the configuration management principles, though I’ve never used any dedicated software for it. For source control I’ve used centralized system. I’ve played with distributed system, though I don’t really completely understand all the benefits of using it since the only I was the only person using it…
Measurement. Unfortunately we don’t do too much measurement at work, so I don’t have much experience with it. I think it would be very boring to do something like that on my coding at home. The only kind of measurement that interests me is code complexity.
Treating Programmers as People. This is most interesting discussion in this chapter. I like to think that if I ever have my own team I would promote as much freedom in creating software as possible. Though I also realize that senior staff have different priorities than junior engineers
On configuration management, I recently started to use SCM on projects that I do by myself, and wonder why I didn't do it sooner.
On estimation, I agree with the point that it the initial estimation isn't as critical as managing the project with the resources at hand to meet the goal. I have yet to see a project take less time and resource than originally estimated. And, things change. Agile methods embrace, rather than fight, this change.
On measurement, I used to push back on software metric efforts because they were always imperfect, but now I favor the view that imperfect metrics are better than no metrics. However, beware of the unintended consequences. For example, if you measure the number of lines of code each developer writes per year, you are going to get lots of lines of code, but they might not be good and essential lines.
On physical environment, I wonder if anyone has studied the productivity differences between developers who have offices vs. cubicles vs. work at home?
On managing, although I think that the general approach of trying to sell standard programming conventions and processes to developers (especially experienced ones) rather then imposing them is the right one, there is a WHOLE lot more to this topic!