A young science

1946 ENIAC 1

1951 Transistors - Univac

1954 Fortran: first high level language

1959 ERMA: first banking computer

1964 IBM 360

1972 Atari

Today IPhone

Think big

With capacity, came complexity

Complexity

Amount of interactions between a number of entities. As the number of entities increases, the number of interactions between them would increase exponentially, and it would get to a point where it would be impossible to know and understand all of them.

Unfortunately, we are limitted

Common Goal: Simplicity

• Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away --- Antoine de Saint-Exupéry
• Simplicity is the ultimate sophistication --- Leonardo Da Vinci
• Simplicity is prerequisite for reliability. --- Edsger W. Dijkstra
• Simplicity - the art of maximizing the amount of work not done --- Agile manifesto

How do we make things SIMPLE???

Code and Fix?

Hunting problems as early as possible?

It's too big!

Do it iteratively?

Managing risks by incrementing?

Managing risks by counting on value?

Can we laugh at any of these methodologies?

I think not!

We need to keep an open mind focused in seeking excellence

This is called exploration, freedom, "breaking the rules", taking risks

About Agile

All about small -- often

When everything is so small

Can you still see the big picture?

Very High Level

Vision

not in our scope

Lower Level

How to keep cohesion?

Agile relies a lot on merciless refactoring

About Refactoring

Have you ever been scared to refactor?

This is a sign that something is going on

James Shores says:

Specification is code

I like that!

Collective Code Ownership

How much code can we own?

Remember why waterfall is not a good idea

It is too big!

We need the obvious simple

Not just simple -- obvious

But what about complexity?

Requirement often are complex

Abstraction of details

As close as possible to specifications

We don't want to have 25 things to maintain

We need Simple & Obvious

But How?

We Need Design

To both:

• Unload our ideas from our brain
• Comunicate the high level ideas behind our not so obvious code

Design can be Obvious code!

Is this very different than hacking?

Yes and No!

What makes hacking ok?

• Merciless refactoring to fix / beautify / generalize
• Unit test to make sure refactoring unveil what is broken
• Manage risks by delivering all the time squality
• Make sure it is Collectively Owned

With Abstraction of Details, we can:

• Own more code
• Better see when refactoring is required and how

Beware!!!

It is not trying to see in the future

Little by Little

Design On Demand

James Shore's first rule:

Less than 10 min

"First, find your exit / coding buddy!"

Use the right tools

White board

I'd like to keep these drawing for posterity's sake

Computerized drawing tool?

Often saves in binary files -- not ideal because it can't be kept easily with code.ssssss

Packaging things together!

We should not have to search for design, BRDs, User Manuals, etc

It should be like the comments and come with the code!

Obviously there!

This way coders know it is there and will be more likely to consult and update

Design

What about:

Diagrams that can be kept with code in RCS

Easy to:

• see changes
• merge changes
• modify
• visualize
• packaged with the code it describes

GraphViz

GraphViz

subgraph clusterAnimalImpl {
	label = "Package animal.impl"
	
	Dog [ label = "{Dog||+ bark() : void\l}" ]
	Cat [ label = "{Cat||+ meow() : void\l}" ]
}
edge [ arrowhead = "empty" ]

Dog -> Animal
Cat -> Animal

edge [
	arrowhead = "none"
	headlabel = "0..*"
	taillabel = "0..*"
]
Dog -> Cat
						

User Manual / Business Requirements

• Html
• LaTeX
• More?!?