Mainfram Reality

Few years ago I read about how Roman Army managed to control such a large part of the “known world”. One of the most important parts of their strategy was that all army barracks throughout their empire has the same layout. So a soldier being moved from North Africa to central Europe knew where the armory was and where to get food and where to go sleep. Adjustment to a new battle ground was much smoother and therefore the soldiers were more effective.

Now, I try to use the same principles for all the software development projects I run. Most of the time I am in charge of developer team(s) and what I call “Roman Army Principle” is essential to how I design applications.

Here are the basic rules:

Each part of the application must “look” like any other part of the application. This is achieved by writing APIs for almost everything. In enterprise application sense, when a developer writes code to validate some data before it is saved, another developer uses the same well defined method of doing the same thing. This means that any developer on the project knows where other developer would put a certain piece of functionality, simply because its done the same way.

If developers must do something outside the framework that has been established, a consensus on how this is to be done is made by the entire team and from then on, such an approach is used by the entire team.

The API must enforce built in work flows for the data being managed. So very record must go through same steps. So for creating a record, that record must be validated, tasks can be performed before it is created, the creation of the record, and then tasks can be done after the record is created. Every record must go through this work flow, again if requirements are different, the entire team must be consolted and approach agreed on.

So what are the benefits:

Each team member feels comfortable working on different parts of the application, because all parts look very much the same.

Developers working on different projects can switch between projects much more easily since the two projects have the same structure, not just basic similarities but more fundamental similarities exist between projects.

The framework then evolves and takes into account ideas from may different people and developers, developers have ownership of the framework and since they have developed it, feel more comfortable using it.

Problems are solved the first time in most cases, and then solution is applied over and over, reducing time and cost.

Applications developed in this way are easy to maintain and support, since a problem with saving a record originates from a known location in the code.

I just like the name “Roman Army Principle”

Over the past months I have been involved in writing applications using Ruby on Rails and many associated Open Source technologies. But during all this time my bills are being paid by contracting and working with Microsoft.NET to build large enterprise applications.

With Microsoft release of Iron Ruby the worlds might be converging and I am left with a challenge to understand how I can truly bring the two worlds I love so much together.

It is not just a question of which platform is better, each platform has its good and bad points. Ruby is just a beautiful programming language, Microsoft.NET has a rich and mature development environment. So where to from here. Well in order to answer that question I better describe what I would consider to be a perfect software solution. In this case I am going to assume a web based application.

• The web based interface must run on all popular browsers, easily…
• The web back-end must provide a secure API since the web interface should be a full AJAX based implementation.
• The application should be easy to install and maintain.
• Any web based application of sufficient size must have a server processing component, like a windows service or a linux daemon, for all those tasks that take too long.
• Developing the application should be based on what I call “Roman Army Principle” (more on this later).
• I do not want to write any SQL, except for the more complicated requirements.

So as the title suggest I have decided, just for the development environment sake to use Microsoft .NET as the base platform. Now since .NET uses SOAP based Web Services as a basic way to exposing an API to the web, I need to look for something else, as for me REST is a better way of doing these types of API. Its better since it works much more easily with the JavaScript AJAX way.

Second and most important thing is that I do not want to write SQL statements for most of my application. For this we enlist the help of O/R mappers like LLBLGenPro or some library based on the ActiveRecord pattern.

Visual Studio.NET has features to easily develop setup files for any application. It may not be the best, but from my experience in most cases it delivers just fine.

As for the programming language, Ruby is coming to .NET. There is no contest there, if IronRuby works like standard Ruby, and I believe it will.

Code generation is another major part of any enterprise application. Unlike true web applications and sites like flickr, the enterprise applications almost always deal with managing data in SQL tables, directly in most cases. So there is really no need to write a list, edit or view screen for each of those tables. Like Ruby on Rails, that code should be generated, and then customized as required.

So where to from now… with maby technologies out there bringing together technologies from both sides of the divide, the future looks challenging, but ultimately I just want to use the best tool for the job being performed. I don’t want to say I only use Microsoft techologies, or that I am an Open Source developer. There is a place for both, but once they talk to each other nicely, my work will be that much more enjoyable.

This has to be one of the most amazing software demos I have seen in a long time.
The potential for this technology is huge. Imagine applications using these types of interfaces, with real time ability, this could be the new and amazing way to use software.

This has to be one of the greatest software development presentations I have ever seen.
Jim McCarthy has great love for software development. He is most known as being a member of Microsoft C++ team.

A must see for anyone involved in software development.. in any capacity.

Miguel Carrasco on his Software Development in the Real World blog has written a great article about SharePoint Portal Server.

Full article:
http://www.realsoftwaredevelopment.com/2007/09/why-sharepoint-.html