Saturday, April 19, 2008

More on the devaluing....

My job just gigged me this way last week.

I was sent a high-level design document and asked for an effort estimate to implement it. The problem? I had no idea what the feature was, since the design doc had been written almost a year ago, and no developers were in the document review. So I have no idea what this feature is, ho it differs from the current system, and what parts are affected by the changes, except what I read from the design document, and that's very light, having been written by a "software architect" who favors handwaving verbiage (is that a mixed metaphor?) instead of clear requirements.

So I told the manager that I needed to re-review the design doc with the architect, and scheduled a meeting. And until I am satisfied that all the design issues have been thought out and nailed down, I will not be giving an effort estimate - I was burned last year by a design document that left out major portions of the feature, and also was supposed to 'just include' another feature entirely.

The Ninja Lesson: do not give answers that you do not know - always wait until you know enough details to make your answer sufficiently safe for you and your team.



Technorati Tags --
, , ,
HTTP

The value of a programmer

I ran across this the other day, and it rang so, so true.

The problem is not so much that a recent business school grad thinks this way, but that this viewpoint that programming is valueless get propagated up the management chain, where it hangs around all the MBAs and salesmen who make up the upper management ranks. If they think it's easy to write any software, they continue to
a) make ridiculous promises, and
b) under-reward the technical staff

Both of these will sour your geeks to the job.



Technorati Tags --
, , ,
HTTP