i can slack off my code s compiling n.
Skip this Video
Loading SlideShow in 5 Seconds..
I Can Slack Off, My Code’s Compiling PowerPoint Presentation
Download Presentation
I Can Slack Off, My Code’s Compiling

Loading in 2 Seconds...

play fullscreen
1 / 41

I Can Slack Off, My Code’s Compiling - PowerPoint PPT Presentation

  • Uploaded on

I Can Slack Off, My Code’s Compiling. Comic and title care of XKCD.com. Who am I?. Jeff Ward Lead Architect Orbus Gameworks. IGDA Tools SIG Chair Author: The Toolsmiths www.thetoolsmiths.com. What this talk is about. The Big Question.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'I Can Slack Off, My Code’s Compiling' - suzuki

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
i can slack off my code s compiling
I Can Slack Off, My Code’s Compiling

Comic and title care of XKCD.com

who am i
Who am I?

Jeff Ward

Lead Architect

Orbus Gameworks

IGDA Tools SIG Chair

Author: The Toolsmiths


the big question

The Big Question

How much time and money is lost just waiting for a build?

how long is your build
How long is your build?

To answer this question, you need to know:

how long is your build1
How long is your build?
  • On average?
  • For a complete rebuild?
our build includes unit tests
Our build(includes unit tests)
  • CPP Libraries (vs2003, 2005, 2008): 00:36:24
  • C# Libraries: 00:00:27
  • Java Libraries: 00:00:04
  • Python Libraries: 00:00:01
now that you know that
Now that you know that…
  • How long is your average incremental build?
  • How many times, per day, is your programmer going to perform that build?
  • By how much can you improve that?
  • The difference is wasted time!!!
why know that

Why know that?

It’s all about the Benjamins.

the money assumptions
The Money Assumptions
  • A 52 week year
  • A 5 day work week
  • A $62k average salary (~$30/hr)
  • This does not include other overhead for a programmer.
this means that over a 2 year project
This means, that over a 2 year project…

…you can lose approximately $468,000, the cost of 2 lead programmers, to build times.

you programmer burn cont
You Programmer Burn (cont.)
  • Two way to look at these numbers:
    • Money Lost (in programmer productivity time)
    • Money Saved (by increasing productivity time)
saving money saving time
Saving Money, Saving Time
  • Faster builds save more than just build time
    • Keeps programmers from task switching
    • Keeps you in the groove
  • Faster builds encourage quick iteration
    • Which encourages more testing
fixing programmer burn easy
Fixing Programmer Burn (Easy)
  • Parallelize your build (Incredibuild, distcc etc)
    • Very Little investment, can see huge returns
    • Little to no programmer involvement (unless you’re switching build systems)
fixing programmer burn easy1
Fixing Programmer Burn (Easy)
  • Dedicate more hardware
    • 2 programmers wasting 30 minutes per day pays for a beefy server.
    • Little to no programmer involvement, instant returns
    • 2 programmers wasting 30 minutes per day costs you $7800, which buys one beefy server
fixing programmer burn medium
Fixing Programmer Burn (Medium)
  • Fix dependencies, modularize code
    • Modularized code is faster to compile and easier to test
    • Reduce dependencies between modules.
    • Minimize unnecessary includes, use forward declarations.
    • Make your inheritance chains shallow.
fixing programmer burn medium1
Fixing Programmer Burn (Medium)
  • Use Precompiled Headers (when you can)
    • Don’t put every header into precompiled headers. It’s silly and it annoys programmers more than anything else
    • Only place header that are significantly large, used very frequently, and unlikely to change
    • Put in guards to avoid PCH dependence
fix programmer burn hard
Fix Programmer Burn (Hard)
  • Use a fast compiling or interpreted language in high level code, one that doesn’t require includes or linking.
    • C#, Lua, Python, JavaScript, Scheme, UnrealScript?
fix programmer burn hard1
Fix Programmer Burn (Hard)
  • Refactor code into individually testable libraries
    • Makes much of your code reusable
    • Allows testing of single library units
    • Can shorten iteration time on that library / unit
    • Going too crazy with this can increase link times
fix programmer burn hard2
Fix Programmer Burn (Hard)
  • Move libraries that don’t change out of your build process
    • Goes with modularizing your libraries.
    • Allows testing of individual modules to be issolated.
    • Beware this suggestion. Frequently teams that do this mistakenly think “rarely edited” means “never edited”
you re so vain

You’re so vain…

Bad builds aren’t just about lost programmer time

deployed builds
Deployed Builds
  • Broken Builds vs. Bad Builds
  • Important to consider when they affect the productivity of the team
    • If a team can’t work because of a because the build is bad, this is all lost time.
jeff s tenets of good builds


Jeff’s Tenets of Good Builds
  • Be fast
  • Be automated
  • Keep the team informed
  • Leave little room for human error
  • Prevent “bad builds”
these points are things to strive for
These points are things to strive for

… for some of them, you’ll never get there.

be fast
Be fast
  • Use continuous integration to build on each check-in, unit test all builds, and analyze code.
  • Create up to date and optimized assets on each check-in
  • Build assets incrementally, use source control to trigger only specific builds in assets
  • Use dependency trees to figure out what needs to be rebuilt as a result of asset changes.
be automated
Be Automated


  • Have check-ins occur at the lowest possible point, automate the rest.
    • This means max, maya, psd.
  • Automate informing the team of changes
  • Automate testing
    • Unit, functional, approval, monkey
  • Automate approval and deployment of good builds
    • Where it makes sense
corollary remove things that are slow
Corollary: Remove things that are slow
  • Integration tests
    • CPP: 00:09:14
    • CS: 00:00:13
    • Generator: 00:16:26
    • Java: 00:15:44
  • Smoke Tests
  • Developer Approval
keep the team informed
Keep the Team Informed
  • How long until the next build?
  • What changes does the next build include?
  • Do I need this build?
  • The team should know builds are bad BEFORE they get it.
human error
Human Error
  • Automate export and build.
    • This reduces human interaction, and prevents build inconsistencies.
  • Isolate mistakes from the rest of the team
    • We all make mistakes, we all check in bad code or bad assets
    • Keep these changes from dispersing in the wild, which would cause hours of wasted time.
create a pipeline
Create a Pipeline
  • A build is not one step!
    • Get from source control
    • Build
    • Automated Unit Tests
    • Automated Integration Tests
    • Deploy to team
    • QA Smoke Tests
    • User Tests
    • Deploy to testers
    • Deploy to beta
    • Deploy to production
per project vs per company
Per Project vs. Per Company
  • Most code optimizations are project based.
  • Pipelines can be reused
your programmer burn
Your Programmer Burn
  • Creating your build system takes time.
  • Time saved > Time spent
    • This makes sense only on large projects losing lots of time to builds
  • Don’t slack
build complete

Build Complete