Obamacare Website Still Down Despite New Vendor

Obamacare Website Problems Continue Despite New Vendor

Throughout the weekend and even again today the Obamacare website problems continue and the site is still offline much of the time. Katherine Sebelius was touting the new “Hub” as one part of the Obamacare website that was working only to have it go down the next day. In looking at the site today (Monday, October 28 @9:30 Pacific) here’s what we’re currently seeing:

Screen Shot 2013-10-28 at 9.26.11 AM It looks like the government has chosen contractors who don’t have much credibility in being able to fix the issues. The part that we find most strange is that it appears that these “fixes” are not going for deployment to a test site and are again not going through a software quality assurance process to ensure that things are really working  before being deployed to production.

Originally my thoughts were that the site’s issues had the potential to be resolved without having to do a complete ground-up rewrite of things, but with the inept new triage updates things aren’t looking progressive.

Our suggestion is to follow much of what we suggested in our first article. Trying to make piecemeal untested solutions will just further compound the problems.

Don’t Let the Obamacare Website Problems Happen to Your Business

Don’t Let Obamacare Website Problems Happen to You

With all of the news about Obamacare, at the center of the controversy is whether the $292 million dollar Obamacare website works at all and more importantly will it ever work. Aside from the politics, what exactly is wrong with healthcare.gov and what can we learn from its failures to protect our businesses and software projects?

Countless people throughout the country have attempted to sign up for Obamacare, but have been unsuccessful. Even after days of trying, off-hour attempts in the middle of the night, for many the process has been completely frustrating and fruitless. Why is the healthcare.gov website failing? It’s failing because the website software and systems that support the site just aren’t built reliably enough to even allow successfully signing up its services. In a nutshell, the crux of the problem is that the overall solution was never properly tested in a way that would allow for the issues to be found and be resolved.

Read more

How To Execute Load & Performance Testing

Points For Load Performance Testing Projects

Many website administrators, QA personnel, and development engineers are relying on load testing and performance testing of websites in an attempt to eliminate unwanted negative surprises in their server realms.  These are especially high-traffic sites (mostly eCommerce or popular entertainment sites) which are employing load testing tools to ensure that their web servers can handle large amounts of user access.  These tools enable the SA and DBA personnel to fine-tune the server environment with software and hardware enhancements to avoid performance slow-downs or complete server crashes.

The approach and method is a simple one:  Within the functional/performance expectations of the website, create enough “virtual users” with the load tool to monitor the effects of the load within the load test time length (anywhere from 5 minutes to 1 hour is usually ample time), gather any metrics/error messages available and make decisions on what changes are necessary for optimal server perfomance in a high-load scenario.

There are many free and licensed load and performance testing tools available through the internet.  Here is a partial list:

Apache JMeter








Rational Performance Tester

Testing Anywhere


QEngine (ManageEngine)




Depending on your level of technical expertise and knowledge of scripting, any of these tools may be sufficient for your load testing needs.

There are some general guidelines to be certain to consider when performing performance testing against any site:

1.  It is a good idea to load test within a test environment only, especially to avoid crashing the production server with a large load.

2.  The load script can cause many metrics collectors to be inaccurate when accessing the pages during the load test.  Be certain that any third-party links (such as metrics counters, ads, etc.) are excluded from your load test script via a “blacklisting” method which will ignore those links.

3.  Flash objects can also have an effect on how the website performs under heavy load as those objects are often grabbed from another server.  These can be included/excluded from the test scripts at the discretion of the testing team (most likely using the “blacklisting” method mentioned in item #2) .

4.  Server caching can be turned on or off depending on the decretion of the test team.

5.  The test script itself can often be set to ramp up to a maximum amount of virtual users.  For example:  From 1 VU to 1000 VUs over a period of 30 minutes, then remain constant at 1000 VUs for another 30 minutes.   This often helps the SA determine when the server starts to experience issues.

Common generic server error messages:

Server timeout (no response from server) most likely due to server’s inability to handle large user load can appear as the following errors:

EOFException(java.net.SocketException: Connection reset)

EOFException(java.net.SocketException: Broken pipe)

java.net.SocketException: Socket closed

In closing, whichever load test tool is selected for your tests, there is always some benefit to stressing the server with load whether it be small or large scale load.  Avoidance of server crashes, slow performance and unpleasant user experience is the desired goal.

Ruby for mobile web and smartphone development

Ruby web development & mobile development

Android development has traditionally been implemented in Java; however today updated Ruby language can be the best tool for mobile app development.  Ruboto framework and SDK for native Android development with Ruby is ideal for classic Ruby developers. If you want to use Ruby the way you would use the Android Java, Ruboto is an excellent solution that can approximate the Java API app development approach.

For enterprise and informational app development, Rhodes may be the solution you’re looking for. Rhodes employs a compiled subset of Ruby optimized for security, code size and speed. Rhodes is very much like Ruby and can be used with multiple operating systems. Expect compatibility with Android, iPhone, Symbian, Black Berry and Windows Mobile. With the only Model View Controller framework supporting native smartphone application development and the sole Object Relational Manager, it is a solution many are seeking.

Application developers who are familiar with Ruby may wish to try Altoros Systems’ Ruby for Mobile Application Development. It can be very handy when it comes to converting existing applications for mobile use. Development and SDK frameworks are available for smartphone and Web. RubyMotion is an SDK with pioneering abilities that allows you to rapidly develop and test iOS and OS X applications for iPhone, iPad and Mac. This software tool set is based on the mature MacRuby developed at Apple 5 years ago.

With all these fresh Ruby web development solutions and the respected open source history Ruby is known for, it makes sense for mobile app developers familiar with Ruby to check out the above solutions before marching down other well-known paths such as Java API.

Observations in Effective Software Development

Rethinking Software Development – Reducing Software Defects

Experts in the software industry have tried everything from new project development lifecycle methodologies, such as Agile, to the latest whiz-bang test and Dev tools that promise greater productivity and suggest a “bug free release.” While many new lifecycle processes and tools can help a project, there are many core fundamental techniques and tools that a Dev/QA team must have in place to improve the chances of shipping a high-quality product or service and employ ways of reducing software defects.

Whether your team is using a waterfall based SDLC or variation, Agile, XP, a mix of both, or something else, it’s a guarantee that the later in the development lifecycle that defects are found, the more costly they will be to resolve. This cost will come in the number of hours required to redesign, the number of people needed to resolve, or the amount of intra-team involvement required to fix. The earlier in the process that bugs are found, no make that the earliest that bugs can be designed-out of a product so they are never introduced in the first place, the less costly they will be to the team.

In recent years developers have been performing more formal requirements, design, and code reviews as part of standard development protocol. In the past, most developers would start writing code and crank out the software to the team to review. It’s been statistically shown that early formal inspections of requirements and design before a project has started or at the onset of a project will increase your success rate of releasing high-quality software. According to Capers Jones, an expert in software design methodology, the requirements phase can have a defect potential of 1.00 per function point on average. This means that for every function point you can expect on average to find one defect originating from the project’s requirements. Since requirements are gathered at the front end of a project it is again typically the least costly place to resolve issues. Putting this in pragmatic terms, this means that you must institute some type of formal requirements review at the beginning of the SDLC and that you had best have not only the project management team and development team on board, but also include the QA team and the QA engineering team if you have one.

Next in importance at resolving defects comes the design phase of a project. Capers Jones rates the defect potential of design at 1.25 defects per function point. Design is actually not only the job of the “design” team, but should also involve core team members across the software development domain, and even include some key management. Yes, I did say management. There’s always something to be learned towards improving a product’s design that even the best software designers or usability engineers can miss. For quite some time I was involved in usability testing of the Norton Utilities for Macintosh. I was well versed in Apple Human Interface Guidelines – the tome that represented Apple’s definition on how usability should be designed into a software product and I was also a big proponent of the book, “The Design of Everyday Things,” by Donald Norman. I soon came to realize that almost everybody has something to contribute to the design phase of a software project, hence why usability lab testing is often so important. You’re bringing the public in to test potential designs and you’ll quickly see them do things that you could in no way have envisioned. The things you’ll learn will often be taken back to the design team and can change original product designs considerably.

Third on the list, in fact the area that has the most potential for introducing defects is the coding phase of the project. Capers Jones says that there are 1.75 defects for each function point introduced during the coding phase. Okay, so you’re undoubtedly wondering how can I reduce the number of bugs in the coding phase.

In our next article we’ll go into the processes, tools, and systems you must have in place for an effective QA coding phase that will reduce the number of bugs in your product.

Source: Software Productivity Research, LLC; “Software Quality in 2008: A Survey of the State of the Art.” Capers Jones