So - I was off work last week painting, and I ran into a bunch of things I hadn't thought of. That said, by the end of the week, I had painted all of the skirting boards and doors with 2 or 3 coats, and the walls of the living room, hall and corridor are now a nice bright lemon yellow (although the paint company called it something more inventive). The place is looking cheerful and livable again.
Some parallels I noticed between interior decoration and software development:
- Preparation is essential
You need a plan, and you will pass over 70% of your decorating time doing things other than painting. You will fill in holes, sand and wash walls, put paper or plastic on the ground, move furniture away from the walls and cover it, and so on.
I forgot about a bunch of stuff and found myself underequipped when the time came to do things like protect the floor (I had a few big 3m x 4m plastic sheets which were completely inappropriate for putting round the edges of the room). I ended up wasting a day doing things which would have been 10 times easier if I had protected the floor and furniture properly. Thankfully, we got a big bunch of free newspapers and I could work OK after that.
When you're writing a program, there are also a bunch of things which need to be done to lay groundwork for a project (plans, specs, basic architecture diagrams, source control, bug tracker, testbed, nightly build framework), and you will find yourself continually regretting that you don't have them if you don't spend the time at the start setting things up properly.
- Avoid false economies
At one stage I got so frustrated that things were going slower than I expected, and I was wasting my holidays, that I did some really stupid stuff. I painted doors without taking off the door handles. I had to take them off afterwards in any case, to clean them, so why didn't I just take them off to start with?
Frustration is the enemy, and causes people to start looking for shortcuts. Sometimes the shortcuts are there (cutting features before a release, for example), and sometimes they aren't. Usually, shortcuts that you take when frustrated end up coming back to bite you later on and costing you time. You might think you can save time by not testing code while you write it, but you will spend twice as long debugging it later. You have to test the code anyway, so why not do it when it's easiest?
- Use the right tools for the right job
I really didn't see why I had to buy lots of paint brushes, so at the start I only had 2 brushes and 1 roller. I ended up going back and buying more brushes, because the ones I had were completely inappropriate for the task at hand.
A bit of forethought will allow you to decide what tools you need, what tools are useful, and what tools you can avoid.
Anyway, we're taking a rest before we do the bedrooms, Thomas will be away at his grandparents at the start of August, and we'll do his room then. After last week, I think that things will go much better now.
The GIMP is up for an annual OSI award in Portland at OSCon next week. The awards will be presented at the Tuesday evening dinner in the Portland Ballroom, wherever that is. yosh and carol will be there to wave the flag for us, all going well. Good luck to us.
There has been a pretty good discussion on the GIMP Developers list recently about colour correction. I would love to see this get done for 2.2, but right now it's unclear what the answers to the two important questions are. Those questions are, as always, what and who. That is, what is going to be done, and who is going to do it.
The discussion has proposed two ways to handle colour management - the first is to apply a colour profile at load time, and have a working colourspace os sRGB or some other RGB colourspace. The problem with this approach is that there will inevitably be some data loss if we start with 8 or 16 bit per channel data, apply a colour profile, and then quantise to 8 bits per channel for the GIMP. The second approach is to store the colour profile along with the image that we load, and apply it only at display time, along with the monitor profile. This has a number of problems too - for example, when we pick a colour to paint with, it is likely that the colour that we see after applying colour profiles will not be the same as the colour we picked.
Since the 2.2 release will be the stable release for at least a year, in all likelihood (and, given our track record, perhaps longer), I would like to see *some* color management support in there. This proposal seems workable to me, although there are certainly implementation details which will be problematic.
Update on paint colours
I found this game where you can pit your wits against the Dulux paint namers. I performed spectacularly badly, scoring 1/10 (the average if you just guess should be 2/10). Good luck.