QA: The roadblock

That’s right – Quality Assurance is just one gigantic road block between you and where you want to go.

These insane people thrive on destruction. They are the rambunctious 3 year old to our new carpet. And what sucks is that we can’t give them a time out!

That means the 1 hour it took to slap together some measly program can take several days because QA found it couldn’t handle special characters, or that only 90% of the functionality works. 90% is pretty darn good, and I’m tired of working on the damn code. Stop breaking it, and we can move on to what I really want to work on!

However, if it weren’t for QA people our product would have several “work-arounds” and we would need 10 times the training and support staff. I also concede that QA adds to the product and reduces the amount of rework. So getting rid of the roadblock isn’t the best solution.

Instead, developers must unite and make the QA position as boring as possible. When QA gets a new piece of functionality, they should get frustrated in their failure to break it. As developers, we need to anticipate their test cases, and try them out ourselves in unit testing. That way we can fix it right then and there and avoid having to see the horrific “bug dance” that QA does when it finds crappy code.

Don’t be pacified.

Want to hear something funny? Mikey (our 9 month old) loves to eat and becomes frustrated when his mouth is blocked by a pacifier. I can’t help but laugh as his eyebrows furl with confusion. He can’t quite figure out why his fistful of peas and carrots aren’t making it to his mouth.

I know he’ll grow out of this predicament, but as adults, we still get hung up on pacifiers. Pacifiers are like business metrics. They are comforting – they provide a quick response to a need. Chomping on trends in inventory turns, employee retention, or productivity measures make us feel more confident that we know our business. We even  make decisions off of them.

Productivity down? Maybe a revenue sharing plan will help.

Delivery estimates continuously off? Maybe we should move to an agile methodology.

First-call resolve percentage low? Maybe help-desk/support training is needed.

Metrics, like pacifiers, have their place. If you need a quick measure in a business presentation, or would like to track performance over time, then use the metrics.

But if you want to understand them and get to the meat of any issue – don’t rely on metrics alone. Instead, dig into the issue – spend time with the people on the front lines, and take the pacifier out of your mouth.

Above all, question your metrics. Do they really capture what you’re trying to measure? What conclusions can you draw out of the metric? What does the metric ignore?

Sometimes another pair of eyes is helpful. This was the case with Mikey. He needed help realizing that his pacifier wasn’t going to help him with his hunger. By the time the pacifier was out of his mouth, the peas and carrots were on the floor. Good thing we have a dog.

Speed Bumps

I did some consulting work for a company in New Jersery that had the following procedure to gain access to a sharepoint folder:

Call the off-shore support team between 7am and 9am Eastern to request access. The support desk will ask for your employee ID and business phone number. Within 48 hours, an automated system will call your phone with the username and password.

We had done some work with this company before – and a previous consultant jumped through the hoops to gain access. So, naturally, some of my fellow co-workers used the already established access.

I was not that wise. Instead, I wanted to help the client maintain their sense of security – even if the procedures seemed like a big speed bump.

When I called up the support desk to explain that I was a consultant and didn’t have an employee ID, they were kind enough to pass me around for an hour. Finally, John (the employee that hired us) gave me his employee ID, and the support desk was ok with using his business phone too. John was on vacation when the automated system called his desk phone. When he got back, he gave me the username & password. It didn’t work, because there was a 24 hour time period in which to login as a new user. The access had expired.

I called the support desk again – and after another hour of being transferred, they were ok with switching John’s business phone to my cell phone temporarily so I can get the automated message.

A couple days later, at 3am, I answered the phone and got a fast, automated message shouting letters and numbers at me. After stumbling around in a dark hotel room for a light, pen, and paper – the message was done. At that point, I decided that the established access would work just fine for me.

It’s important to know where the huge speed-bumps are in an organization. If they slow things down unnecessarily, then employees will learn to swerve to avoid them. A process that everyone avoids is worse than no process at all.

Face to Face

Interesting topics discussed on a recent conference call while waiting for people to join/connect:

• Michael Jackson
• A 5 year-old is terrorizing the neighborhood pets.
• The upcoming 4th of July holiday
• Hotel checkout procedures
• What’s for dinner

These topics were interrupted occasionally by the following:

• The “Now Joining” automated message  that seems to come from a female robot. She sounds so authoritative, that it makes me jump each time she speaks.
• Someone from Tennessee proclaiming, “It’s telling me I have to download the client again.”
• Denver attendee nervously prodding, “Can anyone connect?”
• Ambitious consultant from Orlando, asking “Is <someone of vast importance> on the phone?”

About 30 minutes after the conference call started… the conference call actually started.

I don’t mind hearing about rambunctious 5 year olds, and the 4th of July is one of my favorite holidays – but I think our online semi-anonymous world decreases productivity.

Granted, this was a last minute scheduled demo (go to S3 to ask for one), but I think it would’ve gone a whole lot better if all the participants were gathered around the same table. Call me old-fashioned (correctly), or a techno-phobe (incorrectly), but nothing beats a face-to-face meeting with clients.

With a face-to-face meeting, I’m frankly more interested in the fact that your 5 year old could be running in a street that I could be driving on. I’m also more interested in what you know about the hotel checkout procedures. But of more importance, I can interpret the implicit communication you’re giving and adjust the demo accordingly.

Does the client look confused on a specific screen? Maybe I need to explain that better or ask if they have any questions.

Does the client have a smirk on their face? They may know something I don’t – but I probably should.

Does the client prefer to debate the life and career of Michael Jackson? Then, our software is working fine and they like what they see.

A common question around the S3 office when reviewing requirements is “Did you actually sit down on-site with the client?”  Sometimes this isn’t possible – but when it is, we prefer to be on-site to understand our customer’s needs.

The Artist

On Sunday we took Mikey to the Blanton art museum. Mikey is 8 months old, and he really appreciated how his screeches and screams echoed throughout the modern-art section. Oddly enough, he wasn’t as vocal in the European Art section.

In walking through the various displays, I couldn’t help but think “What is art, really?” I’m sure you’ve had this thought when looking at one piece of art or another.

Simple & Minimal - art or code?

This kind of question can be explained away with some clever phrases. “Beauty is in the eye of the beholder” and “One man’s trash is another man’s treasure”. That’s all well and good, but it doesn’t stop the screaming that Mikey and I do in the modern art section.

If the eye sores I saw could be classified as art, then maybe the functionality we provide to clients can be classified as art. And instead of being called “Developers” we can be “Artists”. (Much like Subway’s “sandwich artist”).

Software, like art, can be beautiful. When the customer can see exactly where a network asset is, or how a trade got executed, or how much money can be saved by catching fraudulent doctors – that’s nothing short of beautiful.

Software, like art, can cause reflection.  Well-built applications can provide data mashing that allow perspectives never thought of before. For example – add geo-coding, traffic, and weather layers to your shipment feed data and you more accurately gauge if a shipment is going to be late.

Software, like art, can be a piece of crap. We’ve all had software that sucks. Sometimes it’s too difficult to understand – other times it just isn’t meeting our needs.

Developers, like artists, have stylistic signatures to the code they are working on. Some developers prefer ansi style joins in their SQL code. Other developers produce comment-heavy code (thank you, by the way).

Developers, like artists, can be creative. Based on limited requirements and a finite set of hardware/tools, developers can design amazing systems that meet and exceed requirements.

Developers, also like artists, can influence the masses. Take a look at Google, for example. An average person uses Google more times a day than they use their office phone.

At S3, we strive to create simplistic, elegant solutions that deliver what our customers need. We are also working on solutions to make your data more revealing and easier to manage. The idea is that if you see your data from a different perspective, it will offer helpful information that you can use to improve your business.

If your data is making you and your children scream, we can help you beat it into shape and create a piece of art out of it. See S3.com for more information.

What does your help desk do for you?

So you have a computer problem. Can’t print. Can’t login anymore. Blue screen of death. Whatever. And you call the help desk. After 20 prompts to help narrow down the issue, you get the standard wait message – “Your call is very important to us. Please wait for the next available agent. We take calls in the order they are received”. So you wait.

You wait long enough to finish reading the book that the boss recommended you read back in 2008.

You wait long enough to start the laundry, pay the bills, feed the kid, and… finish the laundry.

Finally, “Adam” joins the call to help you out.

He goes through the regular script. “We apologize for the long wait, but I am happy to help you with your issue.”

He then asks you for the same information that you were prompted for 3 hours ago. You supply it, begrudgingly, and he starts narrowing down the issue:

“Are the correct cables connected to the correct ports?”
“Did you click on the forget-password button?”
“Have you tried restarting?”

Over the past 3 hours, while waiting for Adam (and the laundry), you’ve tried everything you could think of. So far, Adam isn’t helpful.

So he transfers you.

To make a long story short, you give up. This “help desk” is helpless. They don’t seem to care, they aren’t helpful, and they are wasting your time. We have all experienced this scenario before, and it’s annoying as hell. We switch cable companies, sell our computers, and trade in vehicles because of the support we didn’t receive when we needed it.

What’s my point?
If a company wants to keep its clients, customer support is priority 1.

If the customer can’t operate what you’ve built them, then you are going to lose that customer.

At S3, with our SPS methodology, we make sure that our software works and meets our client’s needs prior to deploying it. So, we have less issues and happier customers than other software firms. In other words, our software does not suck.

However, if an issue does arise, we respond swiftly – supply a work-around if possible, and resolve the root cause. We know that if you experience an issue, others may also experience the same issue – and we need to get it fixed quickly.

Also, if you’re a client of ours, you know that we don’t have a help desk number. Instead, you have the cell phone number of someone who you can talk to directly about the issues you are having. Does your help desk do that?

Sex, Drugs, and Hacking

In college, I had a computer science professor who urged his students to live by 3 simple rules:
1) Don’t have unprotected sex.
2) Don’t experiment with drugs.
3) Don’t be afraid to hack.

Yes, hack. Not in the Swordfish / Office Space / War Games kind of way, but in the ethical / progress-oriented / knowledge building kind of way.

Hacking is defined in wikipedia as:
A community of enthusiast computer programmers and systems designers, originated in the 1960s around the Massachusetts Institute of Technology (MIT)’s Tech Model Railroad Club (TMRC) and MIT Artificial Intelligence Laboratory.

There are two points I want to drive with that definition:
1) Sometimes good things do come out of MIT.
2) Hacking, in it’s true definition, is not bad.

Programmers have grown lazy. Re-use is great, but when a programmer spends 90% of his/her time copying code from one place to another – then where is the original thought? Where is the progress? Where is my flying car?

Stated simply, hacking is needed for innovation. To survive and grow, businesses should encourage their employees to hack.

At S3 – 15% of developer time is spent on employee-led independent projects. These projects do not have to be tied to a revenue stream and there are no set limits to what the employee could do. So far, the developers have challenged themselves with the projects they have chosen. Hacking was necessary. Some of these projects may never see the light of day – but the knowledge gained in working on them will likely be applied to future applications.

Micrometer, crayon, and Ax

Around 2006 I took a job in Austin just to get to Austin (more on that later). One of the first people I met at my new job was Erik. Erik was a consultant most of his professional life, and he had a saying:

“Measure with a micrometer, mark with a crayon, and cut with an ax”.

This saying, I found, is quite appropriate for requirement gathering.

The micrometer is used when first gathering requirements. At this stage it’s difficult to determine what is needed versus what is wanted. So, everything should be written down and explored.

A customer may say:

I need an application to e-mail the vendor every time an order comes into the system.

Using our micro-meter, we dig deeper to understand what exactly is needed. Why does a vendor need to be notified when an order comes into the system? What orders come into the system? Are all vendors notified? Is e-mail an appropriate tool to use for notification?

After several rounds of measuring, we may find the requirements are really the following:

Determine which vendor is suitable for a new order coming into the system based on the lowest vendor-supplied price for the product being ordered. Notify the vendor over e-mail about the order – include the product number, quantity, order number, and expected delivery date. Accept EDI-856 files real time from all vendors to update shipping information for the orders. Notify order manager via e-mail if a EDI-856 pushes the expected delivery date (late shipment).

With a crayon, we define the broad requirements:
1) Determine suitable vendor based on lowest vendor supplied price and notify that vendor of their orders.
2) Accept EDI 856 files from vendors to update shipment information and notify the order manager of late shipments.

Now we can use our ax.
The ax is used to prioritize, scope, and deliver at a level that is both attainable to the delivery team (within a short time-frame) and beneficial to the customer.

In talking with the customer, we may find that the number one priority is to accept the EDI files to update shipment information and notify the order manager of late shipments.

Through this process, we did not lose any of the finite requirements gathered using our micro-meter, or the broad requirements defined by using our crayon. Since priorities always change, we can always come back and work on what we defined earlier.

The 1 week delivery timeframe

At s3, our goal is deliver the most needed functionality for a customer within 1 week. Bug-free. To accomplish that goal, the s3 culture, methodology, and even its logo has changed.

I joined s3 in September 2008. At that time, a business analyst’s job was to gather requirements, design, develop, and hand it off to QA.

It wasn’t delivered bug-free within a week though. Not blaming QA, they are doing their jobs here. They would take the functionality and inevitably have questions about it:

“What does the customer want to do with this?”

“Why does the customer need this so quickly?”

“What does the customer actually need out of this request?”

 

Those questions occured many times too late in the product development lifecycle to ensure quick, bug-free deployment.

In the new model, S3 attempts to understand customer needs before design and development. We move those questions to the front of the process, before the request gets to the delivery team. We now  know before design starts that the customer wants X,Y,Z… but the customer really only needs X right now – and they need it quickly. 

So delivery can now design and develop X. And they work with QA every step of the way – from understanding what X is to deploying X. 

This new model allows us to be more efficient, precise, and quicker with our delivery when the requirements are known. Many times however, the customer doesn’t know what they want. Or, more often, there are many user groups for the functionality being delivered and they all have different needs for the same functionality. 

How does the s3 model handle that? Is our 1-week goal blown out of the water when requirements are changing every day?

This is where the logo change comes into effect. Challenge Everything. Works pretty well for software development – does not work well with the wife. “Challenge Everything” is prevalent at S3 and is at all levels. New hires challenge the CEO, QA challenges Delivery, Delivery challanges BAs, and BAs challenge the customer. Even the logo change was challenged. 

So, aren’t we going to piss off our customers by challenging everything? This is where the culture change occurs. The customer is the one paying us to do this work and if we don’t understand the requirements then we need to challenge them about it to ensure the they are getting their money’s worth. 

A client came in for a massage at my wife’s business yesterday really wanting a Deep Tissue Massage. If you’ve never had a massage before, deep tissue is not the relaxing kind. It involves deep muscles and is used a lot for physical therapy patients. My wife had no hesitency to ask the client why they believed they needed deep tissue massage. The client replied “I have a lot of knots and it’s the only thing that can get them”. This isn’t a very likely answer, so my wife started with firm-swedish and concentrated on the knots. She worked on what the client needed – the knots to be removed. At the end of the session, the client booked another massage and left relaxed.

Through challenge everything, a common language would be achieved – when the client says “deep tissue” they really mean “firm-swedish”. Once the common language is there, requirements are more solid – we understand with more clarity what the customer needs and we can deliver quickly and bug-free with confidence.