28: Know formal methods

No? Formal well defined methods work in formal well defined spaces. We don't. Maybe "be aware of formal methods". Sure... Know of things. That's good. If a sitaution comes up and you think it relates, we can get more info. But getting in depth (if that's the suggestion)…

27: Stop when you achieve your goal

Outcome Focused. If the book's paragraph is anything but having an outcome focus... I'll just be ... not even disappointed. Yeah... I don't expect a lot from this book. I need a better one to do this with... I think I have a "N things a BLAH should know"…

26: "Know-when" is as important as know-how

As I've been doing with these; I like to add comments before I read what the book says. If these are principles, the principle itself should give us some information... some insight. I'm also coming back to this after a month or ... something? OK... What do I think of this.…

25: CASE tools are expensive

Not... sure... what this has to do with *checks title* software development... A tool is expensive... OK... I mean... Is the emphasis on CASE tools a sign of... OK; so I don't actually know what a CASE tool is. I have a vague familiarity with the term... TO THE GOOGLES!…

24: Give software tools to good engineers

I don't like this. Right off the bat you're creating a separation between the engineers you have. There's the "good" ones and they get new shiny objects. Then there's the "not-good" ones and they have to suffer. If you don't think the engineer is good -…

23: Use tools, but be realistic

I played a lot of Dungeons and Dragons when I was in high school. It was a lot of fun. I wanted to DM. I always struggled with some elements of it. I bought a BUNCH of DM books. I had practically every 2nd edition book. Read them all. I…

22: Technique before Tools

I find that tools exist to simplify something. Either to make it easier in some fashion, or speed it up. Electronic Story Trackers make it easier to do a number of things, including modify when not physically present. Refactoring tools let us do what we know we want to do…

21: Different Languages for Different Phases

I don't like the "Langauge", but I understand it's a term we still use to refer to our different representations. As we progress in our design and implementation, we need many different representations to help us understand the system, and varying levels. Sequence, Use Case, Timing, Object, State.…