Blaazin Software Consulting Inc.: Software

Showing posts with label Software. Show all posts

It's been my experience that there are two camps as it pertains to the writing and use of Unit Tests. Those who are for them say it saves time and money, as the saving of one = the savings of the other and those against them complain about the time and repetitiveness of writing them.

Automated Unit Tests Save Time and Money

My first position in the Software Development industry was installing and supporting software at the Client's site. We would download the latest build from the Development team, install, test, and report any issues found. With any luck, we found and fixed any problems before the Client saw them. Too often, though they found them first. It is with this first experience as a fledgling member of a new company that I would start to see the challenges NOT having high quality, automated Unit Tests. Too many times to count I was left scrambling trying to resolve new issues in code both old and new.

With this new perspective of what DOESN'T work I was determined to improve quality. When I was promoted to Development that is precisely what I started with. It is with that, that I ran into the below challenges:

Reluctance

I began writing Unit tests, and encouraged other developers to do the same. I gave several 'Lunch-N-Learn' seminars and demonstrations on how to write good Unit Tests, Test Driven Development, and showed the time-savings associated with it. To my surprise, most Developers still didn't want to write tests. Writing Unit Tests was a task that was (in their mind) unnecessary, time-consuming, and actually took time away from adding functionality. After all, their bonuses were based on functionality added, not tested.

Code Coverage

As I continued to write my tests, I also added coverage reports to the build process. Management liked to be able to see how much of the code was covered by automated tests, and had the other developers cover any new code by 80% line coverage.

That seemed like a good idea, and - to be honest - I was all for it. What I didn't foresee was that the other developers continued to view writing tests as a waste of time. They were writing their tests AFTER their functionality had been added and tested, and put the bare minimum effort into them. So, their tests were ~~akin to that of a dogs breakfast~~, terrible. They would write a test that invoked their code, and it would succeed as long as no errors were thrown. They included no checks to verify that the code actually did what was intended to do, nor had any testing of edge case or failing conditions. Yes, they met the 80% code coverage rule to appease Management, but their tests weren't actually testing anything. The only thing the tests verified with any degree of certainty is that no error was thrown when using the exact case the test was.

False Sense of Security

From a code quality perspective, having no tests is better than having tests that don't actually test anything. Having automated tests and associated coverage reports gives the feeling of security in the quality of the software, but given that those tests didn't actually do anything, that feeling is completely unjustified and misleading.

Unit Test Quality

Code coverage by itself cannot be used to determine the quality of automated Unit Tests. The only way to determine how good a suite of unit tests are is to review the tests manually. Each method under test should have several test cases testing a variety of different input parameters, check to ensure the method did what it was supposed to, handles errors appropriately, and verifies the outcome.

So What's The Upside? How Can We Change Perceptions?

There can be much resistance to writing tests, and shoddy tests written to achieve this 80% line coverage management seems to have fallen in love with. The question becomes how can we show that this upfront effort will save time and money? How can we show that branch coverage is preferable and the quality of testing is vital to ensure the usefulness of the procedure?

The Code - Deploy - Start Container - Navigate - Test - Debug Cycle

Following Test Driven Development practices actually saves development time for me. Most software runs in some type of container (i.e. web server, mobile OS, etc.), therefore to test it the way a User would see it requires that the code be deployed to the container, and the container itself be started. The cycle of code --> deploy --> start the container --> navigate to area of application --> test, can be a long one. If you do this process over and over again, you can see where the time gets wasted. However, if the code is running tests, this process is reduced to a fraction of the time (even better if mocked tests are used). Plus, the tests could (and I argue should) be executing different scenarios, so many scenarios are being tested at the same time during the development phase. If you are using an expensive tool that does not require the container to be restarted when code changes are made, the start-up process is removed, but you are still able to test only one scenario at a time. I have worked on projects where it was extremely difficult (and therefore time consuming) to set up the data from one scenario to another. Automated Unit Tests change all that.

Cost Savings

It is industry-wide knowledge that the cost of fixing a problem in Production code is greater than fixing it during the Development phase.

More scenarios running more often as early as possible in the life of the software means any bugs are found earlier on, whether automated or manual. But, automated tests run faster, and can run more often (i.e. on a scheduled basis), so bugs are found earlier, and are therefore less expensive to fix.

Quality Code Stands the Test of Time

Any good piece of software will be continuously improved, added to, and ultimately changed (this is called Refactoring) throughout its lifetime. The only way to ensure that it still works as it was intended is to test it; and test all scenarios. This can be done manually, but as new functionality is typically added to products, this manual process can take longer and longer each release. If these scenarios are automated, they can be executed and the results validated very quickly.

Attrition

People do not stay in an organization forever. Be it the Developer(s) who wrote the code, or the Tester(s) who tested it, or the Business People who thought it up, eventually, those people move on. Having tests automated in code ensures that the original functionality works as it was intended, and there's always a record of what it does, and how to use it.

Automated Unit Tests Save Time and Money

I have heard almost every reason (excuse) to not write Automated Unit Tests. I have found each and every one of them to be completely untrue, and generally spoken by Developers who just don't know how to write proper tests.

Picture credit: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggjxxKISvxdmRw0TyzxyuFiRTci7Z3ikZBal77aB_UaZac0WqJelryd0cT-O8jPnwzb9JwPoIneOSx7H09_95RINBMr6Pi1MDjCgcTeYLTcjKUhYLZdf9Yvh8sptKSjfuUA-8GGCEj7zTH/s320/bigstock-Timeismoney-81634613.jpg

Picture Credit: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlzvITPXbuXoHybvBFWvNC4_gLU7dAIY0pZY7hC-UTeiGV_kg8_ZULMbcymTJUqwL5zgEqPnPzP_xLfUT65MttFs33aE_Ueqe2HT8pvbNATIEm9sCz7LEUDzkffzqNWqcmOcWM8x6YcQHS/s320/Code+Coverage.jpg

Picture Credit: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisOs1vsZHEPts57DsATS-hWq1k8nkWaiHTChbyoynadbclviq56_Ifv3tEzvnLPZ1E-fWQmRLTbJReSco5ibkvkCeju_dK3RGSkbFtlyTGkIMi-E3UCDohlcmhM92BqYuwbcLwXYV8nUQB/s200/continuous-integration.png

Picture Credit: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgM0eqeuccBCyGdZmZkVxwKMatWVAniOA36so5KJ-HLkxKD29caiDXg6F9SFVJ4oxFVpHmV8aaDCn8A7kyHWarzOsCjW2-FN9sBGg39nhGXY03ki9RP_LHPZycboBnMU9H0VgH0zT2qA8xB/s320/relativecostbugfix.png

Picture Credit: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhovhnUylpWZyZReL94JniDGPs0JrWHIvJGD-Vri3Ic9IG9_1f-J87EkGB4H5ColVyNsfGd_i-tbuJQyMMZke1shcyYQqPZQmVlLqRs3z9fIm5ZUQ_ZttXNMbsKUf_PcApva_fT2m1Yb2GN/s320/Cost+Automated+VS+Manual+Testing.png

Automation , Code Coverage , Development , Information Technology , Quality , Software , Test driven Development , Testing , Unit Testing , UnitTesting , writing Unit tests , 0 Comments

This is a topic that I have dealt with on a first hand basis. My experiences with off-shoring and my general dislike of the practice stem from my intimate interaction with the process. I will not say that ALL off-shoring agencies will have ALL of these issues. What I will say is, not in a million years would I suggest a company take this avenue.

The drawbacks I am referring to were actually a series of smaller issues that piled on top of each other, and that lead to disaster.

Communication

At first, it was minor communication issues between us and the offshore development team. As good as requirements can be, there will always be questions or clarifications from Development to Business. To communicate with us, the process they had in place was for the development team to communicate through their Project Manager (who was in our time zone), and the PM would talk with us. This cycle took a full day in most cases (due to the time zone issue). A few questions lead to additional questions, and this resulting in some issues taking up to a week to be fully answered. To address this, the development team began working during our work time. As an unintended consequence, the Team Lead (who was female) didn't feel safe enough to leave the office at night, so she slept at the office during the week.

Attrition

At almost the halfway point to the project (about 5 months in), we began to notice significant issues with quality, and deliverables not being met. It took us a while to get to the bottom of it, but what had happened was a few senior developers had left the company (one of which was from our project). What the company did was move one senior developer off our project, and put them on another (to cover that project). That left our project without 2 senior developers. As part of the contract, we were to have those senior developers, so their company promoted two junior developers to senior to cover them contractually. They then hired two entry-level developers for our project, and called them junior developers.

Quality

We were left with one Team Lead, one senior developer, and 6 junior / entry-level developers. Not surprisingly, the quality of the application suffered greatly. Defects we could handle, but it was the lack of experience in coding that lead to significant PERFORMANCE problems. Our application was expected to handle a large amount of data in real-time, and due to the way the application was built, it would not perform anywhere near the pre-defined requirements. What followed was attempts to refactor areas of the application, and - although performance improved - that refactoring was not able to meet our performance requirements (or that of our End Users). As a last-ditch effort, some areas of the application were re-written, but it was too late.

To be fair, I believe the re-written pieces of the application would have met our performance criteria.

Outcome

With the communication issues, and lack of experienced developers, the project had significant quality and performance issues. The delivery date (for us and our client) was missed, and the make-up date was also missed. With the state the application was in, combined with an uncertainty of completion date, our client pulled the plug on the project.

What ended up happening was we lost the client, the client sued the company I worked for, the company I worked for sued the offshore development company, and the two people in our company who recommended off-shoring lost their jobs.

Conclusion

When looking for a Software Vendor, ask yourself if the benefit (which is ONLY cost) is really worth the risks and drawbacks, and potentially negative outcomes (which are many).

What I can say is that due to my experiences with Off-shoring software development, there is no power on earth that would make me go that route; the stakes are just too high to gamble.

Development , Information Technology , IT , Off-shore , Off-Shoring , Out-Source , Out-Sourcing , Programming , Small business , Software , 0 Comments

With Black Friday, Cyber Monday, and Christmas just around the bend, is your company ready to take in some of the money flying around the Internet? Is your business setup to partake in the joy of online sales? You know that sunny spot in your business where your customers come to YOU in the hopes of buying that thing you offer to make the person in their lives overjoyed?

Listen, very rarely will people be so willing to separate from their cash as they will this time of year. Nothing is higher on peoples list than making those people they love happy. It's a need that drives people to scour the internet looking for YOU. Last year in just the U.S. there was an estimated 191.1 million online shoppers, by 2018 they are projecting that number to be 215.1 million (http://www.statista.com/statistics/183755/number-of-us-internet-shoppers-since-2009/). Can your company afford to miss the opportunity of this growth?

You may be thinking well wait... I don't have a product, I sell services. Bundle those services people. i.e. you teach Yoga: offer a 10 class pass or perhaps a specialty offering for those who are elderly or wanting advanced sessions. Any service can be packaged. Be unique. Look for niche markets; offer something people don't see often that would be enticing.

How can we allow Amazon to boast $67.86 Billion U.S. dollars in e-commerce revenues in 2013 and not do something to try and siphon some of that (http://www.statista.com/statistics/293089/leading-e-retailers-ranked-by-annual-web-e-commerce-sales/)? What they do right is ease of use, reviews on products, free shipping on some of their items over a certain dollar value, a return without questions policy and all from the comfort of my couch.

You can make this happen for your company. You just need to know what your offerings are and we can make it happen.

Automation , business , Development , entrepreneur , ideas , innovation , IT , marketing , online sales , online shopping , Small business , Software , 0 Comments

Last week, as I was on my way home, the dreaded 'Check Engine' light came on in my car. I managed to slowly limp home, and immediately my wife made an appointment to take my car to a big-name franchise to have the problem found (she's so much better at that stuff than I am - I would have made the problem worse by trying to 'fix' something myself).

The appointment was set for Saturday morning, 8:00am.

I prepared myself for what I was to expect. I was going to get the news that the transmission was almost dead, and would need either a new one, or a rebuild. No matter what, I expected to grab my ankles. Saturday rolls around, I get my car to the garage, stroll up to the desk, and announce my name to Jerry (I know it was Jerry because that was the name on his overalls). It was then that I got my first surprise of the day. It wasn't a huge thing, but having been immersed in software for the past 15 years, I was shocked to see that the appointment book was exactly that: an appointment book! Complete with names and times (written in pen). Appointment changes were done by drawing a line from the original time-slot to the new one. Cancellations: you guessed it; the names were crossed out. I didn't see any, but I'd be willing to bet that there was White-Out in there somewhere.

That got me thinking about how many businesses are still using manual processes? I'm sure they work well provided things stay the same, but what happens as the business expands? What happens if Jerry spills his coffee on the appointment book?

Ultimately, it boils down to one piece of imagery: How many people still beat their laundry on a rock in the river?

The rock worked fine: the clothes were clean. I know what you're thinking. Having washing and drying machines in our homes is a lot more convenient. I can't imagine how many hours are saved by being able to wash laundry at the same time as any other task in our overly-busy lives. Not to mention the quality of the washing itself; beating clothes against a rock definitely reduces its wearable life.

Business processes are no different. Manual processes do work for a short time, but cannot compare to the speed, quality, and reliability of having those same processes automated via software.

Companies seem to view software as a tool for a company to interact with their clients or customers. They focus on their online stores, advertising and selling their products. Business is more than just sales, it's how the processes function as a unit. It is true that more sales mean great things to companies, but saving costs is just as good. There is no greater cost savings than saving time, and that is what automating processes in software does. All systems can be seamlessly integrated.

How do you plan to better your business?

Don't let your business processes fold in on itself because of Jerry's haphazard coffee. In this scenario we would create one system that could schedule appointments and bill clients, as well as contact them in the future for marketing and advertising. All this done seamlessly (and in the blink of an eye).