kissIT!: Rapid Agile Development, a practical approach to hybrid development in SQL, C# & VB.NET

Introduction

Over 18 years of Windows software development experience have distilled in this author a practical and productive method of working. A pragmatic approach with a sprinkling of trial & error appears to work well combined with a good theoretical background of a Degree in Business Information Systems. This sits well with Prototyping / Agile Development in SQL, C# and VB.NET.

A few areas have proven invaluable in saving time, effort and reducing stress during the development and delivery process which are expanded on here and how the kissIT!® applications can help.

For more information please visit www.rapidagiledevelopment.com

Installers

Prototyping or using the Agile Development Method rely on constant test / end-user (customer) feedback. To do this the customer must be able to evaluate each iteration of the product(s). With this in mind, for Windows applications, the product installer should be the first project to be started. As the complexity of the product(s) increases the complexity of the installer may also need to increase but only the bare minimum is required to start.

Some would say that the installer is only needed when there is something to install i.e. the finished product. In reality the installer is the delivery system for products and the first impression for the customer so should be considered as a development project in its own right.

To Generate or not to Generate?

Code Generators (for C#, VB.NET & SQL) usually promise the world. Some are over complicated, difficult to use and produce verbose amounts of output, a lot of which is never used, while others don’t generate enough and require too much user input and configuration. If the adverts are to be believed, simply pointing a code generator at your data model and clicking build will have your customers completely satisfied. In reality this is not the case. kiss!® is designed to get core functionality into a productive, intuitive user interface.

For more information please visit www.rapidagiledevelopment.com

Code Generation has its place and can be very productive if used correctly with a good code generator. Before a project starts a code generator should be evaluated and selected. The parts of the project suitable for code generation should be determined and a belief that the code generator is a development aid, not a magic bullet should be maintained within the development team.

If code generation is appropriate for the project then ensure the data model (which can be an empty database) is constructed that meets the requirements of the selected code generator. Some simple items to consider are:

1. Ensure all tables have a system level, auto-incrementing ID column.
2. Ensure all tables and columns have names without spaces and are not considered reserved / keywords by the destination programming language.
3. Ensure correct Data Type is used for each column to minimise record size.
4. Use table name as a scope delimiter when naming columns e.g. Customer.FullName not Customer.CustomerFullName.
5. Try to organise columns in tables that will allow Helper routines to be generated (if supported) or manually written e.g. if tables with ID, Name & Description columns can have those columns (identically named) in the same order then Helper routines can easily be written for lookups etc.
6. Use Table & Field Enums for accessing Data Fields (by index or name) in a returned Dataset. If these Generated Enums are kept up-to-date the programming language compiler will alert you to code that accesses dropped / renamed fields.

Code Generators may be good at spewing out thousands of lines of code and reporting how many man hours and dollars they have saved but in the real world systems are either manually written or hybrid (part generated, part manually written). Does the selected code generator allow for the management of manually written code and or SQL? Does the code generator allow for customisation of generated code without being overwritten at each iteration (Base & Custom Classes)?

kiss!® is designed to help with hybrid development.

kiss!® allows integration with Third Party applications which the user may already own, or can be purchased separately from the relevant producers:

kiss!® produces Base Classes and Custom Classes which are not subsequently overwritten, allowing for custom code to be added. Manifest and Interface classes are generated for each iteration:

kiss!® can produce the following output using customisable Templates in native C#, VB.NET and SQL syntax:

1. Base Classes
2. Custom Classes (allows manual changes to partial classes without being overwritten during next generation cycle)
3. Business Logic Layer (BLL, BLO)
4. Convert Class (VO -> TO; TO -> VO)
5. Data Access Layer (DAL, DAO)
6. Domain Objects (DO)
7. Domain Object Managers (MO)
8. Field Enumerations
9. Table Enumerations
10. Transfer Objects (TO)
11. Value Objects (VO), also known as Data Transfer Objects (DTO)
12. Interfaces
13. Web Services (WS)

Example Generated Classes for the AdventureWorks HumanResources.Department table:

Database Scripting

With an installer in place it is easy to show customers what has been done after each round of development. If the application has a database the database will also need to be installed and patched. Installing and patching databases is another important part of prototyping as it is vital that customer’s data is maintained once the product is installed on site.

Creating a database from scratch using SQL scripts is a good way of identifying SQL execution issues early (i.e. before deployment) especially in a team environment where there can be instances of developers just "throwing SQL scripts over the wall" without testing the execution of the SQL. Keeping database objects (tables, views, stored procedures) in their own file (one object per file) makes maintenance easier especially if the SQL script file name reflects the name of the database object. Separate files (as opposed to a single monolithic SQL script) also allows multiple developers to work on the database objects without having to wait for a monolithic SQL script to be checked in / unlocked in Version Control.

Scripting a database is also a good way for adding test data. For best results during a prototyping iteration the database should be created from scratch using SQL scripts then populated with test data and finally have the referential integrity applied. Getting into the habit of this process flushes out issues during the development process that may normally only be discovered during the installation process.

SQL scripts should be subject to the same management and source control as the programming language source code.

kiss!®, concatSQL!® and SQLscriptIT!® are all designed to help with SQL script generation, management, SQL execution and SQL testing.

For more information please visit www.rapidagiledevelopment.com

Delivering Applications

The Agile method requires product iterations to be delivered to Test quickly. Part of the delivery process is Security: Strong Naming and Code Signing .NET assembiles. This can be achieved by using signIT!. signIT! is a GUI for using the relevant Windows SDK and .NET Framework executables in an iterative manner. Configurations are maintained to save time and effort during this part of the delivery process.

Feature Creep

Is feature creep a bad thing? Only if the customer cannot afford the development costs!

During Prototyping iterations the customer will no doubt see their ideas crystalise in front them and formulate new ideas based on the system’s functionality to date. Without a specification that is set in stone this can lead to time and cost overruns. This is manageable and will usually lead to a better product provided time and cost requirements can be accommodated by the customer.

Summary

There are a lot of books about Prototyping / Agile Software Development which offer a wide range of advice. It is difficult to maintain complex practices in a development environment so the simpler the practices and procedures are, the more effective they will be. If Prototyping is not new to you or your organisation then you are likely to have your own method of working. If necessary try evaluating / refining / distilling out the essentials and concentrate on ensuring these are done regularly.

The few items listed here are by no means exhaustive but should be seen as tasks to be completed in each Prototyping iteration in addition to the bespoke work to meet customer requirements.

To draw a parallel with exercise, it is not so important that an extensive time consuming workout is completed (Waterfall Model Analysis) but rather that a minimum amount of exercise is actually done regularly (Prototyping Iterations).

To aid the Prototyping process, define a few crucial steps, some of which must be repeated for each iteration, start-up and enjoy the ride.

1. Evaluate and select Installer software and start installer project development (once per project).
2. Evaluate and select Code Generation software (once per project).
3. Set up Database Data Model (and script out to SQL) observing constraints imposed by Code Generator (every time a Data Model change request is applied).
4. Create Data Model Database and Test Databases, including test data, from SQL scripts on a regular basis (every time a Data Model change request is applied).
5. Generate SQL C.R.U.D. Stored Procedures, Data Access Layer, Business Logic Layer, Table and Field Enumerations and Web Services (every time a Data Model change request is applied).
6. Demonstrate the product(s) on a regular basis to the customer.
7. Evaluate and overcome blockage issues.
8. Manage the Feature Creep as customers get to see what is possible.
9. Repeat and enjoy the process!

Thank you for your time.

For more information please visit www.rapidagiledevelopment.com