Productivity at the Cost of Efficiency: an Analysis of Advanced C# Programming

In this modern age of computer programming, there are many advanced features at our disposal. These are designed with elegance in mind and are put in place to allow programmers to be more productive. They are often meant to remove the need to know machine and system specifics so that programmers can focus on the higher level tasks at hand. What this analysis focuses on is examining what happens behind the scenes when using these advanced features. Performance for various new features of C# such as anonymous methods, reflection, and iterators were examined alongside more traditional programming styles in order to determine if these advanced features designed for productivity have any negative impacts on program efficiency.The outcome of this analysis is that these new features are highly beneficial and should be used whenever possible as they have a negligible effect on efficiency. Even when used haphazardly, these new features have proven to be just as efficient as standard programming method

Productivity at the Cost of Efficiency: an Analysis of Advanced C# Programming

In this modern age of computer programming, there are many advanced features at our disposal. These are designed with elegance in mind and are put in place to allow programmers to be more productive. They are often meant to remove the need to know machine and system specifics so that programmers can focus on the higher level tasks at hand. What this analysis focuses on is examining what happens behind the scenes when using these advanced features. Performance for various new features of C# such as anonymous methods, reflection, and iterators were examined alongside more traditional programming styles in order to determine if these advanced features designed for productivity have any negative impacts on program efficiency.The outcome of this analysis is that these new features are highly beneficial and should be used whenever possible as they have a negligible effect on efficiency. Even when used haphazardly, these new features have proven to be just as efficient as standard programming method

Report on a User Test and Extension of a Type Debugger for Novice Programmers

A type debugger interactively detects the expressions that cause type errors. It asks users whether they intend the types of identifiers to be those that the compiler inferred. However, it seems that novice programmers often get in trouble when they think about how to fix type errors by reading the messages given by the type debugger. In this paper, we analyze the user tests of a type debugger and report problems of the current type debugger. We then extend the type debugger to address these problems. Specifically, we introduce expression-specific error messages and language levels. Finally, we show type errors that we think are difficult to explain to novice programmers. The subjects of the user tests were 40 novice students belonging to the department of information science at Ochanomizu University.Comment: In Proceedings TFPIE 2014, arXiv:1412.473

XP customer practices: A grounded theory

The Customer is a critical role in XP, but almost all XP practices are presented for developers by developers. While XP calls for Real Customer Involvement, it does not explain what XP Customers should do, nor how they should do it. Using Grounded Theory, we discovered eight customer practices used by successful XP teams: Customer Boot Camp, Customer’s Apprentice, Customer Pairing, and Programmer’s Holiday support the well-being and effectiveness of customers; Programmer On-site and Road shows support team and organization interactions; and Big Picture Up Front and Re-calibration support Customers steering the whole project. By adopting these processes, XP Customers and teams can work faster and more sustainably

Scaling the Management of Extreme Programming Projects

XP is a code-oriented, light-weight software engineering methodology, suited merely for small-sized teams who develop software that relies on vague or rapidly changing requirements. Being very code-oriented, the discipline of systems engineering knows it as approach of incremental system change. In this contribution, we discuss the enhanced version of a concept on how to extend XP on large scale projects with hundreds of software engineers and programmers, respectively. Previous versions were already presented in [1] and [12]. The basic idea is to apply the "hierarchical approach", a management principle of reorganizing companies, as well as well-known moderation principles to XP project organization. We show similarities between software engineering methods and company reorganization processes and discuss how the elements of the hierarchical approach can improve XP. We provide guidelines on how to scale up XP to very large projects e.g. those common in telecommunication industry and IT technology consultancy firms by using moderation techniques.Comment: 7 pages, 4 figure

Programming Safety Tips: Why You Should Use Immutable Objects or How to create programs with bugs that can never be found or fixed.

Program safety deals with how to make programs as error free as possible. The hardest errors in a program for a programmer to find are often errors in using memory. There are two reasons for this. The first is that errors in accessing memory almost never show problems in the proximate area of the program where the error is made. The error has no apparent impact when it is made, but often causes catastrophic results to occur much later in the program, in areas of the program unrelated to memory error that caused it. The second reason memory errors are so difficult to find is that the working of memory is often poorly understood by most novice, and many professional, programmers. This makes it difficult for many programmers to even understand why an action causes the error. This article will show an example of a program error that can easily occur when memory access is poorly understood. This leads to program errors that are very easy to fix when they are found, but extremely difficult to find. The article will then explain how many memory errors can be easily avoided by following the very simple rule, “Make all object immutable unless there is a good reason to make them mutable”, and why immutable objects are an essential tool in good, safe programming practice