why do complex software application projects drag?

Post on 04-Jul-2015

145 Views

Category:

Software

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Rough slides from my (also rough) talk given at Philly Bar Camp 2014 about conceptual problems facing complex software application projects and what can be done about these problems.

TRANSCRIPT

Why do projects drag?Developers don't have domain knowledge

Scope creepBusiness rule changesMisunderstood or uncaptured requirements

Complex code/domainSteep ramp upBugs“Just get something up there”Change is a complexity multiplier

How to fix it

Problem: Developers don't have domain knowledge

Solutions: Short, clear 2 way communication channel Provide tools for domain experts to express domain concepts

and see the results of changes

How to fix it: part 2

Problem: Complex code/domain

Solutions: Comprehensive documentation Comprehensive test suite Minimalist modular code design Common code practices and conventions

3 things developers love to do

Documentation Write Tests Deal with changing user requirements

Abstraction

What a thing is or what needs to be done Opposite of implementation – how a thing is constructed or

how something is done

Goal is to reach simplest representation that still contains all necessary information

The challenge is to match level of abstraction to needs and capacity of people involved

2 way street – both IT concerns and domain knowledge are abstracted

Steve's Web Development rant

Web development has often leaned heavily towards “just getting something up there” and concerned itself with implementation over abstract design

UI focused – UI tools have traditionally been not good at supporting abstraction

Mismatch between HTML and application needs

We are moving to a place where the complexity of applications calls out for abstraction and the tools and practices are coming along to support thinking about things in an abstract manner

MVC – many models to one view

View Model Interface A view can have a defined interface for how it gets handles

the model data. Providing a translation from your data models to the

interface will allow the view to display and interact with it A table can display a 2d array, a list of objects, steps in a

mathematical series, etc.

MVC – many views for one model

Multiple view types of the same model A single data entity can be displayed by any number of

views e.g. Song

Audio in media player Music staff with lyrics Word Cloud Etc.

Domain Driven Design

Iterative navigating the domain to arrive at a level of abstraction that captures the relevant properties of the system while remaining comprehensible to all parties to the design

This is referred to as the Ubiquitous Language

Represents a shift away from UI-focused thinking

Elements of a domain

Entities Value Object Aggregates Events Non-Entity Services Workflows

Entity versus value object

Entity− Identity is important− Properties are mutable

Value Object− Immutable− Generally dependent on containing entity

Entities

Properties Actions Invariants

Entity Properties

These are not necessarily concrete fields

Data− Derived data – rules− Relative data

States− Relative States

Actions

Can be specified at a range of abstractions, from “it does this” to concrete implementation.

Can have expected input-output pairings and constraints attached

Concrete actions

Generally fall into three types− Update entity (CRUD)− Engage non-entity service− Alter workflow state

Invariants

Property level Entity level

Events

Non entity services

Workflows

Aggregates

A collection of related entities Can in some ways be seen as a meta-entity Usually have a single aggregate root entity

Complexes

Entry point Can be contained in a number of constellations

Tests/Behavior specification

Behavior Driven Design− http://www.thoughtworks.com/products/twist-agile-testing

Moving from Abstraction to something usable

Level 1: Communication

Result is a dynamic, multilevel domain map

The real secret is automation

The real real secret is translation

Level 2: Stubs

Interfaces → reference annotated code− Not just models, but tests

Level 3: Full generation

Interfaces → code Auto-generated skeleton UI 2 way binding?

Simple Interface Implementations

Level 4: Dynamic domain systems

Dynamic proxies of not in focus constellations Dynamic, overridable entity/complex states

Dynamic Interface Implementation

Sandbox any sort of state, any constellation

Abstracted actions

Log action call and parameters Combined with data backup, allows replay of system

operation− Automated testing− Shadow data repository

Steve ErdmanSteve.erdman77@gmail.com

@MrSquicky

top related