GOTO notes: Software Mechanics

04/27/13

GOTO notes: Software Mechanics

Software Mechanics
What I wished I knew at the beginning of my career.
Michael Feathers

Software is Biological
It’s not a construction process. It’s organic, and often messy.
It’s hard to change decisions you made early in the process of growing a system.
We’re more like gardeners.

There is no Up or Down in Software
A layered architecture, etc. is a schema we impose - but it’s one of many.
Top-down, bottom-up - just ways of looking at a system.
Connected or not-connected (information flow) - another way of looking at it
Alistair Cockburn - hexagonal architecture

Everything is an Object
Another way we impose schema on things.
Smalltalk implements “if” as sending a message to a Boolean value. It mimics control structures with polymorphism.

A Type is a Set of Values
int is obvious.
An interface allows us to narrow our design, because it reduces the set within a given context (rather than access to 15 methods on the concrete type, you only get the 2 on the interface).

Types and Tests are the Same Thing
Test failures may be reported the same as compilation failures in the IDE.
Tests say that a system will act in a particular way, as do types.

Sweetness Is Painful
If we design mechanisms to do multiple things in our code, we risk violating SRP. Design elegance can bind things together. (Hairdryer that turns off when we hang it up in a hotel.)

You Can’t Make Software Stronger With Redundancy
We can get better uptime, but we can’t get more correctness.
N-version programming didn’t work well.

Protection is a Social Problem Not a Technical Problem
Sealed/final modifiers work poorly.
API design locks consumers in; they can’t extend things in the way they want.
Maybe the system isn’t testable.
We can’t foresee all the circumstances in which people will want to use our API.
On both sides of an interface we’ll have cruft.
Ruby/JavaScript don’t have these protections, and people can still get work done.

There Are No Requirements (It’s All Design)
Have developers question the business. Are you sure you want to do this?
Have conversations.

Names Come After Structure
For him, he thinks about actors and notifications. The names come later.

The Physical Shapes The Logical
MapReduce; Eventually Consistent
Scale out.
Consider the physical architecture first.

The Social Shapes Design
Conway’s Law
Tragedy of Commons - no one feels ownership (happens in software, too)
Consider changing team structure to target the current goals.

You Can Design Away Errors
You can make certain errors impossible. Strive for that.
Immutability
Capture errors in the input before proceeding (don’t have to keep checking)
Design-by-contract - if doing, try to make the contracts simpler and simpler

Logging is a Design Failure
A method that could be 15 lines is expanded out to 30 because of logging.
Can cripple systems.
Freeman & Pryce - Growing Object Oriented Software, Guided by Tests (book)
We design our pieces to notify someone about their internal state.
Notifiers (similar to Observer Pattern)

Databases are a Design Tool
Try to do selective SELECTs.

Globals Hide Design Information
Sneaky action at a distance. Silent coupling.
Explicit constraint - this is a resource, and I’ll pass it to where it needs to be used
You learn that there are only these places that need this resource.
Better separation of concerns.
If people can touch something anyplace, often they will touch it anyplace.

Standards Dampen Design
Hard rules (cyclomatic complexity of X, conventions, etc.) may prevent people from making exceptions when it makes sense
Rules of thumb are better
Control can be counterproductive.

Context is King
If you’re talking about best practice without discussing the context, it’s just B.S.
(This goes back to Standards Dampen Design.)

Response to functional programming question from audience:
Exposure of data isn’t as big of a deal if it’s immutable.
Design can become compositional.


Your Host: webmaster@truewill.net
Copyright © 2000-2013 by William Sorensen. All rights reserved.