Put your Bugs where your Mouth is

Last month, Decade Software released EnvisionConnect 4.0—and what a proud day it was.

The new version is the previous version on steroids, and were constantly making strides to improve performance and make the product easier before version 4.1—always focusing on making the application faster for users to get in and out and still feel good about having got the job done.

My Development Team prides itself in maintaining a zero defect average. Every 30 days—during Sprint planning—we commit to closing every open defect in addition to delivering any new features we committed to providing.

Speaking to software shops across the nation, I have not found one who has been able to come anywhere near our zero defect average. (If you know of any, please let me know. I would love to glorify them in this blog!)

I recapped all of the above so that you understand my dismay at hearing someone say this week…

“One of our clients says he doesn’t like the Page Layout Editor”—Yes, we do allow users to redesign forms and pages—”because the user says the tool is buggy.”

Immediately, I searched the defect tracking system and consulted my Quality Assurance team. I wanted to find out how many bugs constituted “buggy” and why we had not eradicated those bugs.

I found no bugs related to the feature in question, aside from a couple we had fixed but not yet released.

Then I knew our problems lay somewhere else.

Is the problem related to the definition: What is a defect?

Not likely. At Decade Software, We have the most lax description in the industry: If the client is “bugged” by something, that’s logged as a defect. Ultimately, we may fix it as a defect in code, or by adding a new feature, or by changing a design, or by providing training for the user—but no defect is ever ignored with the words…

“…that’s just the way it is.”

So, if the code is not the problem, and the definition is not the problem, then there’s only one thing it can be. Someone found a defect and did not report it.

Even the best software teams cannot fix bugs no one has found. It is the responsibility of user—internally and externally—to report any problem found.

Software shops can’t make you happy, unless they know what is making you sad.

EnvisionConnect Batch Processing Faster than Envision

Customers and conference attendees have told us time and time again that financial batch processing in Envision was the fastest in the industry. EnvisionConnect, they also reported, is much easier to use, but not very fast compared to its predecessor. Decade's Development Team took that as a challenge, and early trials have everyone buzzing.

Smart Client Technology—the key to working on the web without giving up a powerful user interface—provides that all is processed client-side, including batches. Envision's advantage in the batch realm was its good old-fashioned client-server technology. Batches processed on the server run fast. The challenge in EnvisionConnect was to move the batch processing back to the server side without sacrificing the intuitive interface EnvisionConnect customers have grown accustomed to.

Through exhaustive research, careful prototyping, and much discussion with EnvisionConnect users, the Development Team provided a solution to a problem.

Perform Aging and Penalization and Perform Permit Billing are, by far, the most powerful of Decade's batch processes. From day one, EnvisionConnect was developed with a "hard things first" mentality.

Developers stayed the course with the batches, converting these two batches to server-side processing before all others, and in side by side trials—same data, same configuration, same hardware—these two EnvisionConnect batches now smoke the Envision batches, and they run in a fraction of the time it took the client-side batches to run.

In fact, Perform Permit Billing now processes half a million records in under one hour!

Want to know more? Join us at the Decade Software 2009 Training Conference, October 19th and 20th.

It’s not really Friday, is it?

This has been a busy week, but its the start of one of our best sprints ever.

We are overhauling sections of our flagship software that will knock our users’ socks off, and my team is focused tighter than they have been in a long while.

In the meantime, teams from various departments are working more closely to increase transparency and provide customers with solutions faster.

—and we’re growing! We added two team members in the last 30 days, and we are still interviewing.

More and more potential customers are getting excited about EnvisionConnect, and our newly established Customer Communications Task Force is getting off to a great start.

Great week, but I’m exhausted from all of the excitement, and I’m still happy to see Friday.

[For you youngsters out there, the photo is Sergeant Joe Friday.]

Bugs should fear you more than you fear them

In Martin Heller's column this week, he visits a topic I discussed last week, the fear of bugs. Martin describes Bugaholic's Anonymous and makes some really interesting points.

Here's my favorite...

"...you should welcome bug reports, not fear them. A good tester is a pearl beyond price. A developer who views each bug report as an opportunity to improve what is inherently imperfect code is going to be much better at debugging than one who views each bug report as a personal insult that has to be caused by user error."

He also introduced me to a term I had never heard before, PIBKAC—Problem Is Between Keyboard And Chair—or as my old friend Joe Browning used to say, "Operator Error."

About those casualties of war...

[ Entry written after the fact and retro-published to the date of occurrence. ]

As the stress coach, Garrett J. Braunreiter pointed out a few years ago...

"At the turn of the century—before the fax, modem, cell phone, and computer—the average American workweek was 60 hours long. By 1970, it was down to 37 hours. Today, the average worker puts in 46 hours a week at the office and six more at home for a total of 52 hours, according to recent surveys. In addition, 40 percent of those surveyed said they often work up to 10 more hours for extra pay, adding up to 62 hours—two hours longer than in the horse-and-buggy days."

Being an "old soul", I apparently am quite fond of centuries gone by. I work fifty to sixty hours in the office and at least another twenty at home, writing fiction. Of course, there are those who would say, "He's a manager and a writer. He doesn't really work."

In fact, just last weekend, I overheard two of my developers in conversation. One said, "Who else is working this weekend?"

Another responded, "HL is here."

The first replied, "I asked who was working this weekend?"

At the time, I was actually coding—upgrading the UDF Editor to support new features in EnvisionConnect. I pretended not to hear the joke.

In the last year, my team has worked an average of sixty hours per week per person. Everyone has essentially ignored their stress in favor of reaching our goals for the year. We lost a few teammates as we grew closer to the finish line. They took jobs in less stressful—less transparent—work environments.

...and less than 24 hours after we crossed the finish line, I was transported to the emergency room with pains in my chest.