Why do complex software application projects drag?

Embed Size (px)

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.

Text of Why do complex software application projects drag?

  • 1. Why do projects drag? Developers don't have domain knowledge Scope creep Business rule changes Misunderstood or uncaptured requirements Complex code/domain Steep ramp up Bugs Just get something up there Change is a complexity multiplier

2. 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 3. 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 4. 3 things developers love to do Documentation Write Tests Deal with changing user requirements 5. 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 6. 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 7. 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. 8. 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. 9. 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 10. Elements of a domain Entities Value Object Aggregates Events Non-Entity Services Workflows 11. Entity versus value object Entity Identity is important Properties are mutable Value Object Immutable Generally dependent on containing entity 12. Entities Properties Actions Invariants 13. Entity Properties These are not necessarily concrete fields Data Derived data rules Relative data States Relative States 14. 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 15. Concrete actions Generally fall into three types Update entity (CRUD) Engage non-entity service Alter workflow state 16. Invariants Property level Entity level 17. Events 18. Non entity services 19. Workflows 20. Aggregates A collection of related entities Can in some ways be seen as a meta-entity Usually have a single aggregate root entity 21. Complexes Entry point Can be contained in a number of constellations 22. Tests/Behavior specification Behavior Driven Design http://www.thoughtworks.com/products/twist-agile-testing 23. Moving from Abstraction to something usable 24. Level 1: Communication Result is a dynamic, multilevel domain map 25. The real secret is automation The real real secret is translation 26. Level 2: Stubs Interfaces reference annotated code Not just models, but tests 27. Level 3: Full generation Interfaces code Auto-generated skeleton UI 2 way binding? 28. Simple Interface Implementations 29. Level 4: Dynamic domain systems Dynamic proxies of not in focus constellations Dynamic, overridable entity/complex states 30. Dynamic Interface Implementation Sandbox any sort of state, any constellation 31. Abstracted actions Log action call and parameters Combined with data backup, allows replay of system operation Automated testing Shadow data repository 32. Steve Erdman Steve.erdman77@gmail.com @MrSquicky