unique visitor counter

Archive for October, 2006

bake in a water bath definition

Amazingly a lot of hit to my blog is looking for the definition to “bake in a water bath”. Go figure…

What it means is you need to bake your item in a double container. For example, if you are making creme caramel, you would first fill your porcelin cup with custard. Then put the porcelin cup in a bigger container. When the oven is preheated, place both container in the oven, and fill the outer container with water, up to 1/2 the height of the porcelin cup. Remember, water bubbles when boil. Then, you cover the outer container with tin foil. Then, poke some hole on the tin foil to allow water to escape, so the condensation doesn’t drip back into the creme caramel. Close the oven door, then you are on your way.

Add comment October 17th, 2006

On Software Requirement Specification

During the 4 years I was an engineer at Amaon, I never found requirement spec to be useful.  Instead they uses a concept called one pager, which is to describe the problem vaguely in one page, and hand it to the developer to figure out the rest.  It is then the responsibility of the engineer to understand the problem space and make the best technology decision to anticipate what detail feature the business really wants.  Rapid prototyping, using something close to code as your canvas to refine your picture.  This, I found, have shorten the development cycle; and give the engineers the sense of ownership they are looking for.
Part of the team I am working now with requires a set of specification similar to those of a Boeing airplane plan.  Basically you are fronting all the thinking into the requirement phase and allowing a long period of dark time for development.
In the three months that we spent doing requirement, the business needs have changed significantly.  So the process becomes constantly having to jump hoops to adjust the requirement to fit the changing business needs.  By the time the product is finished, the market might have changed, and the software is not flexible enough to accomedate that.
The problem of the first approach is that you need engineers who are willing to take risk to own a problem space.  If he gets the problem wrong, he should be held accountable and his head should be on the chopping board.  At the end of the day, all business folks are held accountable for the same thing.  Why shouldn’t engineers be treated the same?   You need to find engineers who is capable of doing that, which I think is the main problem why a lot of people go with the second approach.

I can’t say which approach will win.  Having been on both side of the fence, I persoanlly do not believe in software requirement spec anymore.  The flattening of the world introduced a huge inflaux of engineering talet at a much lower cost.  These engineering talent are mostly commodities to fill the second type of work.  You cna now get an army of them to bang out code for you.  So probably what will happen is big company who have a more stable requirement can afford the time to use this method; and small company who wants to out speed them will stick mostly to the first type of engineers.

So as an engineer, the two caree choice I see is either to provide more value by taking on more business risks, or to place yourself as the management of these commodity resources, or to compete for the finite space of being the industry expert on things like pubsub and do that all day.  The days where average engineers can just code is getting shorter and shorter.

2 comments October 17th, 2006

Fresh Fruits from the Pacific Northwest

Got a little “hand itch” and got a few tomato back from Seatle. Tomato and egg it is then…

Add comment October 2nd, 2006


October 2006
« Sep   Nov »

Posts by Month

Posts by Category