Random Thoughts – Randocity!

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 5 | Chapter Index | Part 7 →