If you’re working a regular job, you are almost always paid by the hour. Freelance work is sometimes paid by the hour, but more often the client will want you to bid a fixed price for the entire project: a ‘contract price’. And even if it is paid by the hour, the hourly rate isn’t generally a pre-determined constant – you will have to get in there and negotiate the hourly rate you deserve.

So how does one estimate a fair bid for a contract? Lets take a look at some of the most important factors to consider:

Time
The first factors to consider are how long the project will take to complete, and when the client wants it to be completed by. If the project is going to take a month, and the client wants results in a week, you probably don’t want to touch this. If it looks like a week’s work, and the client is expecting it to take 6 months, then you may be badly underestimating the amount of work.

How do you estimate how long a project will take? That comes down to practice and experience. You have worked in your field, you know roughly how long it takes you to complete each type of task – so you look at the project, break it down into its component parts, figure out how long each will take, and put it all together again. Is this difficult? Yes. Will you make mistakes? Yes. But over time you’ll learn, and we will get to dealing with mistakes in a moment.

Expenses
The next factor is direct expenses. These are the expenses incurred directly by the job: do you need to buy new tools/computer/software in order to complete the job? Will you need to buy books or training? Will you need to travel as part of the job, or commute to the client’s offices? All of this should be pretty straightforward to determine, and the prices for all of it should be easy to figure out – just add it all up.

After that comes living expenses, and these are a little more tricky: rent, utilities, cell phone bills, daily transport costs, food, entertainment… I am assuming you have a fairly good idea of your own cost of living, but if not, you need to figure this all out soonest. Once you have a good idea of your cost of living, multiply it by your time estimate, and add it to the rest of your expenses.

Taxes
So you have your expenses, and those form your bottom line: if you want to complete the job and keep a roof over your head, you have to make at least that much. But wait… The federal government wants a cut. And then there are state taxes. And social security. And don’t forget health insurance – unless you already have a full-time job in addition to your freelance work, you’ll need to pay for your own.

So you need to calculate all this up as well, and add it to your expenses. You probably already known your health insurance premiums, and there are tax and social security calculators on the internet, so this shouldn’t present much in the way of difficulties.

Profit margin
Unless you are truly desperate (and there will be times when you are desperate), you don’t want to be just barely managing to pay the bills. So we need to build some profit into this estimate. Ideally, you want to be making 30% profit or more, and obviously, the higher the better as long as the market will bear (apart from ethical concerns if you’re just ripping off the client).

Risk management
So you have your bottom line, you’ve built in a tidy little profit, but there is still the matter of risk – and there are really two issues at play here. The first is estimation error: your time estimate may not be perfect, or the project may just hit unexpected snags and expenses. And the second is part and parcel of the very nature of free lancing: this isn’t a regular job, so once the contract is over you are once again unemployed. This means that you need to account not only for living expenses during the contract, but also for living expenses while you search for your next contract. If you are lucky, you might have another contract lined up by the time you finish this one, but nothing in life is guaranteed.

So you have to build in a certain ‘buffer’ to absorb these risks. A common rule of thumb is to double your estimate, others go with 1.5x, but in the end this is a judgement call, based on your evaluation of risk. And also on your evaluation of how high you can actually bid, which brings us to…

Client expectations
At this point you hopefully have a very good idea of how much money you need to make for this contract to be worthwhile to you. So we reach what is perhaps the trickiest part of the entire process: judging how much the client is willing to pay. This is largely subjective, but it involves taking a good look at the client: does the client actually have a lot of money? Are they miserly with the money they have? Have they already budgeted a small/large amount for this project?

And very importantly: are they soliciting bids from other freelancers on this project, with which you need to compete? If you are the only person they have asked for a quote, then it often behooves you to pitch your quote a little high – you’ll have a chance to negotiate the final price. But if you are bidding against other people, then you will rarely (if ever) have a chance to submit a later counter-bid.

And that’s pretty much the gist of it – get out there and start estimating. I guarantee you’ll make mistakes, maybe take a loss on a few projects, but if you develop the knack for it, it all evens out in the end.

*A final word: subcontracting
If someone hires me to develop a website, I’m fine on the technical end of things, but I am no artist. So I’ll need to hire a graphic designer to work with me for at least a portion of the project. This is tricky: you need to factor in all the same considerations for the artist that you do for yourself – the only saving grace being that you are absorbing most of the risk, which makes their calculation simpler. My best advice is to find your subcontractor early, and communicate with them on the bidding process. They will have a better idea than you about their own time estimates and expenses.

Spirals are considerably more tractable in polar coordinates, so we start with the polar coordinate form of the logarithmic spiral equation:

(1)

Where (roughly) a controls the starting angle, and b controls how tightly the spiral is wound.

Since we are given an input point in x,y Cartesian form, we need to convert that to polar coordinates as well:

Now, we can observe that the closest point on the spiral to our input point must be on the line running through our input point and the origin – draw the line on the graph above if you want to check for yourself. Since the logarithmic spiral passes through the same radius line every 360°, this means than the closest point must be at an angle of:

(2)

Where n is a non-negative integer. We can combine (1) and (2), to arrive at an equation for r in terms of n:

(3)

Which means we can find r if we know n. Unfortunately we don’t know n, but we do know r_target, which is an approximation for the value of r. We start by rearranging equation (3) in terms of n:

(4)

Now, feeding in the value of r_target for r will give us an approximate value for n. This approximation will be a real (float, if you prefer), and we can observe from the graph above that the closest point must be at either the next larger or smaller integer value of n.

If we take the floor and ceil of our approximation for n, we will have both integer quantities, and can feed each value back into equation (3) to determine the two possible values of r, r₁ and r₂. The final step involves finding which of these is the closest, and the distance thereof:

And there you have it:

Distance field for a logarithmic spiral

The python source code below produces the image shown above, as a 1000×1000 pixel image PNM image written to stdout. If you aren’t familiar with the PNM format, it is an exceedingly simple ascii-based analogue of a bitmap image, and can be loaded directly in GIMP.

import math

def spiral(x, y, a=1.0, b=1.0):
  # calculate the target radius and theta
  r = math.sqrt(x*x + y*y)
  t = math.atan2(y, x)

  # early exit if the point requested is the origin itself
  # to avoid taking the logarithm of zero in the next step
  if (r == 0):
    return 0

  # calculate the floating point approximation for n
  n = (math.log(r/a)/b - t)/(2.0*math.pi)

  # find the two possible radii for the closest point
  upper_r = a * math.pow(math.e, b * (t + 2.0*math.pi*math.ceil(n)))
  lower_r = a * math.pow(math.e, b * (t + 2.0*math.pi*math.floor(n)))

  # return the minimum distance to the target point
  return min(abs(upper_r - r), abs(r - lower_r))

# produce a PNM image of the result
if __name__ == '__main__':
  print 'P2'
  print '# distance field image for spiral'
  print '1000 1000'
  print '255'
  for i in range(-500, 500):
    for j in range(-500, 500):
      print '%3d' % min( 255, int(spiral(i, j, 1.0, 0.5)) ),
    print

You can probably guess the next stage of this little anecdote… Office ’98 on that G3 performed ever-so-slightly worse than Office 4.0 on a truly antediluvian PowerBook 180, which sported a fantastic (for the time) 33 MHz Motorola 68030 CPU.

Now, I am not being entirely fair here – the spellchecker is much faster, the grammar checker didn’t even exist back then, and various other ancillary features have been added and improved. But the core issue remains, Office 2010 (or 2007, which is not in beta) running on a very decent gaming rig, takes longer to launch and is less responsive to keyboard input than Office 4.0 on an 33 MHz 68k.

And the problem isn’t restricted to Microsoft products alone, as many pieces of software have suffered the same sort of creep, not least among them the Mac and Windows operating systems.

In the open-source world and among smaller developers this phenomenon is far less common: a well configured linux or BSD installation boots in a handful of seconds, Blender (sporting most of the features of expensive software such as 3DS Max and Maya) launches immediately and always remains responsive, and Maxis’ Spore takes minutes to start up and load a game while Eskil’s Love throws you into the game in under 10 seconds.

My current computer is many thousands of times faster than that PowerBook 180, so in theory at least, we should be able to do far more, and do the same old things much faster. Why then the slowdown?

It can’t be lack of resources – we are talking about companies such as Microsoft, Apple and Adobe, all with enormous R&D and development budgets, and teams of experienced programmers and engineers. Besides, the open-source guys manage just fine, some with just a handful of programmers, and most with no budget whatsoever.

It has been argued that programmer laziness (a.k.a. badly educated programmers) are to blame, but I am not sure this can be the entire story. Certainly the ‘dumbing down’ of University-taught computer science hasn’t helped, nor has the widespread rise of languages that ‘protect’ the programmer from the hardware, nor the rise of programming paradigms that seek to abstract away from low-level knowledge. But that is the topic of another rant, and is somewhat tangential to the topic at hand. Companies can afford to hire the best programmers, and could if they wanted to, create the demand necessary to reform education practices.

And that brings us to the real heart of the issue: software developers measure success in terms of sales and profit. As long as your software sells, there is no need to spend money on making the software perform better. And if you happen to have a virtual monopoly, such as Microsoft’s Office or Adobe’s Photoshop, then there is no incentive to improve the customer’s experience, beyond what is needed to sell them a new version each year.

However, when you lose such a monopoly, the game changes, and it generally changes for the better. When FireFox, Opera and later Safari started cutting a swathe into Microsoft’s Internet Explorer monopoly, Microsoft was forced to adapt. The latest version of Internet Explorer is fast, standards compliant, and relatively free of the virus infection risks that plagued earlier versions.

This outcome of the browser war has led at least a few to the conclusion that open-source is the answer, and that open-source will inevitably recreate what has been developed commercially, and either surpass that commercial product, or force it to evolve. Sadly, I don’t see this happening particularly quickly, or on a wide scale – OpenOffice is playing catch-up in its efforts to provide an out-of-the-box replacement for Microsoft Office, GIMP lags far behind Photoshop, and linux, despite widespread adoption in a few key fields (namely budget servers and embedded devices) still lags far behind Windows and Mac in many areas.

For many years this wasn’t a problem – every few years you would buy a new computer, typically an order of magnitude faster than the computer it replaced. If new versions of your software consumed a few million more cycles, well, there were cycles to burn, and besides, the hardware companies needed a market for faster computers, didn’t they?

Nowadays the pendulum is swinging in the opposite direction. Atom powered netbooks, Tegra powered tablets, ARM powered smartphones – all of these promise a full computing experience in tiny packages with minimal power consumption. Even though the iPhone in your hand is considerably more powerful than that 33 MHz PowerBook 180, it doesn’t have even a fraction of the computing power offered by your shiny new laptop or desktop. And users expect a lot more than they did in the early nineties – animated full colour user interfaces, high definition streaming video and flash applications, oh, and don’t drain the battery!

CPU cycles today are becoming as precious as they ever were, only now many of our programmers have no experience of squeezing every last drop of performance out of them. Has the business of software development come full circle, and once again become the territory of the elite ‘low-level’ programmer?

Wired reports that a firm in South Africa successfully demonstrated that data transmission via flash drive equipped carrier pigeon is faster than their existing internet service (source).

Of course, any networking student worth his salt should know that this approach dates back to 1990, in the form of RFC 1149…

• Support for multiple windows
• Java-style flow layout
• Full batching
• Numerous performance enhancements and bug fixes
• Minor theme tweaks
• setuptools/easy_install support

Given the speed of development, simplui has moved to its own googlecode project:

http://simplui.googlecode.com

You can obtain the source from Mercurial, or download the binary package there.

In addition, simplui has been integrated with setuptools/easy_install. You can find the package listing in the PyPI directory (here), or you can install immediately with easy_install:

easy_install simplui

(note that easy_install will not install the demo application and themes)

This release does come complete with a few of caveats:

• simplui is only compatible with pyglet 1.1 maintenance – not the experimental version in trunk
• There is a bug in pyglet 1.1.3 which can cause crashes if un-patched.
• On Mac OS X, you may need to upgrade setuptools (sudo easy_install -s /usr/bin setuptools)

The future of pyglet

Alex Holkner recently announced that he isn’t able to continue development/maintenance of pyglet anymore. If you work with pyglet, consider weighing in on the news group about the reorganisation of development:

http://groups.google.com/group/pyglet-users/browse_thread/thread/cd603298938b7371

simplui development

With the recent profusion of GUI toolkits and the discussion thereof on the pyglet mailing list, I have decided to formalise the development of simplui a bit. To that end, I have dedicated a section of the wiki to simplui. The information there is currently very sparse, but I hope to expand it in the near future.

http://wiki.darkcoda.com/wiki/simplui

In particular, I welcome discussion of future features and enhancements, on the road map and associated discussion page:

http://wiki.darkcoda.com/wiki/simplui/roadmap

Happenings over @ GameDev.net

A while back I entered a prize-drawing for some GDNet goodies, by helping spread the word about Intel’s Level Up 20098 contest. I was lucky enough to be picked as a winner, and the kind folks at GameDev sent me a satchel full of pens, mini GDNet frisbees, and sticky-headed darts in the shape of stick-figures – anyone know what they are intended for?

GameDev’s editorial staff have approved a short n’ sweet article by yours truly on the subject of spatial hashing. With a little luck it will appear on the site in the next week or so.

I figured I would also take this opportunity to mention that after 6 years and 4,000+ forum posts, I have become a member of GameDev’s hallowed Top 50 Rated Posters (not including moderators and staff). Think that is worth a line on my resume?

I wasn’t intending to push a release out until more features were added, so consider this a maintenance release.

You can download the tarball, or browse the source in SVN.

The default themes provided by simplui

Today brings the 1.0.2 release of simplui. This is a beta release, previewing major enhancements, and I need as much feedback as possible on the new features. As such, this release isn’t heavily optimised – that is on the wishlist for next release.

The big news for this release is themes support. The GUI is now fully skinned, using a variant on the ninepatch method code developed by Joe Wreschnig and Alex Holkner on the pyglet mailing list.

Each GUI frame can use a different theme (even in the same time!), and the theme can be changed at runtime. I have included two sample themes, one modelled on the Mac OS X ‘Aqua’ interface, and the other on the PyWidget GUI toolkit.

Also included are the usual crop of bug-fixes, including the squashing (hopefully for the last time) of the persistent event clipping bug.

As per usual, grab the tarball, or visit SVN, and let me know if you have any comments or suggestions.

I will follow up with a more technical blog post in the next few days, explaining all that is going on behind the scenes, and can’t be seen in a video.

Part of the rationale behind this video is to stremline the whole video capture and posting process. Unfortunately, it hasn’t been entirely straightforward so far. I went through a number of video capture tools before settling on FRAPS, which works well enough (though I would have prefered a free tool).

I also have had a terrible time converting the video for youtube – ATI’s Avivo video converter is blazingly fast, but apparently produces an incompatibe audio codec in any of the high-quality settings. I was forced to fall back to the CPU-based Auto Gordian Knot, which both does a worse job, is very slow on my little Athalon 64 x2.

I am now experimenting with ffmpeg, but the command line options are confusing to say the least. If anyone has any clues/tips/tricks for getting FRAPS encoded video (and audio) into a suitable format for youtube HD, please let me know.

Today’s 1.0.1 release introduces a slider control, docstrings for all widget constructors detailing the keyword arguments, and a couple of bug fixes.

You can grab the release tarball, or check out the code directly from SVN.

If anyone feels like taking it for a spin, I could do with bug reports and feedback on the API.