Out of the box ideas to improve software development

1. Raising The Bar
Alex Bolboacă,  @alexboly,  alex.bolboaca@mozaicworks.com
October 2018

2. Intro
This talks is inspired by
Intersection #1: Software Design + UX = ?
Intersection #2: Other design disciplines + software design = ?
Intersection #3: Materials Science + Software Design = ???
Intersection #4: Maths + Software Design = ?
Intersection #5: Engineering + Software = ?
Intersection #6: Reaching out to scientists
Extra idea: How could development change fundamentally?

3. Intro

4. Software Craftsmanship Manifesto
10 years!

5. My Journey
• Software Craftsmanship
• First coderetreat outside US
• Many meetings
• Many travels to European communities
• I TAKE Unconference
• SoftDevGang

6. But that wasn’t enough for me
I’m a child of SciFi, born and raised in communist Romania

7. Raising the Bar
As aspiring Software Craftsmen we are raising the bar of profes-
sional software development by practicing it and helping others
learn the craft

8. What I heard
Innovation, Collaboration, Breaking Silos

9. So I’m very surprised to hear…
I’m Software Crafter, don’t want to hear about agile
I’m doing DevOps, not agile or software development
We want to scale agile, should we do SAFE or LESS?
I’m a CSM, CSPO, CSP, …
I’m interested in code, what relevance do Math / Physics / Human-
ities have ?

10. Everything is Connected
Connections

11. Intersectionality
What if we combine ideas from various domains with software development?

12. This talks is inspired by

13. David Hussman
David Hussman

14. Dude’s Law
Dude’s Law

15. Intersection #1: Software Design +
UX = ?

16. Usable Software Design
Who uses software designs? Developers (in agile sense, including
programmers, testers, ops, etc)
What if we apply UX techniques to inform our design decisions?
• Personas
• User journeys
• Usability tests

17. What is Usability?
Usability design qualities

18. By analogy, Usable Software Design helps
• Shorten the time from new developer to productive
• Reduce the number of mistakes the teams make
• Improve team motivation
• Improve team productivity

19. Result: The book

20. Intersection #2: Other design
disciplines + software design = ?

21. How do other designers build intuition and learn to design?
Never ever a single solution!

22. Design studies as part of software design education

23. Intersection #3: Materials Science +
Software Design = ???

24. Code is a Material we use for Prototyping
Is it a …
• Crystalline / non-crystalline Solid?
• Gas?
• Liquid?
• Plasma?
• Non-newtonian fluid?
• Something else?

25. Code as a “Physical” material
Forces:
• Change - add some more code, remove some code, modify some code
• Execution - pass some inputs, read the outputs
Constraint:
• Coherence - code runs and produces desirable results
Mechanical properties:
• Rigidity: unevenly distributed

26. Code is like ?
Weird type of plasticine?

27. Materials Science + Software Design = Some Equations and new approaches?
• Could we compute the rigidity distribution of code? Aka an integration
of coupling over the code topology ?
• Could we compute the effect of change on the rigidity distribution?
• Could we visualize the rigidity distribution?
• Could we interact with code through the plasticine-like view?

28. Result: ?
Who knows?

29. Intersection #4: Maths + Software
Design = ?

30. Maths is Fun!
1 + 2 + 3 + 4 + … = ?
Ramanujan extension to addition gives the result -1/12.
This is used in physics (eg. string theory).
Watch the video here: Mathologer: Ramanujan: Making sense of 1+2+3+… =
-1/12 and Co.

31. Maths is based on
Proofs
Theorems
Axioms

32. Standard of proof in software development is …
This has worked for a team

33. What is a program?
outputs = f(t, inputs)

34. Hypothesis
∀f(t, inputs)∃g1, g2, g3, ...s.th.f(t, inputs) = g1(t) ◦ g2(i1) ◦ g3(i2) ◦ ...

35. Biggest problem when refactoring legacy code?
Dependencies

36. Idea: Use Lambda calculus to refactor legacy code
1. Pick a region of code to refactor
2. Turn it into a big, ugly lambda through safe refactoring (aka separate
from state and dependencies)
3. Decompose the big ugly lambda into small nice lambdas
4. Reorganize lambdas into small objects based on cohesion or
duplication of parameters

37. Algorithm v2
From any code region to big, ugly lambda:
1. Pick a set of statements
2. Extract to a function
3. Make the function static and immutable
4. For each compilation error, either: replace state with parameters and
return values or extract another lambda
5. Simplify through currying, functional composition or lambda injection

38. Experimental result
// Groovy version of trivia legacy code base
private static pure_Roll(
final currentPlayerInPenaltyBoxFunction,
final printCurrentPlayerNameFunction,
final printRollFunction,
final isRollOddFunction,
final rollOddAndPlayerInPenaltyBoxFunction,
final playerInPenaltyBoxAndRollEvenFunction,
final playerNotInPenaltyBoxFunction
)
Source:
https://github.com/MozaicWorks/trivia/blob/decomposeLambdasTry2/
groovy/src/main/groovy/com/adaptionsoft/games/uglytrivia/Game.groovy

39. Experimental result: method body
printCurrentPlayerNameFunction()
printRollFunction()
if (currentPlayerInPenaltyBoxFunction()) {
if (isRollOddFunction()) {
return rollOddAndPlayerInPenaltyBoxFunction()
} else {
return playerInPenaltyBoxAndRollEvenFunction()
}
} else {
return playerNotInPenaltyBoxFunction()
}

40. More code
private static playerNotInPenaltyBox(
printNewLocationFunction,
printCurrentCategoryFunction,
askQuestionFunction,
final boolean isGettingOutOfPenaltyBox,
movePlayerFunction) {
printNewLocationFunction()
printCurrentCategoryFunction()
askQuestionFunction()
return [
isGettingOutOfPenaltyBox,
movePlayerFunction()
]
}

41. Maths + Legacy code = ?
• Can we create a method that is mathematically proven to maintain
code behavior?
• And simple enough to learn and apply with modern tools?

42. Intersection #5: Engineering +
Software = ?

43. Built-in self test
A built-in self-test (BIST) or built-in test (BIT) is a mechanism that
permits a machine to test itself. Engineers design BISTs to meet
requirements such as:
• high reliability
• lower repair cycle times
or constraints such as:
• limited technician accessibility
• cost of testing during manufacture
Source: Wikipedia

44. Software tests
src/…
test/…

45. Why not self-testable programs?
createUser -selfTest

46. Why not self-contained programs?
usage: createUser -[create|selfSetup|selfTest|selfCleanup]
-create,--create creates a user
-help,--help show usage information
-selfBackup,--self-backup backs up the database
-selfCleanup,--self-cleanup drops database and user
-selfRestore,--self-restore restores the last backup
-selfSetup,--self-setup creates database and user
-selfTest,--self-test runs self test
Source code: https://github.com/MozaicWorks/
SelfContainedProcessesAsMicroservicesDesignStudy

47. Built-in self test, setup, backup, restore + code = ?
• Psychological: No separation between operational needs and
“production” code
• Software engineering: All requirements taken into account, including
ops
• Technical: Little change

48. Intersection #6: Reaching out to
scientists

49. Problem
Scientific experiments with software development have weird results. Why?
Maybe access issue. Scientists can run experiments either on students, on
open source code bases, or in large companies.
Results don’t fit with software crafters, small / medium companies or
experienced developers.

50. Possible Solution
A CI plugin easy to install and with good default configuration that publishes
anonymous code-related metrics (without the code) to a public repository
accessible to scientists.

51. Extra idea: How could development
change fundamentally?

52. Fundamental difficulty of software development
Turning fuzzy needs and wants into very precise code

53. What if …
We define very precise requirements that are then fed into a machine to
generate the code

54. Extend the Turing machine?
Turing machine

55. If we remove all the other difficulties …
Imagine an ideal generation machine.
We turn the requirements into a very specific language:
Given ...
When ...
Then ...
We feed the machine with the requirements.
We get out generated code that matches the requirements.

56. Consequence: turning back time
Did you make a mistake in your requirements? No worries, plug in the
correct ones and get the right code out
Do you want to change something fundamental? No worries, same process
No more design mistakes, no more rigidity

57. How would the ideal generative machine work?
Intuitively:
• Generate more specialized tests from the given / when / then
• Use TDD cycles + Transformations to adjust the code

58. Is this even remotely possible?
I don’t know. Where to start?

59. Closing

60. Your turn
• Software development + biology = ?
• Software development + chemistry = ?
• Software development + quantum physics = ?
• Software development + art = ?
• Software development + writing = ?
• Software development + typography = ?
Start your workgroups!

61. Thank you!
Let’s raise the bar together!
I’ve been Alex Bolboacă, @alexboly, alex.bolboaca@mozaicworks.com
programmer, trainer, mentor, writer
at Mozaic Works
Think. Design. Work Smart.

62. 50% off my books with the code LSCC
Usable Software Design: https://leanpub.com/usablesoftwaredesign/c/lscc
Coderetreat, Hosting and Facilitating:
https://leanpub.com/coderetreat/c/lscc

63. Q&A
Q&A