How to tell time?

Sometimes I try to figure out old something is, or how long I’ve been doing something, not by a date or even a decade but by what obsolete technology was involved: I was listening to this when I was still buying LPs, or CDs. Or when software came on a box load of 5.25 floppies.

Cherry Blossoms

The cherries are blossoming already. Now, yadah yadah global warming, yawn. But I was wondering the bees/birds whoever it is that pollinates cherries are around to do their duty. What is going to happen as the weather changes and the flowers bloom earlier and earlier. Has anybody told the pollinators to reset their clocks? Is there something like salmon spawning just in time for the bears to fatten up for winter? Do they all, we all, have enough time to adjust their clocks?

project budgeting

It would be nice if you way start a project by setting the budget limit: this what we can spend. But you know that just becomes the target.  The programmers want to spend it all.  And then some. It sets the size of the project, but usually the lower bound, not the upper limit.

But what if you started by saying you want an ROI target: this project needs to return $50m in increased annual revenue over its costs. I never seen this done. But you can see the effect, to get that much of an increase, you probably do not have small incremental fix in mind.  Or do you.  Consider, if the process generates $1B in revenue now, that is a 5% increase. But if the process generates $200m now, that’s a 25% increase.

More to the point, if the project looks like it’s going to cost $50m with $5m maintenance costs (the rule of thumb is annual maintenance costs are 10% of the development costs) with a ten year life span the project costs out at $100m so you should be looking for $60m in additional revenue. These figures are simplistic, but you can see that perspective shifted from ‘how much can we spend’ to ‘how much do we have to earn’ or if you will ‘how much do we have to produce?’ 

Because programmers think what we produce is a software product.  Once we deliver the code we’re done. We don’t think much about what the software has to produce, how much it has to earn for its living. We want to get programmers to think beyond code delivery.

I do not know any programmers who think this way.  Hopefully commercial programmers think this way. But I suspect many if not most of them have a Field of Dreams illusion, if you write it they will come. Just throw that software on the web and let people find it. Passive entreupeneirship. You can see why most dot comes fail.

The trouble with inhouse development is that the project managers shield the programmers from the nasty budget and scheduling process. They’ve been forced into this mode of operation, programmers don’t want to know (they just want to complain about it later). I suspect this mode of operation encourages the attitude. But if programming is going to grow up we programmers are going to have to learn the business.

on systems analysis

I’m coming to the conclusion that most technically oriented books assume that the requirements already exist and merely need to be converted into ‘use cases’ or even UML diagrams.  And I’m concluding that this is disasterously wrong because it confuses and combines analysis and design as a single step. And because they assume that ‘requirements’ can be stated completely and comprehensively–ignoring all we know about communications in general, which makes sense in that most programmers aren’t much into relating to others (using myself as an example). I’m coming to the conclusion requirements documents are at best skeletal, more like Cliff Notes than War and Peace. So that the real repository of project knowledge lies in certain people’s heads and is expressed orally. 

 

<<dot com is different from internal>>

Puttin’ Petrol Pram

You see huge baby buggies nowadays.  Doubles and buggies with storage compartments and trunks to hold all the crap you need for a baby–and then some.  Heavy duty frames and giantic wheels, sometimes doubled.  SUV and Minivan buggies.  I thought I saw one that was motorized.  It wasn’t but now I’m kind of suprised you don’t see them.  Seeing little tiny Indian nannies puffing to get them up a San Francisco hill, a motorized buggy sounds kind of useful.  Though perhaps its like ancient Greece–if you don’t do the work, you aren’t likely to see the usefulness of labor saving devices.

or all is well

When did the need for medical care morph into a need for health insurance? Insurance is a way to spread risk around so that we all have a managable level of risk. I pay a lot more for car insurance each year assuming that one of these years I may have an accident that could wipe me out financially. But it this the proper model to think about medical care?
Why did we change the patent laws to make medicines more expensive?
Why do we prohibit the federal government from negociating cheaper prices for these more expensive drugs?
I think that public health is different from medicine. One is clean water, clean air, vaccinations, removing garbage, controlling pests. Eliminating tobacco, excess fats and salts and sugars from our dietary options. Medicine is care for an individual for a specific problem. Public health is cheap and effective. And a damn commie plot (joke). Medicine is expensive and inefficient. But our focus is on medicine. Why don’t we emphasize prevention?
Why is the discussion, such as it is, skewed this way?

Getting to Done

I’m good at procastinating. About the only way I can complete something is to decide I’m going to complete something for real is work it out. These aspects work for me:
1) Figure out what the goal is. Mainly this is figuring out if I want this. If I don’t then I probably think about it because I think somebody else’s goal should be my own. Cutting out all the things I don’t actually don’t want (or need) to do clears the decks for what I do want to do. One tip: evaluate both how much accomplishing this thing would make me happy and how much failing would make me unhappy. [see Robertson and Robertson, Mastering the Requirements Process]
2) Break the work down into managable tasks. I’m easily overwhelmed.
3) Allot yourself time enough to do that task item, but don’t cheat. Kenneth Atchity [A Writer's Time] recommends that even if you’re going gangbusters, you do notwork beyond your budgeted time. In the back of your head you know you cheated and you’ll be less inclined to get cracking the next time.
4) Wear a task down step by step by step. Don’t expect to leap across to the end. This is basically the same as item two above, but I have to keep reminding myself.

None of this is original of course. I wanted to credit Robertson and Robertson and Atchity in particular. Just about everybody will tell you to whittle your work down step by step. Still, I have a hard time actually doing this. I’m just about to settle down to a task for a project and this entry is a way of procastinating a little more first…