In this post I’ll attempt to cover briefly major guidelines and principles that proved useful for this approach.
The following principles are recommended to be followed for the efficient xLim 2 development:
- Employ version control and continuous integration (using only dedicated server for the releases)
- Great deal of xLim solutions’ business value is stored in the specific configuration settings (i.e.: schema files, configuration presets for the GridView handlers, layout presets for the single editors, permission settings and workflow chains). They also should be included in the version control and continuous integration.
- Employ test-driven development where appropriate (i.e.: UI handlers and controllers would benefit from the unit tests, workflow micro-controllers are too straightforward to be tested).
- It should take less than 30 minutes on a new machine to setup integration environment, get the sources, compile xLim 2, test it and initialize specific pre-configured solution.
- Develop xLim system vertically not horizontally (create and deploy into production simple full-layered solution first, and then start extending it).
- Stick to the Don’t Repeat Yourself principle (refactor and reuse code, controllers and handlers where appropriate)
- Perform rapid prototyping in the first phase of the software development project and then follow by the iterative development (2 week development phases with planning of 2-3 phases into the future). Planning should include logically working through all the changes-to-be-implemented and aligning them with the evolution of the architecture.
- Always schedule time for xLim configuration and tuning after each milestone.
- Regular backup policy should obviously be in place.
- Do not waste time writing throw-away use cases that are used only for formal acceptance. It is more efficient to stay in close contact with the customer and understand his real business requirements.
- Writing composite business functionality overviews and visualizing workflows, on the other hand, is recommended. xLim is extremely flexible, so it is too easy for the customers to get lost in their own choices about configuring views, workflows and the security. Composite overviews and workflow maps will serve as an excellent way of staying on the same page and initial documentation.
- xLim 2 solutions do not favor big resource pools and parallel distribution of tasks. That’s because of the complex nature of the solution. This implies greater development risks and the need to manage them carefully.
- Do not implement configurability and flexibility just for the sake of doing that. I’ve seen good information management systems turn into an unmaintainable and logical mess, just because they were made too flexible. Flexibility requires separate management UI and adds additional fragile points in the system.
- Work closely with the end-users. xLim 2 is extremely flexible, so they should get the feeling/understanding of the functionality that is easy to achieve (i.e.: adding new business objects with the grids and complex workflows) and is not so easy (i.e.: adding completely new type of shared object that requires complex web and desktop UI handlers).
Additionally, here are the references that proved themselves to be quite useful while establishing the guidelines for the specific xLim solutions and introducing new developers to them:
- Project Management Body of Knowledge – that’s the universal “vocabulary” for all the projects. It does not say a single word about the software development, yet it is extremely useful for understanding and applying any methodology.
- Article on agile methodologies by Martin Fowler – this article is the classics.
- SSW Rules to better… – this is an incredibly useful resource (note, however, that this Australian company is a Microsoft-oriented shop; this means a lot of “TFS”, “SourceSafe” and “Microsoft SQL Server”). The following topics are definitely worth reading:
- Rules to Successful Projects
- Rules To Better Code
- Rules To Better .NET Projects
- Rules To Better Large .Net Projects
- Rules To Better Interfaces
- Rules To Better Unit Tests
- C# Coding standards (or you could pick any other good one. Being consistent in the project is more important than the debate “whether to prefix private members with underscore or not to prefix”)
- How to set up a .NET development tree
- The Fine Art of Commenting
Although the XPO takes care of the 80% of database management, the remaining 20% still require some attention. Here’s the recommended reading on that:
- Database change management best practices
- Evolutionary Database Design by Martin Fowler
- Continuous Database Integration