On Tuesday, October 28, 2003 I was in Santa Clara, CA for the O'Reilly Mac OS X Conference. I was also in a session that day called "Incredibly Obvious Software Development Secrets" which was given by Steve Kalkwarf, who works for Bare Bones Software- makers of the great text editor BBedit (which I happened to be using to write this page). The session was billed as "... session will provide specific examples of development processes and techniques used at Bare Bones Software that allow a small team of developers to produce top quality software."
Since I have absolute respect for the programmers of Bare Bones and BBEdit, this was something that I could absolutely not miss out on attending.
Just a quick note- most of this was done from memory, but I did actually also write down some of what he said while I was in the session. I also used the powerpoint slide as a reference, which can be downloaded from here: http://conferences.oreillynet.com/presentations/macosx03/kalkwarf_steve.ppt.zip.
Steve started the talk giving a little bit of history about himself. He used to work for Apple in a small group that basically went around speeding up code and fixing stuff wherever it was needed. And as such he had access to every single source file that made up Mac OS (this was back in the os 8/9 days). No piece of software was off limits to him and his team members. That must have been cool... However, he eventually moved on and went to work for Bare Bones.
His presentation had 4 basic points-
- Be Lazy
- Use the Tools
- Code Responsibly
- Ship Solid
Under "Be Lazy" he outlined some obvious things that you need to do-
• Source Control- Use this to keep archives and versions of your code. Absolutely necessary in case you need to make a fix to an old development branch and such. They use Perforce, but he also pointed out CVS (which I use and is free) and Projector.
• Bug Tracking- He said that alot of people use Email, but it seems that bugs can get lost in the volume. They also have a white board where they put their "Top-N List" where they have the top 10 issues that need to get done in the next version of BBEdit or Mailsmith. At Bare Bones they use FogBUGZ for their bug tracking because it is a pretty good platform to track issues in, and integrates with their version control system, Perforce. Unfortunately it only runs on windows.
Next up was "Use the Tools".
• They turn on all warnings in their compilers. This way they won't make any little mistakes- and if a warning shows up you won't miss it. He said you might have to move some code around to get it to compile it without warnings, but in the end it's well worth it.
• Performance tools- Use performance tools to figure out where exactly things are going wrong. You can't speed up something if you don't know where it's slow.
• Use multiple compilers. You're project might not always link, but each compiler will find different errors. GCC, Metrowerks, etc...
"Code Responsibly"
• Treat cleanup as a first-class task. Don't leave cruft hanging around when newer and updated methods have been made. This is probably why they were able to port BBEdit to OSX so fast.
• Keep comments relevant- don't change the code and not update the comments that go along with it. They had a programmer who seemed to do this alot- he got fired.
• Code defensively- remember to always check return codes and such. He also pointed out <CarbonCore/Debugging.h> and that it had lots of great macros that you can use to help the debugging process. (Update: Steve wrote me and pointed out that it was Debugging.h and not Debug.h (like I originally had). He also said there was some interesting stuff in </usr/include/AvailabilityMacros.h>. I'll have to check it out.)
• Leave your ego at the door. This was my favorite. He talked about how nobody "owns" any one piece of code. If you find a bug, fix it- don't send emails back and forth saying "could you please commit this patch" and so on. He also talked about how Jim (another programmer) "fixes the fixes"- meaning he might reformat it to their coding standards if it doesn't look just right.
"Ship Solid"
• Enforce code freeze discipline - They wait a full 2 weeks before they ship BBEdit and it's last final candidate. If a bug is found and it has to be fixed right away, they start the clock over and wait another 2 weeks.
• Build integral test suite- Steve pointed out that they have a "Debug" menu for development builds, where they put in unit tests and such- the items under this menu come and go in the development process depending on what they are testing.
• Use your own product- He talked about how the programmer that got fired worked on Mailsmith, but never actually used it. He would only test with 10 or so messages in his inbox and verify that it worked. Their customers had alot more messages than that.
He added one more bullet point at the end- "Have Fun". If you don't enjoy you're work, you aren't going to do a good job at it- so why even bother?
Later on that day (or it might have been the next) I went up to their booth to talk to him a little bit more about some of the macros they use and such. During the presentation he came off like an Army Sergeant- it was kind of amusing. When I started talking to him at the booth he was initially that way, but he began to lighten up a little bit as the conversation went on. Jim Correia (another one of the programmers on the team) was sitting behind the booth typing away as I was listening to Steve, and I look over and he's typing out some example code which was relevant to what we were talking about. Cool! Then all of a sudden Steve goes "You want a t-shirt?". I was kind of stunned for a second because I was thinking about the code and such and then I came to my senses. "Yea!". Hell yea I want a t-shirt.
Kirstin hiding behind the t-shirt!
It was alot of fun, and it gave me lots to think about. I'm going to try and adopt everything he suggested to the development of my products- and I hope to eventually come up a list of my adapted development rules of my own to put on the net.
Thanks Steve!
Since I have absolute respect for the programmers of Bare Bones and BBEdit, this was something that I could absolutely not miss out on attending.
Just a quick note- most of this was done from memory, but I did actually also write down some of what he said while I was in the session. I also used the powerpoint slide as a reference, which can be downloaded from here: http://conferences.oreillynet.com/presentations/macosx03/kalkwarf_steve.ppt.zip.
Steve started the talk giving a little bit of history about himself. He used to work for Apple in a small group that basically went around speeding up code and fixing stuff wherever it was needed. And as such he had access to every single source file that made up Mac OS (this was back in the os 8/9 days). No piece of software was off limits to him and his team members. That must have been cool... However, he eventually moved on and went to work for Bare Bones.
His presentation had 4 basic points-
- Be Lazy
- Use the Tools
- Code Responsibly
- Ship Solid
Under "Be Lazy" he outlined some obvious things that you need to do-
• Source Control- Use this to keep archives and versions of your code. Absolutely necessary in case you need to make a fix to an old development branch and such. They use Perforce, but he also pointed out CVS (which I use and is free) and Projector.
• Bug Tracking- He said that alot of people use Email, but it seems that bugs can get lost in the volume. They also have a white board where they put their "Top-N List" where they have the top 10 issues that need to get done in the next version of BBEdit or Mailsmith. At Bare Bones they use FogBUGZ for their bug tracking because it is a pretty good platform to track issues in, and integrates with their version control system, Perforce. Unfortunately it only runs on windows.
Next up was "Use the Tools".
• They turn on all warnings in their compilers. This way they won't make any little mistakes- and if a warning shows up you won't miss it. He said you might have to move some code around to get it to compile it without warnings, but in the end it's well worth it.
• Performance tools- Use performance tools to figure out where exactly things are going wrong. You can't speed up something if you don't know where it's slow.
• Use multiple compilers. You're project might not always link, but each compiler will find different errors. GCC, Metrowerks, etc...
"Code Responsibly"
• Treat cleanup as a first-class task. Don't leave cruft hanging around when newer and updated methods have been made. This is probably why they were able to port BBEdit to OSX so fast.
• Keep comments relevant- don't change the code and not update the comments that go along with it. They had a programmer who seemed to do this alot- he got fired.
• Code defensively- remember to always check return codes and such. He also pointed out <CarbonCore/Debugging.h> and that it had lots of great macros that you can use to help the debugging process. (Update: Steve wrote me and pointed out that it was Debugging.h and not Debug.h (like I originally had). He also said there was some interesting stuff in </usr/include/AvailabilityMacros.h>. I'll have to check it out.)
• Leave your ego at the door. This was my favorite. He talked about how nobody "owns" any one piece of code. If you find a bug, fix it- don't send emails back and forth saying "could you please commit this patch" and so on. He also talked about how Jim (another programmer) "fixes the fixes"- meaning he might reformat it to their coding standards if it doesn't look just right.
"Ship Solid"
• Enforce code freeze discipline - They wait a full 2 weeks before they ship BBEdit and it's last final candidate. If a bug is found and it has to be fixed right away, they start the clock over and wait another 2 weeks.
• Build integral test suite- Steve pointed out that they have a "Debug" menu for development builds, where they put in unit tests and such- the items under this menu come and go in the development process depending on what they are testing.
• Use your own product- He talked about how the programmer that got fired worked on Mailsmith, but never actually used it. He would only test with 10 or so messages in his inbox and verify that it worked. Their customers had alot more messages than that.
He added one more bullet point at the end- "Have Fun". If you don't enjoy you're work, you aren't going to do a good job at it- so why even bother?
Later on that day (or it might have been the next) I went up to their booth to talk to him a little bit more about some of the macros they use and such. During the presentation he came off like an Army Sergeant- it was kind of amusing. When I started talking to him at the booth he was initially that way, but he began to lighten up a little bit as the conversation went on. Jim Correia (another one of the programmers on the team) was sitting behind the booth typing away as I was listening to Steve, and I look over and he's typing out some example code which was relevant to what we were talking about. Cool! Then all of a sudden Steve goes "You want a t-shirt?". I was kind of stunned for a second because I was thinking about the code and such and then I came to my senses. "Yea!". Hell yea I want a t-shirt.
Kirstin hiding behind the t-shirt!
It was alot of fun, and it gave me lots to think about. I'm going to try and adopt everything he suggested to the development of my products- and I hope to eventually come up a list of my adapted development rules of my own to put on the net.
Thanks Steve!
akm
people
other
im
All Things Copyright © 2001-2004 August Mueller