As of January 1, 2015, Prolifogy was honored to become a member of the World Wide Web Consortium (W3C), an important and influential standards body created by Tim Berners-Lee, the inventor of the World Wide Web.
W3C was founded with the goal of leading the Web to its full potential by developing protocols and guidelines that ensure the long-term growth of the Web. As the Web has developed over time, W3C’s efforts have been integral to keeping web technology relevant and to addressing needs in the marketplace.
Two key design principles—Web for All and Web on Everything—guide W3C’s work. Web for All encompasses the social value of the Web, which enables human communication, commerce, and opportunities for shared knowledge…
When your business makes headlines, you don’t want it to be because of software glitches caused by subpar source code. Everything may look great on the surface, but cracks in the foundation—such as incorrect assumptions, untested scenarios, noncompliance with best practices, and other errors and omissions in the code—can quickly cause your company’s reputation to come tumbling down.
Here are six of the top reasons your company should consider a code review:
When attorneys seek an expert witness for a litigation matter, it seems reasonable to use an outside company for recruiting an expert. This arrangement presumably allows the attorneys to focus more on the matter at hand and spend less time recruiting experts.
There are two types of firms an attorney may approach: consulting firms or expert witness referral services. They are not the same. Consulting firms are engaged in the business of specific subject matter and generally have a staff of experts who work routinely together and whose skills complement one other. Referral services do just that: refer. After matching up an expert to an attorney, they collect a fee and walk away.
Here are 5 good reasons not to do business with expert witness referral services:
Legacy business applications which were “bleeding edge” just 2 years ago now seem to have a funny way of sending your customers running in the opposite direction. You understand that these applications need to be upgraded, and quickly. But how and to what, exactly? Although upgrading enterprise software has never been a pleasant experience, today’s IT professionals face so many tough technical choices, it’s enough to make anyone’s head spin.
Among the decisions to be made: should you stay with native applications or migrate to the web? Should the solution be supported on mobile devices and tablets? Should the solution be hosted in the cloud? Should you attempt to reuse legacy software or tear everything down and start again? What are the advantages and disadvantages? What are the costs? How long will this solution last?
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.
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?
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?
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.