As with most things in life, there are two opposing schools of thought when it comes to software. When it comes to the size of things you can either go big or small. Is your app going to have a large scope or small scope? Is it going to target the general market or a particular niche?

When I started work on Code Collector Pro 1.4 over the weekend I was confronted by the issue of whether to go big or small on two key points: the size of updates I release and the size of the classes I write. These are key decisions that affect all the software we write, so it is worth deliberating over them. Now these aren't questions I've only just asked, they are ones I've looked at continuously and am only just starting to set myself on.

Release sizes

There are two extremes to software release size. At the large end of the scale are products like Adobe Creative Suite, Microsoft Office and Apple's iWork and iLife suites. They have a release roughly every 1-3 years and they feature large updates to several applications. At the smaller end of the scale are products like WebKit or Adium, where small releases are made every day in the form of nightly builds.

Most Mac devs go for the middle ground of this, releasing several medium sized updates a year, though what constitutes a "medium sized" update varies widely. I've been striving to reach the smaller end of the scale with little success until now. The combination of full time education limiting coding time, and a lack of discipline when building releases has led to a series of sporadic releases that are quite large.

With Code Collector Pro 1.4 there was a long list of features building up. There hasn't been a release for 14 months and the featured planned involved would take a good 3-4 months to complete. The release eventually included a UI overhaul, new sharing features, syncing and a re-written syntax highlighting engine.

So I opted to break it up into smaller releases. The UI overhaul is a collection of many small changes and some under the hood changes and nicely separates into a different release. Sharing improvements and syncing were the two major features I wanted for 1.4, so these would fit nicely into a second release. And the syntax highlighting improvements would also fit nicely into a small release. As such the large 1.4 now became much smaller versions 1.4, 1.5 and 1.6.

The current plan is to work on 1.5 straight after releasing 1.4. But why not then combine them? Well there are 3 main reasons not to:

• Syncing and sharing will take 1-2 months to implement, but the UI improvements can be done in a few weeks. As they are the low hanging fruit I would most likely do them first. So why have those improvement sitting around on my computer for a few months when I could ship them to users?
• Smaller releases often lead to a better feeling of productivity. You do have more time taken up by prepping for release, but you feel like you are getting somewhere much faster. It's easier to climb up a set of stairs than a cliff face.
• Releases = money. Whenever you make a release people see it on download sites and news sites. This leads to people downloading the app and then ultimately buying it. The more people buying your software the more people spreading word of mouth advertising and the more sales you get. Ultimately each release is an extra boost of energy into a positive cycle.

Class Size

For those of you who aren't programmers a brief explanation. A class is a unit of code. It contains data and actions upon that data. While not always true, generally a class = a separate file of code. As with release sizes you can either have a few large classes or lot of small classes. Cocoa provides ways to help you divide your code up. Code relating to windows goes into Window Controller classes, code relating to any documents goes into your Document class.

Prior to OS X 10.5 there was a missing piece of the puzzle though. While you could easily split up your application into windows, it was harder to split up these windows into individual views. Then in 10.5 Apple introduced NSViewController, which made this task easy. This means you can split your UI up into even small classes, which leads to easier to maintain code and more reusable code.

As an example, these are the window and view controllers that make up a typical screen in Minim:

As you can see, this one screen has 4 main components. The window, which contains a sidebar and an info panel, the latter of which contains the current tab. Each of these is coded in a separate file. This means that if I need to edit something to do with the sidebar I open the sidebar view controller's file. It also makes things more re-usable. There is a file that contains the file manager view controller class. This same class is used for songs, podcasts, albums and shows.

Now Minim is build with Leopard in mind. Code Collector Pro however is very much a Tiger era application in its design. This is what Code Collector Pro's main window looks like from a class point of view:

There is one class that manages the window, the sidebar, the snippets list and the code view. It even controls the inspector panel. At 2420 lines long it is the second biggest class in any M Cubed app, beaten only by the class that talks to Lighthouse in Lighthouse Keeper. That over 3 times the size of the biggest class in Minim.

Now while a large class isn't necessarily a bad thing, a large class that does lots of different things is. If I want to edit something to do with the sidebar in CCP I've got to search through 2400 lines of code to find what lines are relevant, compared to Minim where I open a file where all the lines are relevant.

I'm currently working through the process of breaking up this monolithic class into much smaller, more manageable chunks. I've already managed to split it into 7 classes, I may be able to divide those even further. Ultimately though, this will add nothing new to the application. It will work exactly the same as it did before. What it does do is make it easier to add new stuff in the future.

It's How You Use It

So does size matter? Well as the title of the post suggests, it does. But what is a good size depends on many things. To quote Albert Einstein, "Everything should be made as simple as possible, but not one bit simpler". You should strive to make things as small as you can, but not unnecessarily. While I can break one large class up quite easily, another may not break up. It may be the case that it is already as small as it needs to be.

The same goes for releases. I can split up what was going to be CCP 1.4 into 3 different versions quite easily, they logically split up. However, Minim 2.0 couldn't have been split up. It was a large project, but it couldn't have been made any smaller. Everything has its size, the job of anyone creating something, be it a piece of code, a product or a business, is to find the right size.

Comments (3)

---

Page 1 of 1 pages