MacGourmet 2: A Development Post-Mortem
It's always my intent to document the process of development here, and one good point to do this is always after a new major version is released. A post-mortem is a great way to look back at what went wrong and what went right in a development process.
Looking back, now that MacGourmet 2 is out, I can say that things took longer than I intended them to take. What caused this? Well version 2 had two major internal changes that took a lot of the development time. The first was the switch to the latest version of the SQLite database. Why was the switch made at all? Well the new database format needed to store a lot more information in version 2. SQLite 3 is also much faster and generates a much cleaner, smaller database file, in addition to being the version that Apple is using for CoreData (MacGourmet still uses its own version of SQLite because it predates CoreData by probably close to 2 years). Doing this, unfortunately required migration from one database to another, which wasn't trivial. This has to be done right, and it has to be tested, tested, tested. This was why there was a somewhat lengthy closed beta. This had to be right before released into "the wild."
The second major change was brought about because I added customizable table columns in the recipe box. This necessitated a switch in functionality between the "My Lists" section on the left and the list of items on the top right. This kind of needed to be done already because, since the time when MacGourmet was first created (MacGourmet was started around October of 2003, and it's first public release was in June of 2004), Apple has added sublists to the source list on the left of their iApps. When version 1 was created, every iApp was limited to one level in the source list. What did this mean? Well it meant a lot of recoding and a lot more testing. These interactions, drag, drop, selections, are probably the most involved.
What else caused a delay? Well Apple announcing Intel Macs at Macworld 2006 and shipping them in February greatly sped up my plan as to when I was going to do all of my universal binary work. They had originally said that there would be no Intel Macs until around July. MacGourmet 1 benefited, because I had a universal version available a lot earlier than I had expected, but it also set back other development. I was almost hoping that only version 2 was going to need to be a universal binary.
Making MacGourmet universal actually wasn't that bad, the hardest problems were with 3rd party products I use. I had to wait for eSellerate to update their framework, and when they did, they required a switch to a different SDK, so that was a project I wasn't expecting to have to spend time on. Because I use my own SQLite build, I also had to build both SQLite 2 and SQLite 3 as universal binaries. Again, more work I would have preferred not to do when I did it.
Another thing that took a lot of time? All of the new themes. I tried to offload these, and actually did offload a lot of the graphic design, but in the end, I wound up doing all of the html and CSS for them myself, because, well they needed to be done, I knew I could do them, and I got tired of waiting for someone else to do them. I'm kind of like that. I'm a firm believer in "if you want something done, and done right, you often have to do it yourself." I'm working on offloading more of this stuff so that I can write more code.
Finally, an all new version requires new documentation, a new site, and new packaging (in my case, as I have a CD edition available). Like most indie developers I do a lot of this work myself... and unlike writing code, working on these tasks, at least to me, is like having teeth pulled. I offload what I can, like graphic design, but I can be kind of a control freak, so if I need something done, and I'm able to do it, I wind up just doing it, but this all takes time. I need to offload more of this in the future, and again I'm working on that.
So, nothing really went terribly wrong, so what went right? Well one thing that springs to mind is the beta test. The people who downloaded and used the beta did a tremendous job helping get things ready to ship. Feedback was great. A lot of people seemed to be new to beta testing so I think next time I may need to add a primer on the process for first timers. Why do I say this? Well a surprising number of people wrote to me worried that the beta expiration date would leave them without the use of their application. At least with the way I run things, this will never happen. There will always be an update out prior to expiration that at the very least extends the beta period.
One thing I will say is that doing an all-new version 2 is a lot different from doing a version 1. For one thing, while you are working on the new version, people are still buying, using and needing help with the current version. This can be a time-sink and it was a challenge to balance the two some times.
Some additional release-related quickies to remember the next time I do a major version release:
Looking back, now that MacGourmet 2 is out, I can say that things took longer than I intended them to take. What caused this? Well version 2 had two major internal changes that took a lot of the development time. The first was the switch to the latest version of the SQLite database. Why was the switch made at all? Well the new database format needed to store a lot more information in version 2. SQLite 3 is also much faster and generates a much cleaner, smaller database file, in addition to being the version that Apple is using for CoreData (MacGourmet still uses its own version of SQLite because it predates CoreData by probably close to 2 years). Doing this, unfortunately required migration from one database to another, which wasn't trivial. This has to be done right, and it has to be tested, tested, tested. This was why there was a somewhat lengthy closed beta. This had to be right before released into "the wild."
The second major change was brought about because I added customizable table columns in the recipe box. This necessitated a switch in functionality between the "My Lists" section on the left and the list of items on the top right. This kind of needed to be done already because, since the time when MacGourmet was first created (MacGourmet was started around October of 2003, and it's first public release was in June of 2004), Apple has added sublists to the source list on the left of their iApps. When version 1 was created, every iApp was limited to one level in the source list. What did this mean? Well it meant a lot of recoding and a lot more testing. These interactions, drag, drop, selections, are probably the most involved.
What else caused a delay? Well Apple announcing Intel Macs at Macworld 2006 and shipping them in February greatly sped up my plan as to when I was going to do all of my universal binary work. They had originally said that there would be no Intel Macs until around July. MacGourmet 1 benefited, because I had a universal version available a lot earlier than I had expected, but it also set back other development. I was almost hoping that only version 2 was going to need to be a universal binary.
Making MacGourmet universal actually wasn't that bad, the hardest problems were with 3rd party products I use. I had to wait for eSellerate to update their framework, and when they did, they required a switch to a different SDK, so that was a project I wasn't expecting to have to spend time on. Because I use my own SQLite build, I also had to build both SQLite 2 and SQLite 3 as universal binaries. Again, more work I would have preferred not to do when I did it.
Another thing that took a lot of time? All of the new themes. I tried to offload these, and actually did offload a lot of the graphic design, but in the end, I wound up doing all of the html and CSS for them myself, because, well they needed to be done, I knew I could do them, and I got tired of waiting for someone else to do them. I'm kind of like that. I'm a firm believer in "if you want something done, and done right, you often have to do it yourself." I'm working on offloading more of this stuff so that I can write more code.
Finally, an all new version requires new documentation, a new site, and new packaging (in my case, as I have a CD edition available). Like most indie developers I do a lot of this work myself... and unlike writing code, working on these tasks, at least to me, is like having teeth pulled. I offload what I can, like graphic design, but I can be kind of a control freak, so if I need something done, and I'm able to do it, I wind up just doing it, but this all takes time. I need to offload more of this in the future, and again I'm working on that.
So, nothing really went terribly wrong, so what went right? Well one thing that springs to mind is the beta test. The people who downloaded and used the beta did a tremendous job helping get things ready to ship. Feedback was great. A lot of people seemed to be new to beta testing so I think next time I may need to add a primer on the process for first timers. Why do I say this? Well a surprising number of people wrote to me worried that the beta expiration date would leave them without the use of their application. At least with the way I run things, this will never happen. There will always be an update out prior to expiration that at the very least extends the beta period.
One thing I will say is that doing an all-new version 2 is a lot different from doing a version 1. For one thing, while you are working on the new version, people are still buying, using and needing help with the current version. This can be a time-sink and it was a challenge to balance the two some times.
Some additional release-related quickies to remember the next time I do a major version release:
- Don't pick the week of Macworld, unless you're showing AT Macworld. Too much news, and the minute your news release is posted, it's pushed off the front page by the myriad of posts after yours. Pick a slower news time if you can. If you DO pick this week, send your release later in the day, EVERYONE seems to post in the morning, so your release disappears that much quicker.
- If you are dropping version support for an old version (in MacGourmet's case, 10.3.9), even if the update is free, you can't display this information in enough places. People will still download it, run it and wonder why it doesn't work. Big stickers screaming "THIS REQUIRES MAC OS 10.4 OR LATER" would probably help, but probably not.
- Pray, PRAY that all of your systems cooperate. The day of the release the websites went down, and from 2PM that day until about 24 hours later, for some reason I wasn't been able to talk to my POP server to get my email in my normal way. Then, I went into the office, and found no network at all. Frustrating.
Labels: Musings
2 Comments:
Thanks for blogging about this. Sad to say, but sometimes it's really encouraging to hear that things don't always go as planned, even for great products like MacGourmet. Maybe there's hope for my stuff too. :-)
Congratulations on the new release! It looks great!
Thanks for sharing.
Post a Comment
<< Home