HL Arledge

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.

Hands-on Workshop at Decade User Training Conference

The Decade Software Training Conference 2009 will be one for the record books.

In addition to providing training based on a user-prioritized list, we'll host a hands-on lab throughout the conference—no appointment necessary. If you have questions or just want to test a part of EnvisionConnect you've never used before, this open lab is the place for you. What's more, if you have questions the lab team can't answer, you're not likely to hear, "We'll get back to you on that." or "Can you call tech support after the conference?" Instead, a Conference Concierge will be on call to track down whomever on our staff has the answers you need.

There will also be sneak peeks at the future of EnvisionConnect and the Environmental Health industry from a technology perspective. We'll be presenting awards for best user-authored reports, page layouts, and SQL scripts, and we'll be introducing you to our online and interactive support tools. Our goal in the year ahead is to ensure that you never have to ask why and if you ask how, you'll get answers ASAP.

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

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.

EnvisionConnect Speaks SWIS-DIP

California's Solid Waste Information System's Digital Inspection Project (SWIS-DIP) is described this way...

The Solid Waste Information System Digital Inspections Program (SWIS-DIP) provides an easy, electronic way to submit statutorily mandated inspection reports. Using SWISDIP reduces waste and paperwork and improves the accuracy and consistency of your reports. Inspections may be submitted using the SWIS-DIP fill-in web form or with XML web services.

That sounds as close to an "Easy" button as you can get, but Decade Software has been working with the state to provide an Easy button on steroids. This fall, EnvisionConnect provides round trip data integration with SWIS-DIP.

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

Hiking to Success at Decade Software

My wife and I took a few vacation days and hiked to the Hollywood Sign, but even the hot sun and aching muscles couldn’t keep my mind off the office.

We’ve got so much going on: business is booming, our biggest release ever is just around the conference, we’re hiring in every department, and our training conference is two months away. Decade Software is truly a company on the brink of jumping from good to great.

That said, I ask myself how we got here.

We got here, the same way a middle-aged overweight man made it to the top of the Hollywood Sign. We navigated the obstacles, the heat, the pitfalls with pure adrenalin and a little something called teamwork.

Decade Software has conquered it’s Hollywood Sign. Now, we’re ready to tackle El Capitan.

Collaborate, support teamwork, or go home!

In an interview this week with John Chambers, CEO of CISCO, they asked him what has changed in business in the last few years. His answer was dead on…

“Big time, the importance of collaboration. Big time, people who have teamwork skills, and their use of technology.

Today’s world requires a different leadership style — more collaboration and teamwork, including using Web 2.0 technologies. If you had told me I’d be video blogging and blogging, I would have said, no way. And yet our 20-somethings in the company really pushed me to use that more.

If they’re not collaborative, if they aren’t naturally inclined toward collaboration and teamwork, if they are uncomfortable with using technology to make that happen both within our company and in their own life, they’re probably not going to fit in here.”

That is exactly how I feel about my team.

Customer design or Too Many Cooks Sink Ships

When designers attempt to please everyone, someone always ends up angry. The key to good design is bringing all interested parties together in order to balance interests and find solutions that work for everyone.

In the early days of EnvisionConnect, customer advocates on staff shouted:

“Our users know what they need better than anyone else. Let them design the software and force the developers to deliver exactly as they define.”

Who could argue with that philosophy? The customer knows best, right?

Let’s return to the mixed metaphor of “Too many cooks sink ships,” and let me tell you a story…

There once was a shipbuilder who hired the best engineers, but he sold ships to the government and was forced by contract to design the ship according to specs put together by a government committee.

The shipbuilder ordered the designers to build every gadget and widget the government committee could dream up, and the ship that evolved from the process was beautiful!

On this ship, you didn’t have to take the stairs to go from deck to deck. Everything in the ship was put on one easily accessible deck. And all of the gadgets, widgets, bells, and whistles glistened. It was the most spectacular-looking ship the government committee had ever seen.

When war broke, the government ordered the ship launched. It would sail to the other side of the globe and squash the evil doers.

Unfortunately, the ship was too heavy. It moved too slow. By the time the ship reached the enemy, the war was over. That’s not all that bad really. If every country followed this design model, the world would be a more peaceful place.

The moral of the story is that all interested parties have to be involved in design.

Luckily for us, the world of Agile software design doesn’t work like ship building.

We do insist that users of the software design by committee on the first pass (in industry jargon, the first iteration) but then it’s up to the engineers to weigh the needs of the many against the wants of the few and refine (industry jargon again, refactor) the product into that happy medium that makes everyone happy.

This year, our customers will notice that we’re changing the way we collect customer feedback—finding ways to extract information faster without wasting customer time, and our developers are defining “the how” and restricting customers to defining “the what”. And when some “what” is ultimately detrimental to a more important “what”, it’s our job to help customers understand the trade-off they are asking to make.

Now, you know why it’s taking a while to christen EnvisionConnect 4.0.

EnvisionConnect 4.0 as she stands today is the most beautiful and the most powerful ship in the fleet, but Envision outruns her. As goals go, our next BIG target is making EnvisionConnect faster, even if it means dropping a few bells and whistles overboard.

Watch this space to see how we do.

Did you miss me?

With all of this tweeting and twittering going on, you would think blogging would be losing popularity, but seldom does a week go by that someone doesn’t ask about my blog.

That said, I’m committing to blogging at least three days a week from now on.

…but I owe you an explanation, as to why I haven’t been doing so.

Because of the wild success of EnvisionConnect—due largely to the success of my own team—we’re really, really busy these days.

Presently, I am assisting with the launch of an all-new Decade Software user community, planning our 2009 training conference, and governing the launch of EnvisionConnect 4.0—our most anticipated release ever.

We’ll look at the details as the weeks progress, but in the meantime, I’m begging for your patience. I’m a really busy guy.

What Managers’ Expect from their teams

Larry Bossidy’s article,“What Your Leader Expects of You,” provides a thoughtful and thorough list of what managers’ expect from the members of their teams.

This is that list with some of my additional thoughts here and there:

1. Get involved: Bossidy says, “Good managers know when to delegate…but more importantly, they know when to get involved.” I say, “Good managers trust staff to deliver, but they also trust staff to alert management when they’ve hit a brick wall or they’re stuck in quicksand. In other words, stay transparent. From a Scrum perspective, this means update the team, the ScrumMaster  and the SOS Master every step of the way.
2. Generate ideas: Team players should provide ideas rather than playing it safe. Don’t offer random ideas that you haven’t thought about, but ones you’ve considered and have merit.
3. Be willing to collaborate: Team players sometimes work in cross-functional team where collaboration is required.
4. Be willing to lead initiatives: Team players should take initiative rather than avoiding the risky projects for the sake of having a good track record. How else will direct report learn to take initiative on their own if they don’t think it’s of value?
5. Develop leaders as you develop: Good Team players are leaders and teachers, constantly helping others develop. For the good of the company or for the good of the team, leaders and managers coach, mentor, and help team players to be leaders and grow into future managers.
6. Stay current: There’s nothing more embarrassing than seeing anyone not know what’s going on in their own industry, the market, or with their customers. All managers should scanning and watching the environment for opportunities or competitive threats.
7. Anticipate: Team players and their management should anticipate what the industry, market, competitor, or customer changes mean for the company and department.
8. Drive your own growth: Team players should want to learn more and take initiative without waiting for the manager to hand out growth opportunities. Find the white spaces in your job function that allow you to learn something new or expand on existing skills. Take control of your career path within the company.
9. Be a player for all seasons: Business is good. Business is down. Team players need different flavors of the same skills sets for good times and bad times. Action plans against competition when you’re the market leader can be vastly differently when you are not. Be a well-rounded player for any business circumstances.

Next, we’ll look at the other side of the coin: What Teams expect from Managers.

Bing! – And thanks for saying so.

Just back from vacation, I decided to try Bing!, the new search engine everyone’s been raving about. And like everyone who tests a new search engine, I entered my own name. Doing so, I discovered a PDF from the Center for Aggression Management entitled, Addressing the Loss of Teamwork: Identifying, Measuring and Minimizing Trust-Destructive Behaviors.

The following is a quote from that essay…

“HL Arledge, a leadership expert defines leadership with four “Ts”: trust, truth, team and transparency. He says Trust is a cornerstone to leadership, the development of loyalty and teamwork.”

Real Nice.

BTW, I also found my name on a page entitled “Words about the Dalai-Lama”, but that’s a different story.

Now, that’s a real team!

Friday night, Joey, one of the leaders on my team got married.

Mike, another on our team played guitar, and Dave, a friend of ours, conducted the ceremony. My wife, Janna, said it was a beautiful reception, but men only attend such events for the reception—so I’ll skip ahead.

Mike, Janna, and I sat at a table with folks from Joey’s father-in-law’s old neighborhood. They still keep in touch, meeting annually for a combination golf tournament and old neighborhood reunion.

We were the only ones at the table not from the old neighborhood. We didn’t mean to crash their party, but all of the other seats were taken. More people had shown than had originally RSVPed.

“Who are you?” One of them asked.

“I work with Joey.” I replied.

“What does HL stand for?”

“Hard Luck.”

“Really? That should be my name.”

And this conversation repeated every time another from the old neighborhood joined us. However, over the music, one of the wives missed my introduction, and asked Mike, “Who is he?”

“He’s mine and Joey’s manager.” Mike said.

Her husband heard and said—loud enough for the whole table to hear, “Hey! HL is Joey’s boss. He said he just worked with the guy.”

And someone else said, “Now, that’s a real team.”

Indeed, it is.

Building a better Vulcan

Outside of the office, I love nostalgia, but inside, I am the first to promote change. Keep the things that work. Build on those things, and throw out the bad.

However, when Paramount Pictures took this approach with Star Trek, I was afraid of the change. I did not trust that JJ Abrams would be able to handle the job.

This was because I was not Paramount’s Product Owner, and their team did not ask me for buy-in, when they gathered requirements to fix something that I didn’t think was broken.

I was wrong. The movie was great, and I learned a lesson I have been preaching to others for years…

“The needs of the many outweigh the needs of the few.

–Mr. Spock, Wrath of Khan”

This became clear today, as I was reading new words of wisdom this week from Joel “on software” Spolsky…