This document discusses principles of developing software using small methods, classes, modules, applications, and teams. Some key points made include: - Small methods, classes, and modules make the software simpler to understand and easier to change. - Applications should be carved out based on domain, users, workflows, and loose coupling. This provides better deployment, users, and asynchronous processes. - Teams work best when organized by application rather than module to avoid issues when code needs to span applications. - Conway's law states that the structure of software reflects the structure of the organization that built it, so architecture and team organization should be considered together.

1. small is beautiful

2. small methods
small classes
small team
small company
small away day :-)

3. big problems
complex world
lot of talent
big aspirations
but....

4. e.g., can a small company solve big
problems?

5. lets leave that for the bar

6. we care about beautiful
small is means

7. why we like small in software

8. simpler to understand

9. easier to change

10. faster to get our work done

11. we like making progress

12. small in software development

13. small methods
small classes
small modules
small applications
small teams

14. small methods

15. tell don't ask
extract method refactoring
strategy pattern
....

16. extract method
when to stop?
extract only when it adds beauty

17. avoid compression

18. when to stop, when is if-else better
when strategy is not a domain concept
simplicity > small
strategy pattern

19. small classes

20. extract class refactoring

21. http://www.refactoring.com/catalog/extractClass.html

22. can be applied to a primitive, collection or
domain primitive

23. number --> money --> salary
language primitive
domain primitive
value object

24. smaller modules

25. module by responsibility types

26. repositories
domain
services
contracts
mappers
a service module

27. does this add beauty?

28. doesn't scale
over period of time everything still bloats
not much

29. Conceptually

30. modules by domain

32. reference data
organization
customer, product
accounts
payments, cash flow, questionnaire
module layers (mifos)

33. weak links between modules
cohesion within a module
identical rate of change of data
to find modules

34. hard to evolve to
deliberately design and implement
for me..

35. consequences

36. module encapsulate complexity

37. only interact to module using its interface
provides decoupling

38. domain model externally in-visible
no cross module entity relationship
[hibernate]
use identity
can still use foreign keys
encapsulated domain

39. inter module communication

40. to dependee module
ask

41. pass message (logical)
e.g. accounts to payments module, tell
makeEntries(amount, customerId)
instead pass message
paymentMade(amount, customerId)
no assumption of implementation
to sibling module

42. use events
product to account module
meetingScheduleChanged(productType)
with dependent module

43. cross cutting module
performance
cross module operations

44. module not just to provide reusability
but to stay small

45. namespaces, for layers in a domain module

46. small applications

47. un-shared code
serving some utility
un-shared database
what is an application

48. don’t reinvent
be lazy first look outside
simplest rule

49. deployment
users
department
asynchronous processes
contained workflows
loose coupling
how to carve applications

50. examples

51. public website
call center
fulfillment
user and workflow driven
trainlines

52. outlook
sanitization
management
synchronization
user and workflow driven
bcg

53. unnoticed in insurecom

54. single ugly monolith (although….)
administration
accounting
policy and claims
…
insurecom

55. too small applications
rackspace

56. same users, different applications, dealing
with similar data
too fine breakup
rackspace

57. challenges
test of the parition

58. joins across systems

59. e.g.
show all unused IP address in this data
center

60. put databases on same server
select … from location.datacenters,
network.ipblocks where ….
hack!

61. query one and query another with result
change use case, what does user want
reporting from data warehouse
is it happening quite frequently?

62. transaction across systems

63. distributed transaction
bad performance
availability impact

64. idempotent operations
asynchronous updates
decentralized data
is it happening quite frequently?

65. centralized data application
configuration data in rackspace

66. de-centralize your data

67. configuration data in rackspace
location configuration
network configuration
…..

68. explain principles
explain application architecture
build common vocabulary
take feedback
evolve
customer and analysts

69. small teams

70. 20 members
developer team = 10
qa team = 6
build & deployment team = 4
beautiful?

71. journey search & journey options

72. same location
no contracts
artificial user stories
database based dependency
same continuous integration
beautiful?
team by module
babies joined at hip

73. website and call center

74. different location
INVEST stories
loose coupling
different continuous integration
business contracts
team by application

75. INVEST stories
own continuous integration
own release
different location
application contracts
small team test

76. beware of conway's law
software provides archaeological evidence
of people/team who worked on it

77. architecture and team organization are not
independent

78. questions