Random Thoughts – Randocity!

How not to run a business (Part 6): Coding Edition

Posted in best practices, business by commorancy on August 6, 2013

So… you decide to open a business to write and sell software. Your business can choose from several different software development methodologies and strategies to help you get that software off the ground. You can choose the waterfall approach or use an agile approach. There are many approaches that can work, but all approaches have both benefits and drawbacks. Depending on the type of business your company is in, you need to think through how each type of coding method can affect your customer. Note that the goal behind most methods of development is to drive the process to completion, not so much to provide quality. With either Agile or Waterfall, both approaches can let you down if you’re not actively driving quality all along the way. Let’s explore.

Don’t choose a software development strategy just because you think it will allow you to complete the software on time. Any strategy you employ must make sure quality is number one or you face customer problems. Simply getting the software done and on time is not enough. Quality has to remain at the top for any software your team writes.

Don’t let your customers become guinea pigs. Software development is for your customers’ benefit. Thoroughly testing code is important. Don’t let this fall through the cracks or your customers will suffer the consequences and end up as beta testers.

Don’t employ only happy path programming efforts when writing code. Coding solely for the happy path leaves your customers vulnerable to the unhappy paths. Coding for happy path is equivalent to intentionally skipping big pieces of testing. Your customer will pay the price when they fall into an unhappy path trap. Your staff then has to respond by spending time doing data fixups, writing patches to fix holes missed and your sales/support teams will be on the phone to customers giving false reassurances.

Don’t miss crucial QA steps just because you ran out of time. If time is the most important thing when coding, then the code quality will suffer and and so will your customer. Again, do not use your customers as guinea pigs unless you like them walking away from your business.

Let’s understand more why the above is important!

The Happy Path is not happy for your customers. Utilizing Happy Path coding is solely for the convenience and benefit of your programmers in getting work done rapidly. Getting things done rapidly, but poorly is not good for your business or your customer. Happy Path software development simply doesn’t work.

As an example, imagine walking down a block in downtown NYC. You walk the block from corner to corner without any diversions or problems arising. Let’s call this the Happy Path. Now, let’s say you walk that walk again, but this time you stumble over a manhole and fall. You were so focused on the destination, you didn’t pay attention to the manhole cover that wasn’t fully closed. This is an unhappy path. Let’s say that the next time you walk this path, you know the manhole over isn’t fully closed and you avoid it. Except this time you were so focused on avoiding the manhole cover, you walk into a tree. Yet another unhappy path.

Now, imagine this is your customer. Each time they try to navigate down your Happy Path, they fall into one trap after another because your software doesn’t handle these pitfalls. Writing code solely for the Happy Path is definitely not your business friend. Your customers will become frustrated and eventually find another company with a more stable product. It doesn’t matter how good the features are, it matters that the software is stable. A customer places trust in your software, but that trust is broken when the software breaks often.

Coding for your customer

Your customer is the most important thing you have in your business. They drive your revenue and keep you in business. You should never play games with them and you should never use them as paid beta testers. But, writing code that only utilizes the Happy Path intentionally leads your customers and your company into unhappy pitfalls. Wouldn’t you rather have your team find these pitfalls before your customer does? When your customer finds the bug before you do, it makes your team and company look inept. This is never a good position to be in, especially when you are trying to establish yourself as high quality software company.

The Happy Path may only provide between 20-50% tested code paths. The other 50-80% is left to be tested by your customer while they pay for and use your product? The Happy Path only leads to unhappy customers. Instead, if your software developers test a Robust Path all along the way, your software should catch at least 80-90% of the bugs leaving very small percentage of edge case bugs for your customers to find. So, instead of having your team working on constant bug fixes and/or constantly fixing or restoring customer data, your team can focus on the next product release features. Unfortunately, customer fixups and customer phone calls over these issues are big time wasters. Wasted time that can be completely avoided by writing the code correctly the first time.

The reality is when writing software, your team can either spend their time on crash proofing code up front or spend even more time crash proofing the code after it’s already in production and making the customer unhappy. Either way, the problems will get fixed. It’s just that you, as a company owner, need to decide whether it’s more important to have happy satisfied customers or a fast development cycle. You can’t really have both. Customers become especially disenchanted when they’re paying a hefty fee to you for your service and end up beta testers. Customers are always expecting solid robust code. They don’t pay to be beta testers.

Customer Churn

Keeping the customer happy should always be your number one priority. Unfortunately, you can’t do that if the code that’s being written is crashing and generally providing a less than stellar experience to your customers. You have to decide if you want your team to spend their time bug-proofing the code or have even more of your staff spend their time after the release smoothing out customer dissatisfaction issues in combination with bug fixes. So, not only is your sales team’s and customer care team’s time spent making the customer happy again, your engineering team’s time is being incorrectly spent having to rewrite code a second, third or fourth time to fix bugs. Depending on your SLAs, you might even be violating these by having certain bugs.

This can mean at least three times more work created for your staff than simply having your developers write robust code from the beginning. Sure, it might require a month longer development cycle, a bigger QA test cycle, but that extra time will pay for itself in having happy satisfied paying customers and fewer customer incidents. Customer satisfaction keeps your development team focused on the next feature set, keeps your sales team focused on new sales and keeps your customer support team educating users about how to use your product. Quality is the key, not speed.

Bug Fixing after a Release

I’m not saying there won’t be bugs to fix or unhappy customers. Bugs will be found even if your team appears to write the most perfect code. However, writing high quality code from the beginning will drastically reduce the cycle of bug fixing and patches. This means making sure your development staff are all trained and knowledgeable about the languages they are required to use. Introducing new programming languages without proper training is a recipe for problems. Learning a new language on the go is the best way to write bad code. Properly trained engineers will usually provide much higher quality code. Don’t ignore the Quality Assurance team’s role in making sure they have a full and complete test suite and solid full test cases. Unit testing works okay for developers, but once the code is all assembled, it needs a full QA test suite.

Also, if your feature set doesn’t cover your customer’s needs properly, satisfaction can also drop. This can happen if your business is fighting bad code rather than listening to what your customers want. Of course, this is a somewhat separate issue which I will discuss in another installment.

Java

I want to take a moment to discuss using Java for applications. Using Java is, again, a convenience to support speed coding efforts. More and more companies want it done ‘fast’.

With more and more compressed timelines, too many people seem to think that writing software in Java is easy, quick and simple. This is a fallacy. It isn’t. While writing the code may appear simple at first glance, the whole JVM adds a huge level of operating complexity that engineers and management fail to understand or simply overlook. In theory, you should be able to deploy your .jar file and be done with it. It’s not that simple. The JVM has heap space sizing issues and garbage collection that can easily turn what seems reasonable code into a nightmare for your operations team to support and a nightmare your customers. Basically, the JVM is an unpredictable beast.

Let’s understand this better. The JVM tries to make coding simple and easy because it’s interpreted. That thinking is a trap. From a coding perspective, it does make coding a whole lot easier as there are lots of frameworks that can be used and code examples to be had. Unfortunately, nothing ever comes for free. There are always strings attached. Java does a whole lot of internal housekeeping so the coder doesn’t have to. This ease of writing the code is completely negated by the JVM itself. To help the coder to not deal with extra coding of freeing up variables and objects, the JVM takes care of all of that. But, the price paid is the Garbage Collector. So, instead, of coder doing this work in code, the Garbage Collector (GC) allegedly does this for you. We won’t even get into just how ugly and horrible the JVM logging is when you’re trying to determine what went wrong.

In reality, the GC can end up spending so much time doing all of this extraneous cleanup work that no actual code work gets done. The reasons behind this issue can range from bad java code (e.g., object leaks, memory leaks, file descriptor leaks, etc) to huge swings in memory usage (creating GB sized objects and freeing them up often). As Big Data is becoming more common place, the JVM really was not designed to properly handle Big Data objects strictly because of the overhead of the GC. That means you need to have someone who’s extremely knowledgeable about tweaking the JVM’s heap sizes, GC frequency and other tweakable parameters inside the JVM so that it doesn’t get into this condition. It also means much more precise monitoring to determine when it is in this condition.

In some Java use cases with big data, using Java may not even work. If you really need to move big data around fast, you should really consider a compiled language first.

In essence, the engineering team has now pushed the normal robust coding and cleanup work off onto the operations team to manage via the JVM container. Now the operations team have to become experts in JVM management through managing and tweaking Java to keep it properly tuned and working. Worse, they now have to understand the code to even begin to diagnose a root cause of failure. In other words, it requires your operations staff have a much higher level of knowledge about java, java coding and JVMs than when using languages that don’t require Java.

Using C, C++ or other compiled languages

Even though compiled languages can require a much longer development cycle and more explicit handling of objects, they do two things for your company: 1) Forces your development team to write better code and 2) Gets rid of interpreted languages (and containers). Even above the tremendous speed gain your application will see from being compiled, the operations overhead to manage the application is drastically reduced. Writing a UNIX daemon to handle an operational task might require a simple configuration file and a ‘service’ script to restart it. No knowledge of a JVM container, of GC or of heap sizes is required.

Memory usage is always a concern, but not in the same way as Java works. In fact, it’s far far simpler to both troubleshoot and manage compiled applications than it is to troubleshoot and manage JVM container apps. If a compiled app goes off the rails, you know for certain that it was the app that did it. If a JVM contained app goes off the rails, you don’t know if it was the app itself or the JVM container that spiraled out of control.

When a JVM contained app fails, you’re left trying to determine if it was a bug in your company’s code running in the container, if it was a bug in Oracle’s Java version itself or if it was a third party component problem. This leaves too many variables to try and diagnose at once. With compiled languages, this troubleshooting is almost always far less ambiguous and is usually as simple as ‘strace’, ‘top’ or reviewing a core dump.

Business Choices

Whatever approach your team chooses, quality must remain number one. When quality is sacrificed for the sake of development speed, your customers will suffer and, in turn, so will the bottom line. Some customers may be willing to deal with a bug occasionally. But, if bugs are continual and constant after every release, eventually they will go find another service. Stability and reliability are the key to making sure your company continues to succeed no matter whether your company provides an iPad app or if your company intends to become the next Google. Innovation keeps your customers coming back from more, but you can’t innovate if your team is constantly fighting bad code.

Part 5Chapter IndexPart 7

Advertisements

Shopping Frustration: When coupon codes don’t work

Posted in shopping by commorancy on September 4, 2012

Nothing is more frustrating during online shopping than when e-tailers send out a coupon code for a one day sale that doesn’t work.  I have to wonder, are these sites just stupid, clueless or technically inept?  Let’x explore.

Holiday Shopping Spree

If you’re like me, I tend to shop for things when people send me coupon codes.  Specifically, I shop when things are wearing out. I try to make sure these purchase times match up when coupon codes are available.  So, I like to wait for sale days like Memorial Day, President’s Day or, like today, Labor Day.  So, I’m happy when companies where I like to shop send me a 20% or 30% off coupon.  I generally like to take advantage of these deals because they don’t appear that frequently and I can shop for clothes that are wearing out.

Clickable Ad Banners in Email

Unfortunately, many of these e-tail sites are so inept or mismanaged that they email out the code but they forget to activate the code.  Sometimes they deactivate it too early.  Worse, they send an email with a big clickable banner ad describing this ‘Sale’ that, when you click, takes you to their home page and not to the sale items that apply to the code.  This action leaves you wondering what the heck is actually on sale?   One word comes to mind: inept.  Retailers, this is a seriously stupid practice.  If you send out an email that you’re having a 20% off sale, a click should immediately take you to the sales item(s).  Don’t make your customers guess what’s on sale.   In the case where I am taken to the front page, I close the browser, delete the email and move on.  Sorry, you’ve just lost a sale and I simply won’t shop there.  I know I’m not alone in this.  A lot of people fill their carts and either abandon the cart or clear it out because of stupid things like coupon codes that don’t work.

Coupon Codes that Don’t Work

I’ve had many times where some company sends me a coupon code that when you type it into the cart and click ‘Apply’, the message says ‘This coupon is not valid’ or ‘This coupon does not apply to the items in your cart’.  This goes back to the above issue.  If you’re planning to issue a coupon code and spend the time and effort to email your email list with this code, you damned well better test that code to make sure it works and you damned well better make sure the customers know to which items the code applies.  Don’t make your customers guess.  Additionally, for 24 hour sales, you should make also sure that code works until midnight.  And by this I mean, make sure it works until midnight of the customer’s timezone, not just your company’s timezone. That coupon should not expire at midnight your company’s timezone time as that could be midday in some locales. The code should expire at midnight wherever your shopper resides or better, expire it the following day sometime during the day to prevent expiration before the day is over for every customer and also lets late customers take advantage.  After all, isn’t the idea behind a coupon code to get people into your site to purchase?

Customers walking away

Making stupid moves like not activating coupons, deactivating them early or making your customers guess as to what merchandise the coupon applies is just a stupid practice.  You probably think I’m talking about small mom-and-pop shops here.  No, these are well known well respected companies that are making these most basic mistakes, like Jockey, Tommy Bahama and Zagg.

Nothing is more frustrating than filling up your cart with merchandise expecting to use a coupon code only to find that it doesn’t work.  Or, worse, not finding the merchandise to which the sale or coupon applies.  In these cases, I empty the cart, close the browser window and delete the email.  If these companies do this more than once,  I remove myself from their email list as it’s quite clear that these companies do not have their act together.  Which, if you think about it, is completely odd.  These are retailers in business to make money.  If you’re planning to offer a sale that uses a coupon code and that code doesn’t work, do you really think people are going to pay full price anyway?  No.  Selling your merchandise is your bread and butter and if you want people to buy your stuff, then you need to make sure your email ads reflect the reality of your site.  If it doesn’t work, then you have even more serious issues on your hands, not the least of which might be considered fraud.

Amazon Better?

I just don’t understand this practice.  This is why Amazon is kicking butt.  With Prime, you get 2 day shipping included and the best price without hassling with coupon codes.  Sure, you might be able to find it slightly cheaper at some mom-and-pop shop.  But, the hassle of setting up a new account and dealing with yet more email that can’t do it right outweighs the few pennies of savings you might get from that mom-and-pop shop.  So, I always find myself back at Amazon buying, at least for hassle-free purchasing.  I don’t want to deal with coupon codes that don’t work, sites that don’t specify what’s on sale or silly stupid problems like this.

For those sites that do this, fix your sites or lose the sale and be trampled by Amazon.  It’s quite simple.

Amazon Kindle: Buyer’s Security Warning

Posted in best practices, computers, family, security, shopping by commorancy on May 4, 2012

If you’re thinking of purchasing a Kindle or Kindle Fire, beware. Amazon ships the Kindle pre-registered to your account in advance while the item being shipped. What does that mean? It means that the device is ready to make purchases right from your account without being in your possession. Amazon does this to make it ‘easy’. Unfortunately, this is a huge security risk. You need to take some precautions before the Kindle arrives.

Why is this a risk?

If the package gets stolen, it becomes not only a hassle to get the device replaced, it means the thief can rack up purchases for that device from your Amazon account on your registered credit card without you being immediately aware. The bigger security problem, however, is that the Kindle does not require a login and password to purchase content. Once registered to your account, it means the device is already given consent to purchase without any further security. Because the Kindle does not require a password to purchase content, unlike the iPad which asks for a password to purchase, the Kindle can easily purchase content right on your credit card without any further prompts. You will only find out about the purchases after they have been made through email receipts. At this point, you will have to dispute the charges with Amazon and, likely, with your bank.

This is bad on many levels, but it’s especially bad while the item is in transit until you receive the device in the mail. If the device is stolen in transit, your account could end up being charged for content by the thief, as described above. Also, if you have a child that you would like to use the device, they can also make easy purchases because it’s registered and requires no additional passwords. They just click and you’ve bought.

What to do?

When you order a Kindle, you will want to find and de-register that Kindle (may take 24 hours before it appears) until it safely arrives into your possession and is working as you expect. You can find the Kindles registered to your account by clicking (from the front page while logged in) ‘Your Account->Manage Your Kindle‘  menu then click ‘Manage Your Devices‘ in the left side panel. From here, look for any Kindles you may have recently purchased and click ‘Deregister’. Follow through any prompts until they are unregistered. This will unregister that device. You can re-register the device when it arrives.

If you’re concerned that your child may make unauthorized purchases, either don’t let them use your Kindle or de-register the Kindle each time you give the device to your child. They can use the content that’s on the device, but they cannot make any further purchases unless you re-register the device.

Kindle as a Gift

Still a problem. Amazon doesn’t recognize gift purchases any differently. If you are buying a Kindle for a friend, co-worker or even as a giveaway for your company’s party, you will want to explicitly find the purchased Kindle in your account and de-register it. Otherwise, the person who receives the device could potentially rack up purchases on your account without you knowing.

Shame on Amazon

Amazon should stop this practice of pre-registering Kindles pronto. All Kindles should only register to the account after the device has arrived in the possession of the rightful owner. Then, and only then, should the device be registered to the consumer’s Amazon account as part of the setup process using an authorized Amazon login and password (or by doing it in the Manage devices section of the Amazon account). The consumer should be the sole responsible party to authorize all devices to their account. Amazon needs to stop pre-registering of devices before the item ships. This is a bad practice and a huge security risk to the holder of the Amazon account who purchased the Kindle. It also makes gifting Kindles extremely problematic. Amazon, it’s time to stop this bad security practice or place more security mechanisms on the Kindle before a purchase can be made.

Tagged with: , , ,
%d bloggers like this: