Skills that are adequate to build a small system will not suffice to build a larger system. This slidedeck was used in a talk where the differences were highlighted and methods and techniques to build large systems recommended.

1. Programming in the large
Naveen Muguda

2. Two kinds of medicines
• Over the counter
• Prescription

4. programming in small
• activity of writing a small program.
• Small programs are typified by being small in terms of their source
code size,
• are easy to specify, quick to code and typically perform one task or a
few very closely related tasks very well.

5. • Programming in the large
• by larger groups of people or by smaller groups over longer time periods
• program changes can become difficult
• If a change operates across module boundaries, the work of many people
may need re-doing.

6. Laws of Software Evolution
• An E-program is written to perform some real-world activity;
• how it should behave is strongly linked to the environment in which
it runs,
• needs to adapt to varying requirements and circumstances in that
environment

7. Laws of Software Evolution
• "Continuing Change" —must be continually adapted or it becomes
progressively less satisfactory.
• "Increasing Complexity" —its complexity increases unless work is done to
maintain or reduce it.
• "Conservation of Organisational Stability (invariant work rate)" — the
average effective global activity rate in an evolving system is invariant over
the product's lifetime.
• "Continuing Growth" — the functional content of a system must be
continually increased to maintain user satisfaction over its lifetime.
• "Declining Quality" — the quality of a system will appear to be declining
unless it is rigorously maintained and adapted to operational environment
changes.

9. Price of being reactive

12. continuity
Effort,
unpredicatability
Complexity

13. • Complexity reflects the number and nature of entities that comprise
the software, and the number and nature of interactions between
them.

16. Complex
• a complex issue is one in which you can’t get a firm handle on the
parts and there are no rules, algorithms, or natural laws.
• "Things that are complex have no such degree of order, control, or
predictability"
• A complex thing is much more challenging--and different--than the
sum of its parts, because its parts can interact in unpredictable ways.

18. Complicated
• "the components can be separated and dealt with in a systematic
and logical way that relies on a set of rules or algorithms.”
• allows you to deal with it in a repeatable manner.

19. Size | Nature Simple Complex Complicated
small ✓
large ✓ ✓

20. complicated
• order, control, predictability
• rules, algorithms, laws, recipes

21. Complicatedness
• “Liberties constrain, constraints liberate”

23. goal of programming in the large
• Make system “complicated” instead of being complex

24. complexity
• Inherent needs to be managed
• Accidental needs to be reduced/eliminated

25. perspective
• programming properly should be regarded as an activity by which the
programmers form or achieve a certain kind of insight, a theory, of
the matters at hand. This suggestion is in contrast to what appears to
be a more common notion, that programming should be regarded as
a production of a program and certain other texts.” - Peter Naur

26. perspective
• programming properly should be regarded as an activity by which the
programmers form or achieve a certain kind of insight, a theory, of
the matters at hand. This suggestion is in contrast to what appears to
be a more common notion, that programming should be regarded as
a production of a program and certain other texts.” -Peter Naur

27. Problem solving
• apply the model
• create/change/delete the model

28. When you drive
• apply the model
• create/change/delete the model

29. Programming in the large
• apply the model
• create/change/delete the model

32. Models allow us to deal with new situations
• They expedite reasoning

33. • “seems like pub-sub system”
• “looks like a bounded buffer”
• “it’s going to be master slave system”

34. Model
• General idea behind many specific ones
• People remember abstractions

35. experiments
multiplication

36. That vs How
• 5 * 6 => knowing that
• 47 * 78 => knowing how

37. • knowing that doesn’t scale
• knowing how scales
• People remember methods/mechanisms

38. • “will use a builder”
• “will wrap that in a optional”
• “will use a circuit breaker”

39. • Theories “compress” knowledge.

40. • int relationshipStatus
• Enum RelationShipStatus { Single, Married, Divorced}

41. struct Stack {
int top;
unsigned capacity;
int* array;
};
void push(struct Stack* stack, int item)
{
if (isFull(stack))
return;
stack->array[++stack->top] = item;
}
int pop(struct Stack* stack)
{
if (isEmpty(stack))
return INT_MIN;
return stack->array[stack->top--];
}

42. class Stack {
private int top;
private int a[] =
public boolean push(int x)
{
}
public int pop()
{
}

44. • Anti pattern: Primitive obsession, Procedural Programming, Beans

45. Bad practice
• Anemic Domain Model
• “ domain model where the domain objects contain little or
no business logic (validations, calculations, business rules etc.)”

46. • 39865 / 17

49. • composability

50. • On the criteria to be used in decomposing systems into
modules David L Parnas, 1971
• “that it is almost always incorrect to begin the decomposition of a
system into modules on the basis of a flowchart”

51. “axis of change”
• “We propose instead that one begins with a list of difficult design
decisions or design decisions which are likely to change.
• Each module is then designed to hide such a decision from the
others”

52. • Bad practice: controller based decomposition

53. Categories of models
Domain Solution
RDD
Design patterns
Architecture Styles
Coding Styles
Math, Logic
Logic
Set Theory
Discrete Maths
Category Theory
Infrastructure
Concurrency Model,
Process model
Database, Event Queue, Data Structures
Distributed Systems

54. • Models should be filtered, precise, compressed and organized
perceptions of knowledge.

56. Inspiration of models
• Theory | Story | Observation| Math | Metaphor

57. CRC
• Model for reasoning about objects/classes
• Identify a class’s
• responsibilities
• collaborations

58. Responsibility Driven Design
• objects play specific roles and occupy well-known positions.
• community of objects.
• Each object is accountable for a specific portion of the work.
• Objects collaborate in clearly-defined ways.

59. Responsibility Driven Design
• object(class)’s role determines its responsibility

60. Stereotypes
Information holder
Structurer
Coordinator
Controller
Interfacer
Service provider

61. Control styles
• Centralized control style
• Delegated control style
• Clustered control style
• Dispersed control style
• Preferred control style

62. RDD: #1 :MVCRDD #1

63. MVC
• Model: manages the data, logic and rules of the application.
• View: output representation of information
• Controller: accepts input and converts it to commands for the model
or view

64. RDD: #2 EBI
• How to design the model
• Entity : Represent the business objects and contain business logic
• Boundary: model the interface with the system
• Interactor: Use case

66. RDD: Clean
Architecture

67. • The outer circles are mechanisms. The inner circles are policies.
• The overriding rule that makes this architecture work is The
Dependency Rule. This rule says that source code dependencies can
only point inwards. Nothing in an inner circle can know anything at all
about something in an outer circle.

68. • Independent of Frameworks.
• Testable. The business rules can be tested without the UI, Database,
Web Server, or any other external element.
• Independent of UI.
• Independent of Database. Your business rules are not bound to the
database.
• Independent of any external agency.

69. Domain Driven Design
• Entity
• Value object
• Domain Event
• Service
• Factory
• Repository

70. Clean
Architecture

71. complex

72. complicated

73. Bounded Context

77. Partially applied Abstractions

78. Patterns

79. Architectural Styles
Structure
Component-based
Monolithic application
Layered
Pipes and filters
Shared memory
Database-centric
Blackboard
Rule-based
Messaging
Event-driven aka implicit invocation
Publish-subscribe
Asynchronous messaging
Adaptive systems
Plug-ins
Microkernel
Reflection
Domain specific languages
Distributed systems
Client-server (2-tier, 3-tier, n-tier exhibit this style)
Shared nothing architecture
Space-based architecture
Object request broker
Peer-to-peer
Representational state transfer (REST)
Service-oriented
Cloud computing patterns