Advice on structured software development for academics. Presented to Maths and Physics PhD students and researchers at Queens University Belfast.

1. training@instil.co
February 2019
© Instil Software 2018
10 Big Ideas from Industry
Queens University

2. Develop
Consult
Train

3. With Special Thanks to Liberty IT

4. I’m here to Raise Awareness

5. How I Got Started…

6. Ten Big Ideas From Industry…

7. These ideas are not mine
• They are wisdom from
experts in the industry
• So I will be showing you a
lot of Tweets from gurus
As you know…
• Copying from a single
source is plagiarism
• Copying from many
sources is research J
None Of These Ideas Are New

8. © Instil Software 2018
Version Control Matters
(Unless you’re a masochist)

9. Why Version Control?

10. Learning About Version Control

11. Introducing Git
10
1
2
3
4
6
5
8
9
7
10
A Git repository is a complex tree and
can present branches with individual
history logs
A branch is simply a pointer to a node

12. Introducing Git
10
1
2
3
4
6
5
8
9
7
10
This is possible because structurally
every node refers to one or more parents
The arrows drawn so far need to flip
When we use
branches and make
changes, the pointer
moves automatically

13. Introducing Git
10
1
2
3
4
6
5
8
9
7
10
Arrows now represent a dependency
Our repository is actually a Merkle
Tree

14. Introducing Git
10
1
2
3
4
6
5
8
9
7
10
We can also mark or remember
individual nodes by adding tags
Unlike branches, tags do not move
R1.0.0
R1.0.0
R0.2.0 R0.2.0
R0.2.0
R0.2.0

15. © Instil Software 2018
Create Feedback Cycles
(The smaller the better)

16. Find And Tighten Feedback Loops
BEST
TWEET
EVER

18. Find And Tighten Feedback Loops

19. Find And Tighten Feedback Loops

20. Build faster feedback loops
• Running unit tests every few minutes via TDD
• Running integration tests every few hours via CI
• QA teams completing non-functional tests weekly
• Clients commenting on demos every 2-3 weeks
• Releases measured in weeks or months
Agile = Feedback Loops

21. TDD
BDD
Integration Tests / CI
Non Functional Tests / QA
Sprint Demos and Retrospective
Feedback Cycles in an Agile Project

22. The Test Driven Cycle In Outline

23. Celebrate the ‘but that’s stupid’ moments!
• This is what keeps us going the right way
• Limitations of the current code inspire the next test
Always watch the test fail first
• The existing codebase may already do what you need
• You may have accidently written a test that cannot fail
Don’t implement and refactor at the same time
• They are two separate activities
• Mixing them only causes confusion
• Remember tests need refactoring as well
There’s a difference between simplest and stupid
• Keep making progress towards your intended design
• Never work yourself into a corner in the name of simplicity
Key Points About the TDD Cycle

24. Understanding the TDD Cycle

25. Some Great Reads

26. Some Great Reads

27. © Instil Software 2018
Its OK To Be Scared
(But never not to ask)

28. Programming Is Really Really Hard

29. No Fear
(Well Just A Little)
Pure Bowel
Knotting Terror
You’re Going To Experience Fear Every Day…

30. You have the right:
• To know what is needed (requirements) with clear declarations of
priority
• To produce quality work at all times
• To ask for and receive support from peers, superiors, and
customers
• To make and update your own estimates
• To accept responsibilities instead of having them assigned to you
The Developer Bill of Rights

31. You have the right:
• To an overall plan, to know what can be accomplished when and at what
cost
• To get the greatest possible value out of every programming week
• To see progress in a running system proven to work by passing repeatable
tests that you specify
• To change your mind, to substitute functionality, and to change priorities
without paying exorbitant costs
• To be informed of schedule changes in time to choose how to reduce the
scope to restore the original date
• You can cancel the project at any time and be left with a useful working
system reflecting the investment to date
The Customer Bill of Rights

32. Some Recommended Reading

33. © Instil Software 2018
Social Skills Matter
(It’s a team sport)

34. Social Skills Matter
Developers start out obsessing about code
• But end up as psychologists and/or linguists
Coding in industry shouldn’t be completely novel
• All the really technical problems have been solved already
People are a very different matter
• The true challenges in software all revolve around people
• Your colleagues, your management, your clients etc…

35. Not this…
Or even this…
But this…

36. Social Skills Matter

37. Some Helpful Advice…

38. © Instil Software 2018
Performance Matters
(Except when it doesn’t)

40. What is Meant by ‘Performance’?
‘Performance’ can mean many things:
• Latency – the time for an item to be processed
• Throughput – no of items completed per ‘n’
• Scalability – how throughput alters as usage increases
• Degradation – what happens when we can’t scale further
• Utilization – making full use of cores, RAM etc...
Each application will have its own priorities
• E.g. an Android or iOS client will want low latency whereas a
batch processing system will want high throughput

41. Examples of Relative Costs of Operations

42. How do we Measure Performance?
We measure performance with:
• Micro-benchmarks - fictional analysis of part of the system
• Profiling - collecting runtime data from a ‘real’ system
• Benchmarking - determining the limits of the ‘real’ system
• Monitoring - collecting metrics from various environments
The best measurements are the most difficult to obtain
• The closer you come to real world usage the greater the barriers
in your way to collecting measurements
• In some environments there may be legal constraints that
prevent you ever interacting with the system in production

44. Does Performance Matter?
In the early days of IT performance was everything
• Because hardware was expensive compared to developers
Over time this began to change
• Developer time became expensive compared to hardware
• Software spent more and more time being maintained
Developers understanding of performance declined rapidly
• As the underlying platform became more and more complex
Today the rule is:
• Write the shortest simplest code you possibly can
• Allow the compiler, VM and hardware to optimise it
• Don’t constrain your code with assumptions about speed
• Have performance tests to provide reliable feedback

45. © Instil Software 2018
Code With Two Hats
(Wear one at a time)

46. There Is Some Truly Horrible Code Out There…

47. Real Developers Write Code That’s Readable

48. Good Boy Scout Rule

49. Refactoring Is Part Of Normal Development

50. Quality
Feedback
Loops
Clearly Correct
Code
Ubiquitous
Language
Encapsulation Immutability
Decomposition
Verification
Spec By
Example
OO FP Single Purpose
Methods
TDD
BDD
Profiling
DDD
RX
Iterations
CI
TDD
The limits of my
language mean the
limits of my world
If you always do what
you’ve always done
you'll always get
what you’ve always
got
“Obviously No Defects” Vs.
“No Obvious Defects”
Reviews
Retrospectives
DI
Modules
MVC
Monads
Structs
Contracts

51. Read These Books

52. Never Implement and Refactor at the Same Time!!!
We write code with ‘two hats’
• The ‘I have to get this ******** thing working’ hat
• The ‘someday someone will maintain this’ hat
The second hat is the Refactoring one
• Refactoring is a vital skill in its own right
Never implement and refactor together
• Your thinking will get derailed and you will create a mess

53. Unit Tests And Refactoring Go Hand In Hand

54. © Instil Software 2018
Apply the S in SOLID
(In a hierarchical manner)

56. The Single Responsibility Principle
Every function / type / class you write should
• Perform a single function in the app
• Have only ever one reason to change
• Be describable without conjunctions
This is indicated by brevity
• Aim for method lengths of 10 lines or less
• Or even 6 lines or less in Ruby / Scala / Kotlin

57. SRP Works at Different Levels of Abstraction…

58. Unit Tests Are Tests Of Abstractions

59. © Instil Software 2018
Naming Is Everything
(…and incredibly hard)

60. When It All Goes Wrong...

61. Does Language Matter?

62. Get Into The Habit Of Worrying About Names

63. Introducing Domain Driven Design

65. Bounded Contexts and Language Games
But how many kinds of sentence are there?
Say assertion, question, and command?---
There are countless kinds: countless
different kinds of use of what we call
"symbols", "words", "sentences". And this
multiplicity is not something fixed, given
once for all; but new types of language, new
language-games, as we may say, come into
existence, and others become obsolete and
get forgotten. (We can get a rough picture of
this from the changes in mathematics.)
Here the term "language-game" is meant to
bring into prominence the fact that the
speaking of language is part of an activity, or
of a form of life.

66. © Instil Software 2018
Objects Are Awesome
(But FP is the future)

67. C
C++
Java
C#
Pascal
Delphi
Basic
Visual Basic
VB .NET
Perl
F#
Java
Script
CoffeeScript
1990
2000
2010
TypeScript
Jython
JRuby
PowerShell
Dart
Scala
Clojure
Kotlin
Groovy
Go
Objective C
Shell
Scripting
Swift
Python
Ruby

68. Object Orientation Has Proven Its Worth…

69. Objects Threads

70. Functional Coding Is Becoming More Prevalent

71. Comparing the OO and Functional Styles

72. But all a purely functional program
can do is heat up the CPU - and
that's still a side effect!!!

73. Languages on the JVM
Java Virtual Machine
Bytecode
Interpreters
JRuby Groovy Jython
Scala Clojure KotlinJava
Gradle

74. Making Waves at the Moment

75. You Might Want To Learn Haskell…

76. © Instil Software 2018
The Jungle Is Neutral
(So it’s all up to you…)

77. Routes Into IT & Career Progression
• System Administrator
• DB Admin
• Network Admin
• Remote Support
• On-site Support
• Professional Services
• Junior à Senior Tester
• Test Team Lead
• Junior à Senior
Developer
• Technical Lead
• Architect
• Evangelist
Dev QA
Sys
Admin
CD
Management
Sales & Marketing

78. You need to keep updating your skill set
• Frameworks go out of date every 2-6 years
• Programming languages every 6-12 years
You Need to Keep Your Skills Updated

79. You Need To Manage Your Own Career

80. Ultimately The Jungle Is Neutral…

81. © Instil Software 2018
In Summary…

82. Here are our 10 Big Ideas once again:
• Version Control Matters
• Create Feedback Cycles
• It’s OK To Be Scared
• Social Skills Always Matter
• Performance Can Matter
• Code With Two Hats
• Apply The S In SOLID
• Naming Is Everything
• You Need OO And FP
• The Jungle Is Neutral
In Summary

83. Any Questions?