Software Best Practices

The first 22 of the 55 facts are about management in chapter 1. Almost half the book! Clearly good software management, like in anything, is important to success. Several key areas were covered, People, Tools, Estimation, Reuse and Complexity. The SDLC wasn't covered but that's in chapter 2,...

This fact supports Glass' argument that software automation, CASE tools and MDA, isn't currently feasible. There's not a lot of supporting evidence but I believe it too. The single hardest thing to do is decide precisely what to build. This would have to be done up front to automate the construction...

I couldn't agree more. And the first engineer that agrees to that ".. one little thing..." without thinking it through should be tacked to the wall right next to it. This is the central fact of the book, according to Glass. The downstream effects of small changes are so hard to foresee...

Probably so. It's so complex its extremely tough to verify. I think if any code is modified by more than 20% it should be rewritten or refactored so its unrecognizable. Really though this is a code quality issue. If the changes don't break many module interfaces a rewrite wouldn't be needed...

Coincincidently, after building 3 similar products it's beneficial to adopt a product line.

This is true because because business requirements and design decisions are also reused but only if you plan for it. The impetus of a product line approach was to reuse requirements and software for similar software products. By parameterizing the actual code base a company could support a family of...

I wish I'd have seen this too. I was deeply involved in building and maintaining a Software As Service product. I think this is another solution for reuse in-the-large, albeit indirectly. I proposed a reuse approach to our problems but had the same response as you. The business focus was on growth...

That's a great distinction. Once we know what it takes to make it happen technically then we need to decide if it makes business sense to do it. These are in business plans, marketing studies and gutsy hunches.

Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.

For every 25 percent increase in problem complexity, there is a 100% increase in the complexity of the solution. That's not a condition to try to change. That's just the way it is.