Increasing Code Quality While Staying Lean

© 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

#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

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

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.”

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

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

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?

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

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

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

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

What Works: Strategies for Increasing
Code Quality while Staying Lean
What we do
Problems solved
Tips

1. Video
Demo is the new testing.

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

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

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

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

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)

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/

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.

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)

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

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

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

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.

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.

3. Documenting our Decisions
We’re coding for our future selves.

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)

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

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

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

4. Recording Technical Debt
Document the path not taken.

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

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

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

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.

5. Cut to the Chase
Remove unnecessary back and forth by
proposing closing actions first.

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/

5. Cut to the Chase: Problems solved
Get paid sooner
Agree to schedules in fewer emails
Correspondence becomes much easier to read in retrospect

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

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.

6. Unknown vs Blocking
How to run fast in the dark

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.

6. Unknown vs Blocking: What we do
The Feature
Done Undone
Known Unknown
Not Blocking Blocking

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

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

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

Increasing Code Quality While Staying Lean

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Increasing Code Quality While Staying Lean

Ähnlich wie Increasing Code Quality While Staying Lean (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Increasing Code Quality While Staying Lean

Hinweis der Redaktion