10 Reasons You MUST Consider Pattern-Aware Programming Developers spend up to 20% of their time writing repetitive code that machines could generate more reliably. Automate the boring side of programming and get a 19x ROI. Developers spend up to 20% of their time writing repetitive code that machines could generate more reliably. Automate the boring side of programming and get a 19x ROI. Within this document we discuss the problem of duplicated source code, also known as the notorious boilerplate code that stems from manual implementation of patterns. We challenge the notion that patterns in software development are limited to architecture and design but do not apply to the implementation itself. Instead, we assert that the absence of support for patterns in programming languages is a chief cause of boilerplate code. We propose introducing support for patterns into mainstream programming languages—a concept we namepattern-aware compiler extensions. This guide is written for all organizations for which software development is critical, but that struggle with high development cost, long time to market, poor quality (even random defects) and shortage of qualified engineers (with the need for engineers to do meaningful work, not repeating mundane tasks). It is especially written for CTOs, software architects and senior developers in software-driven organizations— specifically in financial, insurance, healthcare, energy and IT industries. Is there a real problem? Do I need to address this? As a developer, how many times have you found yourself: ● copying and pasting blocks of code to implement a ● debugging random failures in multi-threaded applications? functionality (e.g. logging)? ● wondering why it’s so hard to build enterprise-grade software ● repeating the same pattern of code hundreds or thousands when the prototype seemed so simple? of times—and wishing so-called “modern” programming languages were a bit smarter? If you’ve answered yes to any of the above questions, then you have a problem with boilerplate code. ● trying to understand the business logic behind a codebase cluttered with technical code such as exception handling, What is boilerplate? Why is it so ubiquitous? And more importantly, transaction management, audit or thread synchronization? what can we do about it? This is what you will learn in this white paper. ● struggling to add or modify functionality in an existing software? The problem: existing compilers don’t support patterns Whether it’s architecture, carpentry or mechanics, patterns are You would not hire artisan carpenters to build a utilitarian industrial essential to all construction and engineering disciplines. Learning building, would you? not only how to implement patterns, but also when and why to choose them, is an important part of the education of professionals Developers call this repetitive code boilerplate. Good developers of these disciplines. consider boilerplate code as a boring but necessary part of their work. However, as this white paper will show, boilerplate code is Software engineering is no exception. Patterns have been not inevitable. successfully applied to software architecture and software design, two preliminary steps of software constructions. As a result, Before looking into alternatives, take a few minutes to think about today’s software engineers are trained to think in terms of patterns. the cost of boilerplate code for your organization. However, when it comes to implementation, developers don’t have the right tools. Conventional programming languages miss a concept of patterns. Therefore, software developers are forced to implement patterns by hand. Just like artisan carpenters would manufacture dozens of almost (not totally) identical joints to build a cabinet, a software developer would add almost identical exception handling logic to hundreds of functions by hand. The difference, however, is that the artisan carpenter produces a piece of art, while the software developer builds a utilitarian application. PATTERN-AWARE PROGRAMMING 2 What is boilerplate costing you? Boilerplate code is a major source of pain in enterprise development. It has the following consequences. 1. High development effort when the initial developer left. When you know that ● High development costs. Some application features require maintenance accounts for 55% to 95% of the total cost of a a large amount of repetitive code when implemented with software system3, and that developers spend half of their time existing mainstream compiler technologies. Source code is a on average trying to understand existing code, you realize why liability and needs to be maintained. Empirical research shows it is so crucial to keep source code succinct and readable. that the total lifetime cost of a line of code is approximately $14 for medium enterprise projects1. This cost also applies to ● Strong coupling. Conventional programming languages boilerplate code. don’t give you the tools to properly decompose the pattern itself from its usage. As any software architect knows, poor ● Long time to market.The time developers spend writing problem decomposition results in duplicate code and strong repetitive code is time they cannot spend focusing on what coupling, and strongly coupled architectures are more difficult actually matters. Businesses that come late to market can to maintain. miss opportunities. For example, suppose you want to modify a pattern to change 2. Poor quality software the details of an audit policy. If your audit policy requires you ● High number of defects. Every line of code has a possibility to add code to every single business function being audited, of defect, but code that stems from copy-paste programming you will end up modifying thousands of files. This is why weak is more likely than others to be buggy because subtle coupling and proper problem decomposition is so important. differences are often overlooked. Additionally, empirical research2 shows that features that are implemented across a 4. Slow ramp-up of new team members large number of artifacts are more likely to contain defects. ● Too much knowledge required. When new team members come to work on a specific feature, they often must first learn ● Lack of robustness. The difference between a prototype about caching, threading and other highly technical issues and an enterprise-grade application partly lies in features before being able to contribute to the business value—an such as exception handling, transaction management and example of bad division of labor. auditor caching. These features typically exhibit the most repetitive patterns and are tedious and boring to implement; ● Long feedback loops. Even with small development teams, therefore, reliability features are often deliberately omitted, common patterns like diagnostics, logging, threading, data unintentionally forbidden in some parts of the applications or binding and undo/redo can be handled differently by each simply left untested and unreliable. developer. Architects have to make sure new team members understand and follow the internal design standards and ● Multi-threading issues. Conventional object-oriented have to spend more time on manual code reviews—delaying programming languages allow programs to be simultaneously progress while new team members wait to get feedback from executed by several threads on multi-core CPUs, but these code review. languages do not guarantee that the program execution is safe. As a result, developers have to build thread safety manually using low-level thread synchronization artifacts such as locks, events or interlocked operations. In any sizable application, managing locks becomes a nightmare. The problem occurs when developers forget a lock (and it always happens). No big red sign appears immediately, instead, the defect will hide in the code and will appear randomly, most of the time in production. This is why thread safety problems are so difficult to diagnose. 3. Difficulty to add/modify functionality ● Unreadable code that’s difficult to maintain.Business code is often littered with low-level, non-functional requirements and is more difficult to understand and maintain, especially 1 One developer typically produces 600 lines of code per month (McCon- nell, Steve (2006). Software Estimation: Demystifying the Black Art. Pearson Education). We used the estimate that the yearly cost of a developer is $100,000. 3 Roberto Minelli, Andrea Mocci and Michele Lanza (2015). I Know What 2 Eaddy M., Zimmerman T., Sherwood K., Garg V., Murphy G., Nagappan You Did Last Summer—An Investigation of How Developers Spend Their N., Aho A. (2008). Do Crosscutting Concerns Cause Defects? IEEE Transac- Time. Published in 2015 IEEE 23rd International Conference on Program tions on Software Engineering, Vol. 34, No. 4, July/August. Comprehension. PATTERN-AWARE PROGRAMMING 3 Existing technologies Several different tools can be used for pattern automation although they have not been designed specifically for this purpose. These tools are often found under the categories of dependency injection framework, aspect-oriented programming framework, meta-programming framework and assembly post-processor. Dynamic Proxies and Dependency Injection Aspect-Oriented Programming Frameworks Aspect-Oriented Programming (AOP) was invented at the Xerox A proxy is a common design pattern in which a class operates as a Palo Alto Research Center (PARC) in 1997 when Xerox engineers gateway to one or more other classes. A dynamic proxy is a class designed AspectJ™, an