Wednesday, November 19, 2008

2008-11-19 Wednesday - QCon 2008 Day-1 afternoon

Disclaimer: There may be some many mistakes/errors in my blog notes for QCon over the next few days - as I am writing these posts while I'm sitting in sessions - and much of these notes are stream-of-consciousness - as I try to keep up with the presenters. I will attempt to clarify/correct any errors within the week.

I'm in San Francisco attending QCon 2008 this week.

Session: Golden Rules to Improve Your Architecture, 1PM-2PM

Alexander v. Zitzewitz
hello2morrow, Inc

created hello2morrow in 2005

"The Dragon of Complexity"
- invisible
- snatches you from behind
- your enemy

"You can never kill complexity"

"The friend of the dragon is the Law of Entropy"

Erosion of architecture - a fundamental law?

Architecture erosion is quote a known problem
- System knowledge and skills are not evenly distributed
- Complexity grows faster than size
- Unwanted dependencies are created without being noticed
- Coupling and complexity are growing quickly

Typical symptoms of an eroded architecture are a high degrees of coupling and a lot of cyclic dependencies
- changes become increasingly difficult
- testing and code comprehension become more difficult
- deployment problems of all kinds

"The Truth can only be found in the code"

Mapping of physical elements to logical elements
- Each package is mapped to exactly one subsystem
- If package's contain types of several subsystems, virtual refactorings are helpful
- a good naming convention for package's can make your life every simple
- Subsystems should have interfaces
- Work incrementally
-- start with your layering
-- then add the vertical slices (if applicable)
-- define subsystem interfaces
-- fine tune the rules of engagement on the subsystem level

How to measure coupling
- ACD = average component dependency
- average number of direct and indirect dependencies
- rACD = ACD / number of elements
- NCCD: normalized accumulated component dependency

(from the large-scale C++ design book)

Robert C. Martin: Dependency Inversion Principle
(invert dependencies, add interfaces)

Spring is a big abstract factory pattern

Average component dependency should be below 7% - heuristic target

Spring has no cyclic dependencies greater than +1

__Cyclic dependencies are evil__
- No cycles between packages
- the dependencies between packages must not form cycles
- cyclic physical dependencies among components inhibit understanding, testing, and reuse.

Introducing interfaces allows you to break cyclic dependencies

__Six Golden Rules for a successful project__
Rule 1: define a cycle free logical architecture down to the level of subsystems and a strict and consistent package naming convention

Rule 2: do not allow cyclic dependencies between packages

Rule 3: keep the relative ACD low (<7% for 500 compilation units, NCCD < 6)

Rule 4: limit the size of java files (700 LOC is a reasonable value)

Rule 5: limit the cyclomatic complexity of methods (e.g. 15)

Rule 6: limit the size of a java package (e.g. less than 50 types)

- JDepend

Neal Ford's presentation: 10 Ways to Improve Your Code, 3:45PM

#1 - Composed Method
Divide your program into methods that perform one identifieable task

refactoring to composed method

__Benefits of composed Method__
method names become documentation
large number of very cohesive methods
discover reusable assets that you didn't know were there

#2 - Test-Driven Development (TDD)
(also Test-Driven Design)

__Benefits of TDD__
- first consumer

#3 - Static Code Analysis

- byte-code analysis: findbugs

#4 - Good Citizenship

singleton is bad because it mixes responsibilities, untestable, the object version of global variables

avoiding singletons
- create pojo for the business behavior (simple, testable)
- create a factory to create one-and-only-one

#5 - yagni
(agile term)

build the simplest thing that we need right now

don't indulge in speculative development

increases software entropy

only saves time if you can guarantee you won't have to change it later

if features are weight - then anticipatory design decreases the velocity of the rate of change that is sustainable in a code base.

Top 10 Corporate Code Smells
10 - we invented our own web/persistence/messaging/caching framework because none of the existing ones were good enough

9 - we bought the entire tool suite (even though we only needed about 10% of it) because it was cheaper than buying the individual tools.

8 - We use WebSphere because...(I always stop listening at this point)

7 - We can't use any open source code because our lawyers say we can't

6 - We have an Architect who reviews all code pre-checkin and decides whether or not to allow it into version control

5 - The only JavaDoc is the eclipse message explaining how to change your default JavaDoc template

4 - We keep all of our business logic in stored procedures..for performance reasons

3 - We don't have time to write unit tests (we're spending too much time debugging)

2 - The initial estimate must be within 15% of the final cost, the post-analysis estimate must be within 10%, and the post-design estimate must be within 5%

1 - There is a reason WSAD isn't called WHAPPY

#6 - Question Authority

test names - use underscores (not Camel Case)


pair-programming studies - pairs produce code 15% slower after adjustment, but with 15% fewer defects

#7 - Single Level off Abstraction Principle (slap)
everything should be at the same level of abstraction
jumping abstraction levels makes code hard to understand / maintain

#8 - Polyglot programming
leveraging existing platforms with languages targeted at specific problems and applications

looming problems/opportunities
- massively parallel threading
-- use a functional language:jaskell, scala (inherently thread save, immutable)
- schedule pressure
-- jruby on rails
- writing more declarative code via dsls
- build fluent interfaces
-- swiby:jruby + swing
--- (swiby is a DSL for UI programming)

"Java will become the glue language"

#9 - Learn Every Nuance of your chosen language/tool

- java's back alleys
-- reflection

- regular expressions

#10 - anti-objects
OOPSLA 2006 - collaborative diffusion presentation

"The metaphor of objects can go too far by making us to create objects that are too much inspired by the real world"

Dr. Dean Wampler's presentation: Radical Simplification Through Polyglot and Poly-Paradigm Programming, 5:15PM

Simplification of code is necessary

Ola Bini's Three Layers

Functional Programming avoids multi-threading/concurrency issues

Functional programming: Declarative rather than imperative

DSLs tend to be very declarative

Examples of Functional Languages:
- Erlang
-- 9-9's reliability for AXD301 switch
-- for distributed, reliable, soft-time
-- All IPC is optimized messaging passing
-- very leightweight and fast processes

-- hybrid language (object and functional)
-- targets the jvm
-- "endorsed" by James Gosling at JavaOne
-- could be a popular repalcement for Java

"Is a hybrid object-functional language better than using an object language with a functional language"?

Disadvantages of PPPP
- N tool chains, languages, libraries, "ecosystems"
- impedance mismatch between tools

Advantages of PPP
- use best tool for a particular job
- can minimize amount of code required
- can keep code closer to the domain
- encourages thinking about architectures

Why go mainstream now?
- rapidly increasing pace of development
- pervasive concurrency
- cross-cutting concerns