Tip:
Highlight text to annotate it
X
Let' s get them. First vote up there, ready, set vote. Oh
yeah, lots of colors, so talk this one over. Let' s try and vote
again. Ready, set voters pairs go. Wow, that converged, all
right, working magic. Let' s go over them. The closest to plan
and document scheduling and monitoring are Agile points and
velocity. Yep. Agile is used in retrospective. What' s the
experience of your team and assigning points and how fast you
use them to predict the future? Yep, as opposed to in advance,
making schedule. That' s a big difference. The closest to the
software requirements spec in plan and document is Agile user
stories. Yes, those little tiny 3 x 5 cards are your written
documentation specs that you work with the customer and that' s
opposed to 100- page book or hundreds of pages book and an IEEE
standard. Agile has no equivalent to ensuring requirements such
as traceability. Yes, that' s what the BDD is. BDD gets the
requirements into user stories and we' ll see shortly that we
can take those 3 x 5 cards and turn them into acceptance tests.
We' re going directly from the customer get them writing cards,
what the features we want, implement them [ inaudible00: 13:43].
That' s the acceptance test, where make sure those features are
there where it' s not part of plan and documents, so they have
these traceability' s tools to try and make sure you do that.
Actually four and three or faults, but that would have been kind
of clever. Questions about this? Questions? Good. All right, so
that' s what this alternative order of the universe looks like.
When you guys make these comments, " Oh, I know how software is
really built." Okay, yeah, there' s another way to build
software. This is in the only way. It' s got positives and if I
was doing space shuttle stuff I' d probably use the plan and
document with all that stuff, but not for a lot of things. Let'
s go ahead and will have time to do one more segment about
comments. This is again another thing about writing beautiful
code. What' s interesting is two my good friends are Armando Fox
and John Ousterhout. John Ousterhout used to be a faculty member
here, one of the best programmers I' ve ever met. He and Armando
just do not agree about comments in general Armando believes in
self- documenting code and Ousterhout thinks that' s evil. Self-
document code is evil. Let me go over Ousterhout' s advice and
we' ll talk a little bit about where they agree, where they
agree. Examples of bad comments, which they both agree on this.
Here' s a good useful comment. Add one to i. Well, thanks I' m
glad you didn' t not comment. Without that comment, I don' t
know what I would have figured out, okay. Here' s another one.
Lock against concurrent access. Spinlock detects. Yeah, that' s...
Your writing down what it does. This function swaps panels void
swap panels, panel 1, panel 2. Great. Thank you for doing that.
What the idea is for good comments and Armando would agree these
comments aren' t that good. What Ousterhout says what' s missing
is the reason why you did it. What' s the motivation? Don' t
write comments about what it is. Put in the why. You can' t
figure that out from the code, the why, that you did that. That
should be here. You want to the comments at a higher level, so
that if you change; when you change the code, which you
ultimately will have to do, it doesn' t break the comments.
Here' s an example. If we' re going to be scanning an array to
see if the symbol exists, do it that way, rather than basic kind
of implement the code in comments. This is a much better
comment [ inaudible00: 16:12] doing it. What' s tough about
comments is there is not lots of good examples. Open source has
terrible comments. If that' s your example, it' s rare that you
see good comments in this. In Ousterhout code, there' s as many
comments as there are lines of code, there. That really helps
it. I think Armando agrees with the why part of this, that
writing down why is a good thing. He' d like to believe with the
elegance of Ruby and good variable names and stuff like that.
The code can be understandable without the comments. He would
agree that you can' t capture the why in there. One of the big
things about the legacy code when you' re trying to figure out
what' s going on is typically that there' s no comments. They
may want to try and work on that. When I talked to my friend
Ousterhout, and I think he agrees with this point. What I really
love about this course is virtually every time we tell you a
good idea. There' s a tool that implements that. Good idea. What
about ABC complexity? We got Flog for that. How about Cyclomatic
complexity? That' s Seguro or Smells. Oh, that' s Reek. Good
comments. We don' t have a tool. The problem with that, if there
was a natural language understanding tool that would say this is
a pretty good comment, that would be useful. What I like about
the course is the advice we give you. You can follow and we can
see if you follow the advisors tool to do that. With comments,
somebody has to read through the code to see if you' re writing
good comments and that' s not a scalable, so he can make the
classes big students would like. Let me wrap this up. We started
off with giving advice on how to write beautiful code and SOFA:
short, do one thing, few arguments and consistent abstraction,
so you don' t have smelly code here. These metrics will point to
areas of concern. They' re not a foolproof guarantee but they
are good indicators. Big idea, behavior different design is the
user stories and Lo- Fi user interfaces to be able to work with
the customer right now to be able to figure what they want, and
you need to do that. How to make good ones; they need to be
specific, measurable, achievable, relevant, and timeboxed,
Trackers, this useful thing to be able to calculate progress.
This other universe has the project manager. They get good pay,
but there' s a lot on the line to try and be successful. With
that, we' ll see you next time.