If you’re occasionally missing deadlines, accumulating unbillable work or shipping bugs, you’ll learn six techniques to dramatically increase quality while working quickly. In this session, learn what’s proven to work for SeedCode when delivering both large custom projects, as well as quick little mods. These are techniques you can implement without hiring new staff and without slowing down. These are the techniques we use at https://www.seeedcode.com and https://dayback.com

1. © 2017 FileMaker, Inc.
FILEMAKER DEVCON 2017
JULY 24 - 27, 2017 | PHOENIX, AZ
What Works: Strategies for
Increasing Code Quality while
Staying Lean
BUS004
John Sindelar
SeedCode, Inc. | DayBack Calendar

2. #FileMakerDevCon© 2017 FileMaker, Inc.
Who am I?
John Sindelar
Developer since FileMaker 3
CEO of SeedCode
- A few couple large custom projects each year
- Lots of small mods for map and calendar customers
Author of the early SeedCode Calendars (now DayBack)
Surfer, trail runner, kayaker

3. #FileMakerDevCon© 2017 FileMaker, Inc.
No Time for Quality?
We don’t have time for this because…
- All our projects and late already
- Everyone is already super stressed
- We don’t have time.
Humans don’t “have” time, we “make” time
- Literally
Think of what follows as Techniques for Making Time

4. #FileMakerDevCon© 2017 FileMaker, Inc.
Where these technuiques came from
“Our new team members are going to
learn more from what we do than
from what we say….”
“…So let’s make sure we’re actually
doing the things that have worked for
us.”

5. #FileMakerDevCon© 2017 FileMaker, Inc.
What Works?
“Having an internal blog works”
- A living handbook for policy questions
- A place for employees to draft (and comment on) public posts
- Document what’s working for you

6. #FileMakerDevCon© 2017 FileMaker, Inc.
Where do these strategies apply?
Project Size
- Large, multi-year projects (over 6,000 hours)
- Smaller mods (4-10 hours)
- We use almost the same strategies for both
Small teams or solo developers
Using FileMaker Pro

7. #FileMakerDevCon© 2017 FileMaker, Inc.
What do we mean by “quality”?
Quality is often used as a synonym for “good”
- In code, comments are “good” because they serve a value
- Like “transparency”
- But transparency serves a value like “portability”
- “Quality code is highly portable” links a presumed good to a value
So what are the values by which we judge quality?

8. #FileMakerDevCon© 2017 FileMaker, Inc.
What do we mean by “quality”?
Money, $$, €
Money, and time.
Money, time, and freedom.
“But money, of course, is never just money. It's always something else, and it's always
something more, and it always has the last word.” - Paul Auster

9. #FileMakerDevCon© 2017 FileMaker, Inc.
What do we mean by “quality”?
Only interested in code quality in terms of money and time.
In this context quality means:
- Less rework
- Increasing delivery velocity
- Role portability in your team
- Speedy project restarts

10. #FileMakerDevCon© 2017 FileMaker, Inc.
What do we mean by “lean”?
Strategies that don’t require hiring people, or
- Subscribing to apps
- Buying gear
- Adopting dev conventions
- Putting your kids to work
- Giving up sleep and weekends

11. #FileMakerDevCon© 2017 FileMaker, Inc.
P.S. What Works?
“Defining your terms works”
- It’s tough to make decisions among “good” options without clearly stated values
- “I like option A because it’s more clear”
- vs
- “Option A adheres to the principle of least astonishment”
https://en.wikipedia.org/wiki/Principle_of_least_astonishment

12. #FileMakerDevCon© 2017 FileMaker, Inc.
What Works: Strategies for Increasing
Code Quality while Staying Lean
What we do
Problems solved
Tips

13. #FileMakerDevCon© 2017 FileMaker, Inc.
1. Video
Demo is the new testing.

14. #FileMakerDevCon© 2017 FileMaker, Inc.
1. Video: What we do
Every small delivery is accompanied by a 3-5min video
For large projects/products, every case is closed with a video
We demonstrate the “whole feature”
Using the customer’s data
Mac/Win: http://screencast-o-matic.com https://www.monosnap.com/welcome

15. #FileMakerDevCon© 2017 FileMaker, Inc.
1. Video: Problems solved
The act of demoing swaps developer mode for user mode
- You will catch mistakes this way
- Which means less rework
Customers can’t evaluate our work if we just drop it off
- They can’t make sample data & won’t experiment with real data
- They don’t know how to reproduce initial conditions
- They don’t have time

16. #FileMakerDevCon© 2017 FileMaker, Inc.
1. Video: More problems solved
Anyone in your team can come up to speed
- Instead of finding the file, logging in, …..
- Watch a video and you’re caught up
- Portability and restart speed
Videos are a reminder to everyone that it worked when we delivered it

17. #FileMakerDevCon© 2017 FileMaker, Inc.
1. Video: Tips
Record as if you were showing it off to an interested friend
- You’re not selling or pitching
Open questions should be transcribed into emails or cases
- You can’t search video narration
Close with suggestions & next steps
- A suggestion of what we could do next to increase the software’s value

18. #FileMakerDevCon© 2017 FileMaker, Inc.
What Works?
“Video Works”
- Probably the most important thing we’ve done to reduce mistakes
- Role portability has increased for custom work
- Delivered work gets validated by customers (not just accepted)

19. #FileMakerDevCon© 2017 FileMaker, Inc.
P.S. Close every case with a video
If you’re asking, “What’s a case?”…
…You need a bug tracking database
- FogBugz, Jira, ZenDesk, GitHub, etc.
- Try to pass as much of the Joel Test as you can
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

20. #FileMakerDevCon© 2017 FileMaker, Inc.
2. Breaking Things into Small Chunks
We do not listen to a client for 4 hours
then head into the desert for 4 months to
build their software
…hoping they like it when we return.

21. #FileMakerDevCon© 2017 FileMaker, Inc.
2. Small Chunks: What we do
Deliver every 5 or 10 hours of code (small projects)
For large projects or products, deliver every week.
Deliver means deploy
- Deliveries are put into production (data migration and everything)

22. #FileMakerDevCon© 2017 FileMaker, Inc.
2. Small Chunks: Problems solved
We don’t outrun our understanding of the client’s issue
- You also speak with the client more often.
Work actually gets validated
- Deliveries are small enough for the customer to digest
- Deployments are seen by ALL users (not just informants)
- You get feedback now not months from now
“The only real risk is to build the wrong thing” - SeedCode

23. #FileMakerDevCon© 2017 FileMaker, Inc.
2. Small Chunks: More problems solved
No more half done features
- It sucks to restart something that was never finished.
- When we finish something we put it to bed by deploying it.
Redefines “Bugs”
- making a distinction between “mistake” and “undone”
Reduced cognitive load
- Undone tasks take up much more mental energy than things that are put to bed.
http://www.spring.org.uk/2011/02/the-zeigarnik-effect.php

24. #FileMakerDevCon© 2017 FileMaker, Inc.
2. Small Chunks: Tips
Cases should be binary
- Something that is either done or not
The more friction, the smaller the chunk
- Subcontractor cases should be no more than 5 hours
- Project restarts: 3 hours

25. #FileMakerDevCon© 2017 FileMaker, Inc.
2. Small Chunks: More Tips
Use timeboxing to keep things small…
…and “Ship anyway”
- Create new cases for the gaps or edge cases.
- Those are just more small chunks.

26. #FileMakerDevCon© 2017 FileMaker, Inc.
What Works?
“Breaking things into small chunks works”
- Small chunks are more portable,
- They reduce risk,
- And increase everyone’s sense of success (even the client’s).
- Most importantly, we don’t outrun our understanding of the subject matter.

27. #FileMakerDevCon© 2017 FileMaker, Inc.
3. Documenting our Decisions
We’re coding for our future selves.

28. #FileMakerDevCon© 2017 FileMaker, Inc.
3. Documenting: What we do
We write comments make links.
Case numbers create links: finding them in code is gold.
When we decide between competing alternatives…
…we write about that in the case or in the product docs.
Competing alternatives, see “Why Make this a Switch” -
http://www.seedcode.com/pmwiki/index.php?n=DayBackForFileMaker.PerformScriptOnServer)

29. #FileMakerDevCon© 2017 FileMaker, Inc.
3. Documenting: Problems solved
Creating a path from the customer’s case (or feature specs) to the code
that addresses them
A path that our future selves can follow.
- Reduces restart time
- Increase role portability
“One definition of fragility: the original developer is the only one who
can help this customer” - SeedCode

30. #FileMakerDevCon© 2017 FileMaker, Inc.
3. Documenting our Decisions: Tips
Start the docs, email, blog post before the code
- It’s much easier to jot down these details as we’re building vs to reconstruct them later
Include the case #s in the code and commits
- In comments when code is commented out or added.
- In script headers
- In GIT commits

31. #FileMakerDevCon© 2017 FileMaker, Inc.
What Works?
“Documenting our decisions works”
- We write code once but we support it forever
- Increases role portability…
- …which reduces developer distraction / gear switching
- Removes Fear Uncertainty and Doubt: the “spooky music” that slows us down

32. #FileMakerDevCon© 2017 FileMaker, Inc.
4. Recording Technical Debt
Document the path not taken.

33. #FileMakerDevCon© 2017 FileMaker, Inc.
4. Recording Technical Debt: What we do
Defer hardening until our work is validated by the customer.
- Keep scripts simple as long as possible
We create a case for what’s undone
Create cases for any bugs we see that aren’t going to be fixed IN the
video
https://en.wikipedia.org/wiki/Technical_debt

34. #FileMakerDevCon© 2017 FileMaker, Inc.
4. Recording Tech Debt: Problems solved
“Recording instead of coding” avoids premature optimization
Capturing what’s undone
- It takes less time to get back to work because I know just where to pick up
- Increases role portability as others can pickup where I left off
Recording let’s me “observe” without pressure to fix
- We’re more attuned to what’s happening when we’re not also trying to weigh its consequences
Premature optimization / generalization:
https://dev.to/wrschneider/balancing-early-and-later-project-risks

35. #FileMakerDevCon© 2017 FileMaker, Inc.
4. Recording Technical Debt: Tips
Have a place to record debt
- Bug tracking database
- Inside scripts document your intention not your method
Get used to making lots of small cases
- Anything surprising or unexpected gets a case.
- When you find yourself pausing while recording a video
- Schedule “hardening” sprints to bring down debt
Again: https://en.wikipedia.org/wiki/Principle_of_least_astonishment

36. #FileMakerDevCon© 2017 FileMaker, Inc.
What Works?
“Recording technical debt works”
- Technical debt taken on intentionally can help us get there faster,
- Just like debt financing can help a company grow faster.
- Debt taken on invisibly is like a variable rate loan—not good.
- And in both cases, it’s the unknown that makes all the difference.

37. #FileMakerDevCon© 2017 FileMaker, Inc.
5. Cut to the Chase
Remove unnecessary back and forth by
proposing closing actions first.

38. #FileMakerDevCon© 2017 FileMaker, Inc.
5. Cut to the Chase: What we do
Close by suggesing an action
- Instead of suggesting more communication or asking open ended questions
Close by asking “binary quesions”
- Questions that can be quickly answered with Yes or No
- Or can be answered by clicking a link or making a purchase
When we have to discuss schedules, we use “time words”
Time Words: https://dayback.com/time-words/

39. #FileMakerDevCon© 2017 FileMaker, Inc.
5. Cut to the Chase: Problems solved
Get paid sooner
Agree to schedules in fewer emails
Correspondence becomes much easier to read in retrospect

40. #FileMakerDevCon© 2017 FileMaker, Inc.
5. Cut to the Chase: Tips
Put revenue first: you can discuss everything else later
Add decision links instead of asking for a decision
- GoToMeeting invitation
- Purchase hours, pay the invoice, approve the mockup
Video is great way to shorten the email loop
- “Bias for video”
Bias for action: https://www.amazon.jobs/principles

41. #FileMakerDevCon© 2017 FileMaker, Inc.
What Works?
“Cutting to the chase works”
- You get paid faster, get the OK faster, get replies faster,
- With less miscommunication.
- And you reply faster, because shorter emails are easier to write.

42. #FileMakerDevCon© 2017 FileMaker, Inc.
6. Unknown vs Blocking
How to run fast in the dark

43. #FileMakerDevCon© 2017 FileMaker, Inc.
6. Unknown vs Blocking: What we do
When we’re checking on on a sprint, we ask:
- What’s done vs undone
- And for what’s undone, what of that is unknown.
For the unknown, we ask if it’s a blocker.

44. #FileMakerDevCon© 2017 FileMaker, Inc.
6. Unknown vs Blocking: What we do
The Feature
Done Undone
Known Unknown
Not Blocking Blocking

45. #FileMakerDevCon© 2017 FileMaker, Inc.
6. Unknown vs Blocking: What we do
The Feature
Done Undone
Known Unknown
Not Blocking Blocking

46. #FileMakerDevCon© 2017 FileMaker, Inc.
6. Unknown vs Blocking: Problems solved
Surface unknowns early and ask for help
- Customer, stack overflow, API author, etc.
- Help is often asynchronous
- Catch them early and they don’t become blockers
Good technique for reducing fear and paralysis

47. #FileMakerDevCon© 2017 FileMaker, Inc.
6. Unknown vs Blocking: Tips
Easier to see unknowns if they are expressed as cases
- vs running into “the wall” when you’re coding
Creates two definitions of “blocking”
- blocking my work, blocking shipment
- hint: it’s almost never blocking shipment

48. #FileMakerDevCon© 2017 FileMaker, Inc.
Thank You!
Please remember to fill out the session evaluation at:
www.filemaker.com/devcon/evaluations
FILEMAKER DEVCON 2017
JULY 24 - 27, 2017 | PHOENIX, AZ