Build times

On your next project, seriously consider mandating a maximum build time of (say) fifteen minutes.

Then hire someone – very early on – to keep it that way.

(taps foot)

(stares at photos of family on desk)

(gets coffee)

(doesn’t open up a browser and read slashdot)

(cracks open that book on file systems again.  watches build oozing its way up the screen.  i swear it gets slower every time.  one chapter.  two chapters…)

SOMEBODY BROKE THE BUILD

fix it

(taps foot)

(slashdot)

 

This entry was posted in Rantage. Bookmark the permalink.

0 Responses to Build times

  1. John Feagans says:

    The correlary to build times is the boot time must be less than the build time. Both need to be under 15 minutes. Try to build, download, and boot a router at a big Silly Valley company and you are facing serious caffeine overdose.

  2. landon says:

    Right. When I left Atari (and you folks!) to Apple, I ran into a sign in the Apple OS group’s area saying “Time to boot tripled!” — apparently they’d gotten sloppy, and were trying to use self-shaming to fix things.  This was system 6, I think.

    Similar deal with a scrolling LED message board in the Newton group (“Attention all, Please Remove Your Shorts,” referring not to articles of clothing, but rather that the ARM compiler generated *terrible* code for 16 bit values).

    Correlary to the correlary is the ability to quickly install the project and start running unit tests, as this cycle largely dominates late and time-critical development.  Sub-ten-seconds would be good for this (thank goodness “file copy install” is coming back in style). If these *have* to be lengthy processes, then they *must* be hands-off and automatable.  It sucks to be under a deadline and waiting for a miserable download to finish (some set top boxes I was working on a while back were *worse* to work on than just burning ROMs, as we did on the ST).

    Three day server installs (by gurus in robes, sacrificing chickens every time they edit a “user friendly” XML configuration file) are right out.

    If you wonder why a product came out crappy, it might be interesting to look at (a) the development environment, and (b) did the team working on the product have a chance to really use it?  The best feedback is self-critical feedback (“I have to fix this channel change time or I will go insane” . . . typeTypeType . . . “Whew!”).  I’ll be a lot of good products have had quite a few somewhat selfish “Whew” moments.

  3. 15 minutes! *Wince*

    Man, the holy grail of software development is shortest possible turnaround time: diagnose/code/build/test/debug. “What the heck was I working on when I started the build?”

    I suppose this is why I dislike big systems…

    No wonder landon reads so many novels…

  4. John Feagans says:

    Back on the topic of boot times. One of the things I will take credit for is insisting on ROM code in the ST. But remember how horrible this was at CES in 1985 when we booted CP/M! Thank heavens we shipped with Jason DOS.

    Horrible boot time today? My Samsung HDTV tuner. You push the remote and it is 30 seconds before you cna tune the station.

    Next horrible time? Waiting for my Canon DSLR to boot so I can take a picture. Weren’t cameras supposed to work that you wound the film and clicked the button?

    What about cell phones that take 30 seconds to boot and be usable? The old model was you picked up the phone and dialed the number.

    I’ve noticed the cars lately have to boot…

  5. landon says:

    Yeah, the ST booted in under two seconds (the last time I tried it I thought the switch was borken. Nope. I hit it like twenty times, just watching the boot cycle. Glorious). Even with a hard disk attached, I never saw an ST boot that was over ten seconds. Today’s PC BIOSes don’t even approach that. (There is at least one project to put Linux in the BIOS flash of a PC).

    [I was talking about 15 minute full buld times, btw. Sub-ten-second turnaround is what I have on most of my projects right now, unless you include the horrible integration into our main code base.]

  6. John Feagans says:

    How on earth did we do our version control and branch strategy on the ST? We had a very large group of 30 or so engineers and it didn’t seem to have the problems of someone checking in code and breaking the build. Now it is in this large Silly Valley company soeone creates a local file, commits their code, and the build is broken.

  7. landon says:

    Our source control wa a guy named Mike Schmal.

    Built like a biker. You didn’t piss him off.

    [Actually a really nice guy.]

  8. John Feagans says:

    I hired Mike for a project at Commodore. I remember he had a German Shepard he kept in his office in the KMST building (now TV station KION), that was an annex to the DRI offices in Monterey. He had the baby gates so he could keep the door open and the dog inside. Lou and the other DRI managers barely tolerated us. My office was on the other side with Jason and Lowell Webster. Dave Staugus took a group picture of us n front of the office with his 4×5 film camera. Do you still have a print? I do.

  9. John Feagans says:

    The dogs name was divit. The code word for attack was “get the flea”. We played with the pup for hours in the parking lot.

Leave a Reply

Your email address will not be published. Required fields are marked *