Skip to main content

When is it Done?

Words, they can be hard to come by, misleading (on purpose or mistake) and costly.   The word "Done" means many things to different people during the software development process, with most of them not-really correct or helpful.

  • Software Engineer says "it's Done" - The code may have been written but not tested.  Or written but not working, or done "except for some details", or if they told the client it's done, then what does that mean?
  • Project manager says "it's Done" - This depends on whom they are saying this to.  Saying this to a client means that they should expect it in their hands NOW.  If it's the CEO then it means, to appease, to inform, to CYA, etc.?
  • QA says it's "Done" - Then it means it's clear of bugs, ready to ship?


Done only means "Done" when the client has it in their hands, installed it and it works as promised.  We have all seen or heard to people using the work "Done" to describe, what they perceive as their involvement, in the process of getting a product done.  This word being heard or being used to the wrong person can lead to misleading information (at best) or mistrust (at not best).  I'm sure the stories of shipping blank software to clients to meet a deadline of being done are true (I've seen this in the past).  How is this helpful?

Lets view this from a more lethal point of view and replace the software development context with that of a surgery room and replay the statements.

  • The Surgeon was done with the procedure.  Did the surgeon close up, did the staff count the supplies?
  • The hospital told the family that the doctor was done.  What does this mean about the outcome?
  • The Post-Op recovery was done.  Did the patient wake up?  Is there a complication that will require follow up?
What does this mean for the patient?  The patient only really cares that the everything is completed and there is a successful outcome (they can go on living). 

All involved in the surgery can not and should not assume that because their direct involvement is over that there is a successful outcome.  Only the end result will satisfy the "Done" statement.

So why is the implication, if not the actual word used so much in not the proper context?  Because the same thoughts, fears and feelings are involved in everyone involved.  The boss that does not accept "no" for an answer, the reward / penalty system linked to workers pay that encourages this to the desire to be accepted, impress, etc.  There are a hundreds of ways to renforce behavior that is not beneifitial to others or ourselves.

(These can exists in cycles until the end)
------
Design
Development
QA
-------
Shipping
-------
Installed and Reviewed
Done!

Comments

Popular posts from this blog

My Current Desktop and Happy Vining.

It's been a big switch when I quit my old procession (Software Engineer) and ventured into the unknown.  So this is my current desktop.   First it's a REAL desktop and not a computer screen. Second, I've had to learn a whole new set of tools.  You would think a pencil is just a pencil and a paint brush is just a paint brush, but noooooo, they are tools into you mind and that's what needs re-tooling. The tactual nature of these tools and operation as much more rewarding (and frustrating too) than typing code in an IDE.   That had it's incentive but that well went dry and life changes,  so I changed. The pleasure of creating colors (no RGB involved) ad hoc wise is interesting.  Getting the technique to merge them on paper is very tough.  You do not know what you're going to get, so you just have to go with it. I'm glad that I can do a lot of other things instead of Software, but I hope that others in my past procession work on other pa...

3rd Try is a Charm

I've been trying to draw / paint these barns for a couple of years but never felt or got them right.  This time I think they turned out right. So What went wrong before and what's right now with this drawing?  This time, the light was right.  It's coming from the upper right and the shadows just looked right.  The other thing is the corn field on the left had to "be in season", otherwise it's just a plowed field.  I had taken other photos from different angles but they never felt right.  This angle has the road, power lines, corn field, etc. all leading to the right.  The shadows on the lower right helps fill in that corner (don't forget about the corners!).  The last part is trying to draw (ink paint maybe) the trees in the background.  Not so easy when they are kind of a blob is green shades. So yeah, it's composition that is king.  Many times I just don't see it until the drawing / painting is finished and when it's right it feels goo...

Thought Patterns

I know how I work.  How a think about, visualize a problem and go about mentally design a solution and implement it in code.  My thought pattern works pretty well for me on most occasions, but not always. There are times when I have a force myself to change my thought pattern because of the problem I'm solving requires a different mindset.  Anyway, this posting is about how I work most of the time.  Here is goes. I quickly break down a feature into operations that are required to exists and tackle that code first.  My thinking is that, if I can solve the primary issues first, then secondary features will fall into "known knowns" and I can address those at anytime (and sometimes at my leisure) and this allows me to meet my internal timeline. If I addressed features and operations that are not primary first, then I feel I risk my (and the projects) timeline without addressing issues that allow the feature to operate.  You may have seen this occur where...