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?
