Enterprise Performance & Scalability

Fri, 16 Nov 2007 23:08:35 -0600

Attending the 2007 No Fluff, Just Stuff (NFJS) conference in Chicago (Itasca), the first session I attended was Enterprise Performance & Scalability by Ted Neward.

To start, the talk was excellent. Definitely chock full of useful information that you can walk away and start applying right away. If you’re interested in this stuff, I highly recommend that you check out Neward’s book, Effective Enterprise Java. I know I will be. I also recommend that you figure out when NFJS will be coming to a metropolitan area near you, and see if you can get his talk first hand.

Two points stuck out from his talk that I want to pass along.

1. Myth - you know what the problem is
2. Before you fix something, measure the problem.

First, the myth. This really hit a chord with me, because I’ve done it many times myself. A customer or manager comes around, describes a problem, and as a developer, I start thinking what the problem could be and quickly jump to a determination of the problem and an idea of what could solve it. Unfortunately, as Ted points out, our intuition sucks.

The problem is, systems are incredibly complex, and unfortunately, our intuition really does just suck. This leads into the second point. We need to measure.

Measuring means getting information on our applications performance and scalability. This needs to be done before we jump to conclusions or even ideas about where the problem is and what can be done to solve it. To do this, developers need to provide a means of measuring the application, before a problem develops - but certainly, when a problem presents itself, we need to first think about measuring it, getting some data, then drawing conclusions.

Domain Driven Design

Fri, 16 Nov 2007 15:55:21 -0600

The second session I attended at this year’s NFJS in Chicago was on Domain Drive Design with Venkat Subramaniam - something that has held my interest for about a year now. I’m slowly understanding it more, letting it percolate in the back of my head. In that process, one concept that has struck a chord and tripped me up is the ubiquitous language.

The use of ubiquitous language is almost a no-brainer, once you’ve read what Eric Evans says about it. The tricky part seems to be how to get there, particularly how to include an entire I/S team and an entire client team so everyone is speaking the same language.

So, I asked Subramaniam exactly that. Here’s what I learned.

Subramaniam does not recommend sitting down and having an entire team design something. Instead, a pair of developers (pair programming) can sit down and design a feature. Developers should pair differently in short periods (daily, weekly, etc.). This causes the ubiquitous language to be cross-pollinated more readily as each pair works with the client on a feature and then switches up and works in a different area.

In addition to this, senior developers (leads) can assist in validating and cross-pollinating by “running” - jumping from pair to pair in the course of a day or week.

Good stuff, and definitely concrete information that at the very least can be tried and tweaked until it seems like the team and the client are starting to build and refine a domain specific ubiquitous language.

I jotted down a couple other notes to share.

• Building what your customers “wanted” guarantees failure. Write what your customers “want” (present), not what they “wanted” (past).
• Code reviews are good (especially peer code reviews). A code review should make you smarter (peer should point out an improvement) or make you a hero (point out something you did really well).

Coding

Enterprise Performance & Scalability

Domain Driven Design