Liveblogging p&p summit, day 3, designing for performance

Yes, let's all agree that all apps must have a performance plan.

• Highest-priority scenarios - could be response times to user input, or server throughput, or other. I'm thinking data response times too.
• Articulate Bad, Good and Excellent performance - e.g., on startup 10 sec is bad, 3 sec is good, <>
• Do coarse estimation if "good performance" is in jeopardy - if uncertain, prototype and measure more; if bad, redesign.

Design design design design. "If you have a performance catastrophe - 10x, 100x from acceptable - then you either have some serious bugs or the flaw is in design. If it's in the design, then you're screwed. You cannot fix this late in the product cycle. You have to start over and redesign the app from scratch for version 2." You don't say. J.f.C.

Measure. Use real numbers. Measure early. Don't skimp on this. Performance is not free.

You cannot commit to features or designs until you know how much they cost, and to know that, you need real facts and real numbers. Use references (consults?), past experience, and experiments/prototyping to determine what things cost. You can only make rational decisions about how to build things if you know this. (I am sure this must apply to aspects of decision-making beyond just performance.)

Multi-threading. Ugh.

A symptom of blocking - you have a ton of stuff going on/waiting, but the machine's CPU is not fully utilized. This means something's hanging on some thread while the machine has idle threads to spare. Points of communication between threads will then be the bottlenecks. It's fine to share RO data between threads because each thread can keep its own hot copy.

Disk is 10,000x slower than RAM.

"The problem with caches is they only work the second time." D'oh.

("Argaments"?)

Memory is not a primary metric - time is. It only matters inasmuch as it affects time.

Takeaways:

1. Care.

2. Plan.

3. Measure.

4. Design.

5. Measure some more.

Liveblogging p&p summit, day 2, keynote

"Don't allow an unbelievable schedule to live."

Not just don't, but here's why not:

When people don't believe the schedule, it undercuts their belief in anything else you say.

When everybody "knows" you can't make the schedule, if you're not actively managing that, they'll start making their own decisions and judgments. If this is under the table, then they won't do it the way you (the manager) would want. E.g., if they "know" the ship date isn't realistic and no one is talking about that, maybe they'll speculate about how much it's going to slip, and start working to that assumption. If you (the manager) don't know what they're speculating and aren't giving realistic, believable input into that judgment, then you won't have any influence over that decision they're silently making about how to work. Yowch.

The usual solutions are to change the ship date or change the scope, to bring about a believable schedule. Both of which are the right things. I suppose there is another possibility, to convince people that the original scope & schedule should be believable, by providing lots of supporting facts and Gantt charts and suchlike. The problem here is that this is more like browbeating, most of the time. If your developers don't believe the schedule (assuming your developers are minimally competent and are at least somewhat able to explain their concerns rationally; if not, then you have a much bigger problem), chances are you should listen to them instead of trying to talk them out of it. As well, not listening to them makes all of the above outcomes worse.

"Working harder is a short-term solution." Death marches R bad, mmmkay?

Liveblogging p&p summit, day 1, more

Gratified to see that my team isn't the only one with an unhealthy fondness for layer cake metaphors (and Visios)!

"Customer doesn't care whose fault it is; they just want things to work." Good reminder for me, personally.

Got to talk to a very delightful p&p program manager/session presenter in the coffee line while a different session was going on. If I were actually any good at this "networking" thing, I would have figured out a way to snag a business card or thought of a thought-provoking question for further follow-up. Live & learn.

"When [users/developers] get a new version and have to spend all their up-front time fixing compatibility issues, they tend to not want to use your app at all." Not that Microsoft would know, of course. ;)

Much later in the day...

Experimental 15-minute "lightning sessions" debuting this year. The first one was a Program Manager discussing transition to Agile, which was disappointing because it didn't cover Agile in very much depth. In 15 minutes. I know! Really! (Ahem, kidding.)

The current "lightning session" covers a concept called Behavior-Driven Design. I love it. This is either something we are already accidentally doing, or something I wish we were doing. Either way, it seems to me that it would fit well within the methodologies we already use. Awesome.

I exercised restraint and did not "mention" the speaker, @ElegantCoder, in a tweet, even after other attendees did and his TweetDeck notifications started popping up on his presentation laptop. The temptation was tremendous.

So he uses the word "scenario" for the "given/when/then" construct describing a desired/expected behavior. We also use the word "scenario" and I'm trying to figure out whether our usage is reasonably compatible with this standard definition, or if we're abusing it. We use it to describe automatedly-testable behaviors, so it does seem to fit together, but it doesn't really describe our internal architecture, so maybe not so much.

OK, this is cool. Third lightning session on SharePoint development seemed ridiculously irrelevant to our team, but instead, here he is demoing the concept of Inversion of Control, which is perfect for some of the team members we brought along, and the examples are simple, and he's explaining the value IoC adds to the process. Hooray!

That means 2.5 out of 3 lightnings are useful so far.

Last lightning round: Billy Hollis. Always a total, major win even if he doesn't fully appreciate that there may be female coders in his audience (or in the universe) when he writes his jokes. Ahem. *dusts shoulder-chip* I'll still give him full credit for "useful". 3.5 out of four, nice work p&p.

Liveblogging p&p summit, day 1, intro & keynote

ZOMG it's Martin Fowler. Right now! I knew he'd be here, but, first! #fangrrrl

"We need to reduce our emphasis on quality so we can fit more features into the next release"? No, that's definitely never happened to me. Nope.

Attendance is way, way down compared to two years ago. Our own delegation this year is half the size (or smaller?) than ours then, and I'd really guess the overall crowd size is similarly proportioned. Which makes me wonder about last year (immediately mid-meltdown) when we couldn't attend at all. Don't know if it is valid to think of us as a bellwether.

Lord, this clacky Dell keyboard is already not making me any friends here.

Key concepts from the Martin Fowler leadoff keynote, part 1:

External quality, which is negotiable with the users/product owners (e.g., they get to prioritize bugs vs. new features), vs. internal quality (architecture), which really mustn't be.

Accidental complexity vs. essential complexity. Code debt!! Initial accidental complexity is the principal and working with the accidental complexity when implementing new features/changes is the interest. This impacts the effort required to do that new work. It isn't just "debt", it could be on the scale of a technical subprime mortgage. Not that I would know. Nope.

Debt planning (refer also to the debt payoff line graph):

Deliberate/prudent: "We must ship now and deal with the consequences"

Deliberate/reckless: "We don't have time for design"

Inadvertent/prudent: "Now we know how we should have done it"

Inadvertent/reckless: "What's layering?"

Event sourcing:

(This is relevant to my interests.)

We log all events in an insert-only store, and we trust our log, such that at any time we could rebuild the entire current application state (e.g., dB) by parsing the log. This also means we have a solid audit trail, and we could rebuild the entire historical state of the application (presumably someplace else) just by dialing back the date. Or diff two states. In other words, this stuff isn't just for version control systems any more.

Also useful for various other things which hopefully one of my colleagues took notes about. Oops. #shortattentionspan

OK, now there's a dude in front of me taking pictures of Martin Fowler. Unless he's part of Microsoft's PR division, that means I am not the only #fangrrrl in the room! I am sorely tempted to take a picture of him taking a picture.

Coffee time!