Successfully reported this slideshow.
Your SlideShare is downloading. ×

Increasing Code Quality While Staying Lean

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 48 Ad

Increasing Code Quality While Staying Lean

Download to read offline

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

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

Advertisement
Advertisement

More Related Content

Similar to Increasing Code Quality While Staying Lean (20)

Recently uploaded (20)

Advertisement

Increasing Code Quality While Staying Lean

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. #FileMakerDevCon© 2017 FileMaker, Inc. What Works: Strategies for Increasing Code Quality while Staying Lean What we do Problems solved Tips
  13. 13. #FileMakerDevCon© 2017 FileMaker, Inc. 1. Video Demo is the new testing.
  14. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 27. #FileMakerDevCon© 2017 FileMaker, Inc. 3. Documenting our Decisions We’re coding for our future selves.
  28. 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. 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. 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. 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. 32. #FileMakerDevCon© 2017 FileMaker, Inc. 4. Recording Technical Debt Document the path not taken.
  33. 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. 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. 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. 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. 37. #FileMakerDevCon© 2017 FileMaker, Inc. 5. Cut to the Chase Remove unnecessary back and forth by proposing closing actions first.
  38. 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. 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. 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. 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. 42. #FileMakerDevCon© 2017 FileMaker, Inc. 6. Unknown vs Blocking How to run fast in the dark
  43. 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. 44. #FileMakerDevCon© 2017 FileMaker, Inc. 6. Unknown vs Blocking: What we do The Feature Done Undone Known Unknown Not Blocking Blocking
  45. 45. #FileMakerDevCon© 2017 FileMaker, Inc. 6. Unknown vs Blocking: What we do The Feature Done Undone Known Unknown Not Blocking Blocking
  46. 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. 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. 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

Editor's Notes

  • Please do not delete or change this slide.

×