Estimates

16:01, Friday April 11th, 2003 • feeling relaxed • no comments

After the major fuck up that was my estimate of the work involved in my last project, I was determined to do better this time. I have been reading a lot about extreme programming and have chosen to employ it's methods in my work. Their advice with the design phase of a project is not to plan too much, to be ready for change and to be very careful when estimating deadlines. One phrase sticks in my head, if something looks like it's going to take 3-4 days, break it down into smaller parts. Combine this with the rule that no one thing ever really takes less than half a day and you have a process which I hope will turn out to be vaguely accurate.

As I went through the project specification document with a fine toothcomb I thought about my work process. Sure I can acheive task X in an hour, but only if I'm already in the flow of work and I don't have to orient myself to it. I can maybe achieve task X in that time, but there is no way that I can achieve eight tasks that should take an hour in one day, even if I work full pelt. It doesn't work that way. I need tea, I need to send emails to clients, make phone calls, find files, research things. All of this adds up.

I had in mind another piece of advice that a friend of mine had given me, "You need to firmly believe in your ability to call the prices and time estimates (even when you are wincing your through an icy patch of the conversation) to ensure that he knows the reason why he has employed you at this critical time." Too many often I have gone the other way and downgraded my estimates, only subtly, just erring on the lower side, and paid the penalty.

There's always the possibility I have done that again this time. The extreme programmers talk about making estimates in ideal days and then multiplying by a load factor, usually in the order of 2 or 3. I didn't do that. I made estimates in something more like genuine time and kept rounding up and then added about 15% extra to each of the five milestones and an extra 10% for project management. I did conceed to write documentation for everything in that time as well, but this is a low pressure task and one which can easily extend a few days beyond any deadline.

I feel relatively confident about the work. This is a miracle given that when we had the initial meeting my recent failure was fresh in my mind. Even just the concept of delivering "something within a week" was unduly stressful. As each milestone is met, my confidence will return more and more.

More going with the flow

18:04, Wednesday April 9th, 2003 • feeling relaxed • no comments

I talked to my client about his design. He gave me reasons for keeping frames and we had a fairly spirited discussion about it. I'm still implementing the same project, but it's OK now because I'm reassured that he didn't just make things up and back up his decisions. Also a working demo is more urgent than I had understood, changing the goals slightly.

Definition

17:41, Wednesday April 9th, 2003 • feeling relaxed • no comments

shirkload
shirk·load (shûrk' ld)
n. The amount of shirking expected from a shirker in a specified time period.

When should you go with a flow you don't like?

11:15, Wednesday April 9th, 2003 • feeling thoughtful • no comments

My client has designed a screenshot showing how they would like their application to look. The guy who made it is fairly good with Photoshop and it has rollovers and tabs with 3D effect and everything. However, whilst he is a fairly capable amateur designer, he doesn't have a lot of knowledge of usability and has resulted to the standard muddling through approach. The design uses frames; employs a fair amount of javascript; will require frames to be kept in sync with each other and uses a JS tree view control.

Typically with the muddling through approach, a lot of it is fine. Syncing frames all the time will make the application more complicated as each page has to work out where what goes. The tree view is a worry as well. What if somebody hits it with a browser that can't handle it? I will build it using DOM methods and CSS so it's future proof, but I bet there are going to be people that use Netscape 4 to browse this application. Because it's a functional application I believe it's much more important that people can access it reliably. It's OK when you can't hit the latest Kylie website, but if you work in say, a hospital or a garage, you don't want to be upgrading your browser just to get your job done.

Somehow I need to bring these issues into discussion without making the designer think I'm having a go at his design. I also admit that there is a side motive, some of the stuff he has asked me to do will be time-consuming to implement, so I'd rather not do it. My reason for this is not just laziness, they could use my time better to create a more functional application.

The dilemma is working out how much I'm hired to talk and how much to do. Often I'm hired to build and advise but that isn't always the case. It's not black and white, of course, some things are open for debate, others are resolutely not. I get the feeling that the design of this site is not up for debate and there's only one way to find out. It's not my favourite part of the job and I think that it might be worth looking at a course in client management or something. The reason it's so hard is that when I'm in a meeting my primary goal is to please the client. When I'm coding, it's to build an application quickly and without bugs. That means that I think of something and when I come to discuss it my view has been changed subtly by the desire to please my client.

Router fun

16:11, Tuesday April 8th, 2003 • feeling jubilent • no comments

So I'd forgotten the admin password. I needed to setup port forwarding so my client can see their mini-server. I thought, how am I going to change stuff without the password. After reading around for a bit it seemed the only option was to reinstall the firmware.

This didn't go according to plan and by five o'clock last night I had just a shell of a router that would not respond to any commands. Normally these things can be administered through a serial port if all else fails, but the key combination to boot into emergency prompt mode wasn't working. This morning that very much confused the guy I spoke to at technical support.

However, one thing did work, the key combination to boot over BOOTP. So armed with a PDF explaining what was I required, I found BOOTP and TFTP servers for Windows and managed to rebuild the whole system over ethernet. That was cool, I've never done that before.

Then of course the configuration interface went into treacle mode. It's taken me the best part of an hour just to configure the ADSL, DHCP, NAT and DNS. No idea why. Now it's fixed though and I couldn't really care any more.

I think I might read my email...

Page 80 of 113

← previous page, next page →

Choose another page: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113 or return to the most recent entries.

Last updated at 11:32, Wednesday June 18th, 2008. All times are shown in 24-hour clock format and are BST.

Rate my journal on bloghop.com: the best pretty good ok pretty bad the worst

aftnn.orgafternoon's journal → page 80