Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

Zero Defect Software Development

There is an old article about Zero Defect Software Development(ZDSD) by Steve Pavlina that was recommend to me by a coworker.

According to the article the basic tenet of ZDSD is "Maintain your product in what you believe to be a defect-free state throughout the development process."

I think a lot depends on how you define defect. For instance the article uses games as an example and includes in defects "unpolished artwork, an unacceptably low frame rate on the target system, levels that aren't fun enough, or any number of unfinished features". These can be restated as aesthetics, performance, usability, and unmet feature requirements.

Restated further, defects are measures against a defined level of quality (i.e. anything that falls below the defined level of quality is a defect). If the only measure of quality is the business requirements then the defect rate may be relatively low. If other measure of quality are defined (performance, maintainability, documentation, etc) then the defect level would need to be reevaluated based on those standards.

Rule 8 advises you to "Set QA objectives at the beginning of every project". Combine this with the basic tenet, "Maintain your product in what you believe to be a defect-free state throughout the development process" and what you get is "Set a standard of quality and live up to it".

Not bad advice. I'm sure a lot of development shops could be helped by it. The problem is that different development shops practicing Zero Defect Software Development could be given identical requirements and produce substantially different levels of work depending on what other measures of quality they define.

Fortunately there is more to Zero Defect Software Development than this. The recommended practices are actually quite stringent. Here are a few:
  • Review code regularly
  • Rewrite poor-quality modules
  • Make the quality of your code as important as the quality of your product
  • Learn from every bug

Good stuff. In fact the article recommends a laundry list of very solid practices, but I wonder if Zero Defect Management isn't as aptly named as it might be.

Also, I couldn't find much of recent chatter about ZDMS, except some talking about zero defects in general, so maybe this never really took off. There were some solid recommendations in the article though and I highly recommend checking it out.

Family Eulogy

My father died last week at the age of 65. My grandfather died just a year or so before him at the age of 93. Below is a picture of me, my son, my father and grandfather taken almost 7 years ago. 4 generations.

In the end death humbles us all. The most I can offer them is a brief remembrance, sharing the best of these men that I loved and admired so much.

Briefly though I need to take a step back in time and share the story of a man that they admired, my great grandfather, James Partin.

My great grandfather was a cowboy all his life. My grandfather had an old picture of him on his horse, a gun on each hip and lasso in hand, herding cattle. He was good to the Indians that some times camped on the other side of the lake from him and was know to share the sweet potatoes that he grew with them and anyone else who came to visit. He was a good man by all accounts, tough but fair and hard working every day of his life.

At the age of 73 my great-grandfather was trampled by his horse after his saddle broke while he was roping a calf. He managed to walk some miles back to the ranch where he worked as supervisor and was taken to the hospital, but died a few days later of internal injuries and gangrene.

My grandfather, Judson David Partin, loved his dad dearly, and in his 90’s he still got choked up telling the story of his father’s death. I don’t think anyone ever gets completely past the death of their father.

As much as my grandfather admired his dad he chose a different path. As a teenager my grandfather was out tilling the field barefoot with a mule and plow when he had a root pop up and hit him hard on shin. It was a small but pivotal moment. He said he decided then and there that he was he was going to do something different with his life.

Some time later he talked his way into a job driving a Model-A truck moving citrus (the model-A was the successor to the original Model-T). He told the man who hired him that he knew how to drive it, and though he didn’t, he figured it out.

He spent the next 60 or so years of his life driving trucks off and on. He cleared land for airfields stateside in WWII and was known to be able to operate any machinery with wheels or treads. He was forced to retire from truck driving for insurance reasons at the age of 82. So far as I know he was the oldest working CDL licensed driver in the United States.

A few years later when I went to visit he was still doing 90 mile per hour on the local interstate, three radar detectors on the dash and a .38 and .45 next to his seat. I took a trip with him up to North Carolina and he stopped to help some people who were broke down on the side of the road up in the mountains. He figured out what was wrong with the car and we drove 30 miles away to the nearest parts store, came back, fixed their car and got them on the road again. He was a good man and spent his life helping people, especially family.

Though his health began to fade after retired, he spent another 10 years sitting on the porch feeding the sand cranes and the squirrels and driving his girlfriend around to garage sales (a younger woman, just in her 70’s). In 2006 he fell in his home and broke his hip. He managed to get up, clean a gash in his head and was sitting his chair when my dad came to check on him. He lived another year or so but was never independent again.

Electric light, the automobile, movies, and airplanes were all just beginning to be commercialized when my grandfather was a kid; electricity and indoor plumbing were luxuries that most did not have, his family included. In his lifetime my grandfather saw the time of cowboys and indians fade and transition to the age of computers, space and the internet. There has never been any other time in history when one lifetime could see so much change.

My Dad, J. David Partin, was just as determined as my grandfather was to do things differently. From childhood my dad had a gifted voice. He went to college and studied business and music. He spent most of his life as a singer and an entertainer. He even briefly had a local television show on Tybee Island, GA in the late 70s called the Dave Partain Show (Partain being a small alteration of his last name that he used as a stage name).

He was drafted into the army during Vietnam, but was fortunate enough to be stationed stateside; he managed several restaurants, owned a club for a while and never gave up his dream of making it as an entertainer, returning to it time and again. Over he all lived a wild and crazy life.

Though he hung on close to 10 years longer than the doctors had given him, being ever the contrarian, he passed away quietly in his sleep days after his doctors offered the family hope that he might bounce back one more time. In the end he was most happy that he had been able to reconnect with my sister and I and that he had gotten to see his grand children, of whom he was immensely proud; a joy he shared with everyone.

I loved my father very much.

I always will.

Update: I couldn't bear to post this at the date it was written, and don't want to update the date and have it show up as current now after the fact, so I'm posting it at the original date. I'm not certain if it'll be picked up by the RSS feed or not, but I want it out here on my blog as a testimony, whether anyone sees it or not.

QC Testers - Not Just Software Sanitation Engineers

A good Tester can be worth their weight in gold if you let them. Their job is to put your application through the ringer. They are also generally the first person to use your app/feature so they can provide some key insights into user experience and usability.

Off the top of my head here are some things that a good tester can check:
  • Is anything broken that worked before? (regression testing - a lot of work here)
  • Can your URLs be hacked to get information that users shouldn't have? (security)
  • Are sql injection attacks possible? (security)
  • Is your tab order right? (usability)
  • What would the stupidest person using your app do here? (user experience/idiot proofing)
  • What happens if you double click on buttons? (user experience/idiot proofing)
  • If there is role based content/functionality what would happen if a user with multiple roles accessed this feature? (security/usability)
  • What would make this feature easier to use or easier to understand? (usablity)

Those are just a few. If you're a developer I'm sure you've asked yourself a lot of these questions and then some, but testers are different. As a tester, "If it ain't broke, you aren't trying hard enough". A good tester takes it as a challenge to out think you, to find the things that you missed when you were busy getting it working.

It used to be that testers were either inexperienced techies trying to break into development or just business people who just stumbled in and filled a need. They'd give the app a quick once over to make sure nothing obvious was broken and move on.

More and more I'm seeing testers with decent database and coding skills. They understand how the application works. They're in the database, they know how the data moves. They know how to know if things are working right and how to set everything up properly.

Bright people are now choosing testing as a career and I think the gap is quickly widening between a top notch tester and a merely competent one.

So if you're lucky enough to have a good tester don't look at them as another hurdle that has to be jumped to get your code out to production. They are a valuable part of the process; they're you're collaborators in turning out an awesome product.

P. S. Can't resit giving a belated shout out to my favorite testing blog, JW on Test... Thanks James, keep up the good posts.

Jump the fence or bloom where you're planted? When to move on to another job.

After only six month at my current job I've accepted an offer at another company. If you follow my blog you may remember my last job change and my excitement at finding a good job close to home. It was a very good job. I had a good team, a good boss, and a reasonable workload; I was very happy there.

Then, just before Christmas, my company let go of a bunch of contractors. Though I wasn't one of them and though my boss assured me that he was very pleased with my work, my confidence in the security of my job there as a contractor was shaken. I didn't immediately start a job hunt, but planned instead to reassess things toward the end of February and make a decision then.

Providence intervened however. In mid February I received an inquiry through LinkedIn asking if I was interested in a web development job at a small, growing company in Ponte Vedra Beach (just 20 minutes from where I live in Jacksonville, FL). A growing company in this economy sounded really appealing. Long story short I interview and loved what I saw and heard; two days later I accepted an offer and gave notice at my current job. Perfect opportunity, perfect timing.

All of this upheaval got me to thinking, though. Is there a fixed set of criteria that people can use to judge when it's time to move on from a job? What are the things they should look for?

You've heard the saying "the grass is always greener on the other side of the fence", which is to say that things always seem better elsewhere, though they seldom are. Often it's just a matter of trade offs. If you work for a solid company, have a reasonable boss and interesting work then you should overlook the little things and strive to make lasting changes in your company for the better or, as I heard a preacher say once, "dig in roots and bloom where you're planted".

Making the most of the job that you have is usually the right move, however, I've come up with a short list of things that I think signal that it may be time to move on:

  1. If the company that you work for is unstable. If you are in a company that is on shaky ground then you need to try to get out before things hit the fan and you end up looking for a job with a large group of your peers. Feelings of loyalty can be compelling, but if you're married, especially with kids, and don't have a generous rainy day fund to fall back on then you need to start weighing your options immediately. Remember that your duty is to family first, work second... Always. Remember too that it's easier to find a job when you have a job, if for no other reason than that time is on your side. Just be careful and make sure that the company you're moving to is more secure than the one you're leaving.
  2. If you have an unbearable boss. Maybe your boss is truly evil or incompetent in a dilbertesque kind of way or perhaps there is simply a personality conflict or idealistic differences between you. In any case, if you can't resolve the issue, if you can't be at peace and if there is no end in sight then you need to move on before you grow bitter and hurt your reputation. Oh and if you and your boss are at odds, you can be sure that you'll be the first on the chopping block when it's time for cutbacks.
  3. You are working insane hours. We work in I.T. and in crunch time we do whatever it takes to get the job done. I'm sure you all have your own war stories of long nights and 24 hour days. We're proud of those. They're badges of honor. But those should be the exception not the rule. If everyday becomes crunch time and unrealistic expectations are the norm, then you need to get out. It's a tough call to make. I've been there. Your boss promises that you're almost over the hump and then it'll get better.... months later he's still promising it, with genuine sincerity, but in your gut you know there's no end in site. It's time to move on before you burn out and it starts affecting your health, your work or your relationships.
  4. If you're not learning anything. If you are no longer challenged and if most of your learning comes from off the job then it may be time to move on. Technology is moving faster all the time and if you aren't moving forward you're getting left behind. This is one situation that can respond well to a frank talk with your boss about your concerns, but if you've exhausted all other avenues you need to consider making a move, before you get trapped in a dead end career .
  5. You are grossly under compensated. Money isn't everything, but then again you don't want pay inequities to be abusive. If there is a significant difference between your salary and others at the same level in your industry then it may be time for a change. I worked a company once where where every few years people would take a job somewhere else and come back in a year making significantly more money simply because the pay structure favored new employees over loyal employees (i.e. base rate increases over time dramatically outpaced yearly pay raises). If your efforts to address the inequities have been ignored or rebuffed then you may want to consider your options.
The above points can be categorized as Security, Environment, Workload, Skills and Pay.

If you're having one or more of the above problems with your current job then I'd say it's definitely time to start looking for other employment, even if, given the current economic situation, it's a slow steady search over time.

As a wise man said recently, YOU, and NO ONE ELSE, is responsible for your career.

Be careful that you never allow yourself to be be paralyzed by either the comfort of your current circumstances or the fear of change. Change is inevitable; change is life. If you're comfortable now, don't become complacent; hone your skills and build your experience... change is coming.

Update: Shortly after writing this post and moving on to my new contract to hire position, my new employer (owner/developer in the small 2 man shop I signed on with) decided I wasn't a good fit. No really satisfactory reason given... he was the owner, he got a gut feeling... that was it. I received the call Monday morning as I was leaving the house not to come in that day.

It was a gut punch. With the economy down I knew there were only a handful of positions out there and I felt the world crashing in.

Fortunately I was in good standing with my old employer and my old boss and his boss jumped through a bunch of hoops with HR to get me my old job back (especially tough since 2 rounds of layoffs had just happened). I am grateful and very personally touched by the effort made to bring me back.

In this midst of this I immediately pulled the above post, not wanting anything to jeopardize my chances coming back. I finally feel comfortable putting this back out there (as of 6/22/09). Having gone through all of this and had time to reflect on what I wrote I still think I got it right, but with a few caviots:

  • Be very careful about your decision to leave; a job is a very precious thing.
  • Be very careful how you leave; don't burn any bridges.
  • Be very careful what you put on your blog when you leave; many people at my work read this blog post after I left... I'm so glad I didn't, even accidentally, write anything questionable or anything that offended anyone. Even so I rather wish I'd waited a month or two before posting it.
And finally: Thank you again to those who helped -- I am both humbled and touched by the decision to bring me back.

Accessing Page data via Session in WebMethods public static methods that are marked with the attribute [webmethod] are available as Ajax calls in JavaScript. Unfortunately these methods can't access the Page object or any non-static values or objects.

The solution? Create one or more static properties and use them to store the data you need in your session.

static IAccount account

return (IAccount) HttpContext.Current.Session["MyPageAct"];

HttpContext.Current.Session["MyPageAct"] = value;

Now you can initialize this property in your page load event and because it's static it can also be accessed from your web method.