Articles Archive

Finding Litigation Code Review Experts

The discovery phase of IP litigation often calls for a technical review of a software product. A code review is an activity conducted by an expert witness that involves reviewing the source code of a product to discover pertinent facts relevant to the case. The specific facts depend on the purpose of the review. In patent cases, the search may involve looking for specific functionality buried within a mire of source code. For copyright cases, it may involve searching for evidence of literal or non-literal copying.

Attorneys sometimes assume that any expert with competence in a particular programming language would be qualified to perform a code review. This is not necessarily true. Building software applications and performing forensic analysis of software applications are different activities, and indeed, are almost exact opposites. Developing new software involves writing source code based on ideas and understandings that already exist in the mind of the developer. Forensic analysis, on the other hand, requires the person to begin with zero knowledge and collect facts through investigation in order to gain an understanding of the product’s behavior. Ordinary software developers may not have an awareness of the consequences of making false assumptions during what is supposed to be an objective code review analysis.

Posted on 27 Mar 2013

A Software Dilemma: From Idea to Enterprise

Today’s most successful enterprise applications were once nothing more than an idea in someone’s head. While many of these applications are planned and budgeted from the beginning, still quite a few applications begin their lives as nothing more than a single-developer experiment with no particular formal design or future in mind. After all, innovation doesn’t always wait around for a plan and a big budget.

Before long, the application grows and becomes too unwieldy for a single developer. At this point, a group of developers project their own ideas and visions onto the product, thereby resulting in a mixed bag of features which are deployed to users first on a test basis and later sold on the open market. Customers begin paying money for the application. By all accounts, the application is “successful.” Or is it?

Posted on 13 Feb 2013

Design as a Deliverable

Before software can be properly implemented, requirements must first be gathered and a design must be created. It has been shown that when software teams spend the proper amount of time on requirements and design, the cost of producing and maintaining enterprise software decreases dramatically, along with the number of bugs and the duration of the implementation and testing phases.

Various research studies have endeavored to identify the “ideal” amount of design time to spend in the pre-implementation phases of a software project. The findings vary, but are generally in the range of 20-35% of the overall project time. Figures such as these often draw strong negative reactions from the people you’d least expect—software engineers. The reasons vary. In many ways, software engineers are to source code as artists are to a canvas: both expect a certain level of independence and feel creatively inhibited by external forces requiring them to do things that they view as superfluous.

There’s only one problem: engineering isn’t art and both requirements and a design are necessary. Nobody would ever step foot into a skyscraper whose design was conceived during construction. That’s common sense. So,why isn’t it also common sense in the world of software that no business wants their critical software systems designed while they’re in the middle of being built?

Posted on 13 Dec 2012

The Perils of Ignoring Implicit Requirements

The following is based on a true story. Details have been altered to protect anonymity.

A national retail company recently rolled out a major software upgrade, impacting its back end software systems, web site, financial reporting, and several mobile apps. The requirements were captured by means of focus groups, surveys, comments, and other means. The requirements were prioritized, discussed, carefully documented, designed, implemented, and numerous test cases were designed to confirm compliance with the requirements. Most would probably agree that everything stated so far is a recipe for success. But read on.

The company in question rolled out a mobile app that initially took more than 30 seconds to load basic customer account data. Once the account data finally loaded, customers discovered them to be outdated by several days—and in some cases, wrong. The additional server load attributable to users attempting to download account data cascaded to the company’s web site, which became unresponsive during several daylight hours on one particular weekend. Additionally, the public-facing aspects of the system turned out to be confusing to customers, leading customers to visit their nearby retail locations to ask questions that employees had no idea how to answer. Most of the problems still existed to some extent even weeks after the initial rollout.

Posted on 19 Nov 2012

Why your software needs obfuscation

Here we explore a subject that is usually of utmost importance to a company’s competitive position in the software marketplace, yet is untaught by most accredited computer science programs. Consequently, this subject sits at the periphery of most software developers’ minds, if it sits in their minds at all. This subject concerns the protection of proprietary algorithms and information contained within software applications. Or more notably, the lack of protection.

Most programmers are taught that software applications are compiled from a high-level programming language to binary “machine-readable” executable code. The false implication is that because the code is now “machine-readable,” it is no longer possible for anyone to read or understand. However, just as high level programming language code can be translated to machine-specific assembly instructions, the process can also be reversed. In most cases, executable code can be translated at least back to assembly code —if not all the way back to some high-level language. Decompilation of programs written in certain languages such as Java and the .NET languages is particularly effortless: with these languages, the executable can be easily transformed back to its precise original source code form.

Posted on 12 Oct 2012

Will your software stand up to a Prolifogy code review?

A chain is only as strong as its weakest link, they say. How strong is your software development chain?

Is your software development team following best practices? Are your trade secrets easy to steal? Are you infringing any patents or copyrights? Will end users find your application too complicated? Will your infrastructure stand up to future expansion and load? Can your vendors and consultants claim any rights to your source code? Are your back end systems vulnerable to attacks?

Astonishingly, the answer to many of these questions is often “yes” according to Prolifogy’s panel of associates—the world’s foremost Ph.D. experts in software engineering. Prolifogy associates have decades of experience and insight into many of the world’s most overlooked, yet most critical aspects of software development. From small startups to large publicly traded companies—no matter the industry—Prolifogy associates have repeatedly discovered that no organization is immune from the potential disasters that await companies that do not proactively search out and resolve these issues.

Posted on 20 Aug 2012

Role of Subject Matter Experts for Patenting Inventions

Licensing and infringement litigation are two primary potential income sources from a patent. With licensing, the inventor permits the licensee to make, use, sell, or offer to sell a patented invention for compensation. With infringement litigation, the inventor seeks damages from entities who have already engaged in the above without permission. After a patent is issued by the United States Patent and Trademark Office (USPTO), it may be sold, licensed, litigated, and/or discarded by the assignee.

With patent sales, the inventor or assignee must convince a prospective buyer that the patent is valid and worth using in a product or service. The same is also true for prospective licensees, where the licensee would generally pay royalties based on use.

Posted on 1 Nov 2011