Building Systems

Been having a good look at Government 2.0 which I think is great. Particularly, http://www.katelundy.com.au/category/campaigns/publicsphere/open-gov/, the Public Sphere 2.0 is a great forum and hopefully we will see more of this public engagement in the future.

The problem is that whilst promoting social networking to derive policy is great, I think a fundamental issue is still to be resolved .. the systems behind the scenes. I am not disparaging the process at all, but to me it is a tune I have heard before. The users want everything and the systems behind the scenes are a tangled web of confusion. I believe you have to get the foundations right and that starts with how software is designed, how it is built and how it processes data.

So here are my guidelines for software development just in case someone stumbles on them. It literally would save millions of dollars if government IT systems were built with a few prerequisites in place prior to any project commencing. There are many guidelines available for managing IT projects, I will preface this by saying I don't know what the government already has in place.

As IT integrates more and more with our everyday lives it is imperative that the government;

• Not be tied to proprietary systems
• To build systems that will have significant life spans
• build systems that can communicate well together.

So from an ignorant view the following would have to be a bare minimum;
1. UML. UML provides a common graphical language for exchanging system design. This should be part of the visualization of government processes. While the UML specification has many diagrams in it the 'Use cases' would allow lay people the ability to visualize a system flow without being inundated with technical jargon.
2. Code isolation. UML and unit tests encourage applications to be broken into small code blocks. These code blocks can be run under unit tests isolated from the production environment and suits the agile development philosophy.
3. Unit tests. Unit tests, allow new versions of software to be tested, as an isolated module, prior to implementation minimizing the possibility of failure. These are written prior to the software code being developed. Using unit tests and contract programming would allow the outsourcing of non-critical routines, which would vastly decrease the cost of developing and maintaining systems.
4. Language choice. Proprietary languages are a risky investment. I worked for the X government department as a contractor when the Ochre language went bankrupt. At least 3 years of work was effectively lost. The 2 contenders for ubiquitous programming are Python and C#. Both languages are now available on Linux and Windows, both allow database abstraction. Productivity in Python is higher and it is closer to the human readable form. C# is excellent in multithreading and operating system integration. Python can be integrated with C# and C++ to get the best of the lower level languages. Both Microsoft and Google are using it.
5. Database abstraction. This is crucial. Code should not be written in such a way that it talks to a database directly. It should go through a database abstraction layer first. This means that the application is independent from the database platform. So should a system be implemented using MS SQL, it could be changed to run on PostgreSQL, Oracle or any other supported platform without any changes. Database Abstraction Layers are available in Python (SQLalchemy) and C# (nHibernate) as well as others. As part of database abstraction, application rules should not be stored in the database, they should reside in the application and work on the abstraction layer. If you run stored procedures you have effectively tied yourself to one platform.
6. Code repositories. Code should reside in a system that supports check-in and checkout, prior to an application being built. That ensures that the code cannot be lost.